TRIOS Installer -- shiny new v7.0.7 ( not late at all )...

[filip]

it not seeing the installation but it most likely has to do with grub-efi is not being installed correctly

I don't have that issue -- Box weirdness galore. 
Though it would be nice if you could post the installation log from it ( boot live -- mount root -- cat /var/log/installation.log ), it should tell us more about what happened. 

[VastOne]

working to get that now.. there is no network now on the livecd with the changes made.. getting the enp0s3 instead of eth0 and failing to restart the network

I will have the file up shortly

[VastOne]

Here is a pastebin post of the installation log

[VastOne]

I also attached it here

[filip]

@Network:

I can't be of much help here, since besides the usuall stuff, it's exactly the network nonsense that keeps me away from systemd. Random connection drops, changing cable from one LAN port to another breaks the network on both, the famouse "doesn't brings up the net on boot", device name changing....

Anyway, quick workaround for live is to just run "dhclient". 
And if I may suggest you to take a look at "connman"... If doesn't have issues with systemd, it might be perfect for VSIDO, given that it has tiny footprint* and a solid Gtk GUI ( not pacakged yet, unfortunately ), and the best off all is that nothing else is needed ( nm, wicd etc... ).

connman-gtk: https://github.com/jgke/connman-gtk
* Along the lines of 5-8MB of RAM for both the daemon and the GUI.

@Installer/GRUB:

Looks like you didn't setup an EFI partition ( fat16, about 30-100MB, mountpoint=/boot/efi ). 

[VastOne]

^ thanks for that.. is the creation of the fat16 partition is all that is needed for the installer?

Do I tell grub to install there?  Forgive my ignorance on this.. never had a uEFI hardware and very limited experiences...

[VastOne]

I saw the answer to my question in the installation at the partition setup .. it does the boot/efi for us.. nice!

[VastOne]

Successfully installed and now seeing the issues you reported clearly... I created the partitions in Gparted before the installation so I did not see the mkfs issue .. I will test that on net test install

1.  net.ifnames=0 is easy to correct.. It will be on the next ISO test.. Since the grub config files are different I need to edit them to be the same

2. I will look at connman and I have a short term fix for the local-filesystems.service issue simply shortening 90 seconds down to 5
is a setting from fstab that is not being passed in this ISO.. will research and figure it out

3. Will fix the Medit issue

Thanks for all the help and feedback!

[jedi]

Successfully installed and now seeing the issues you reported clearly... I created the partitions in Gparted before the installation so I did not see the mkfs issue .. I will test that on net test install

Which ISO? the 02Apr one?  I did see the mkfs error.  Reran and did gparted first solved that.  Tried the install with /boot/efi mounted and not mounted.  Same result both times.  Did not work.  Install worked just didn't do the grub part...

Once I've rebooted into my VSIDO_GoTo and updated grub, then the new install boots from the VSIDO_GoTo grub menu.  Issues with the install.  I get the fstab problem of old where the sys hangs for a minute and a half which is an easy fix on this end. (I can see a new user getting a little frustrated about this)  Though this has probably been resolved here, still getting two speakers on the menu.py volume icon.  After the minute and a half hang, I had to Ctrl-D to continue.  It said that the login password was wrong? 

Just updated grub from this new install and a reboot will tell the tale...

[VastOne]

Thanks for testing and the feedback Jedi

Yes the April 2nd is the current testing version we are all using

When I Ctrl-D after the 90 seconds I just let it boot and then it gets to a login screen.. is that where you are seeing the PW as wrong, at the normal login screen?

All the issues you saw I am aware of and am now working on resolving them

For me... I am perplexed.. I can successfully install and on the first reboot from the installation V-Box sees grub and efi and all is good... but once I shut the session down and reboot, V-Box no longer sees the efi partition.. Does the efi partition need to be anything special other than fat16? Does it need to be sda or sda1? Does it need to be flagged as a boot device from gparted? I can go into the v-box settings of efi and switch around the boot order but the only thing that seems to consistently boot efi is the ISO and NOT the installed VSIDO with efi

[jedi]

Does the efi partition need to be anything special other than fat16? Does it need to be sda or sda1? Does it need to be flagged as a boot device from gparted? I can go into the v-box settings of efi and switch around the boot order but the only thing that seems to consistently boot efi is the ISO and NOT the installed VSIDO with efi

Just wanted to be sure on the correct ISO to be testing.  It is the one I'm using as well.  A Ctrl-D after the 90 sec's does indeed get me to the login screen...

Yes the /boot/efi partition should be fat32 imo, however if fat16 works thats cool too.  It should also be noted that that partition will need the boot flags 'esp' and 'boot' selected.  Not sure if that'll fix the V-box issues though...

I updated grub after booting into the new install the second time and it was successful.  However on reboot there is no entry for it in the UEFI boot list.  My regular GoTo grub menu got me back here to the new install.  Will keep puzzling for a little while.  Been a while since I had any fun...

[VastOne]

OK... I rebooted to a new install and set the partition as a boot drive and ran update-grub and now I am getting a reboot back to the new install

Thanks for that clarity.. Now I need to correct the net.ifnames=0 on the grub line so that there is network on the LiveCD and to add these parameters to the fstab entry to stop the 90 second delay

Code Select Expand

noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2

I will also eventually correct the vim/medit issue

Thanks for testing and helping out, it is greatly appreciated

[VastOne]

For those keeping score, these are the changes I had to make to the fstab to eliminate the 90 second timeout crap

My current /etc/fstab

Code Select Expand

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>

proc   /proc   proc   defaults   0   0
# /dev/sda2
UUID=63881c3d-95b7-49b8-986c-f767c13701ae   /   ext4   noauto,x-systemd.automount,x-systemd.device-timeout=2 0 2
# /dev/sda1
UUID=B13B-925B   /boot/efi   vfat   auto,users,rw,quiet,umask=000,shortname=lower,x-systemd.automount,x-systemd.device-timeout=2  0   0

[jedi]

you can probably axe the 'proc' line as well.  I simply deleted the swapfile line in fstab and it solved the 90 sec issue...

[VastOne]

I do not have a swap file setting.. the error is coming specifically from the efi boot line

Code Select Expand

vfat   auto,users,rw,quiet,umask=000,shortname=lower

Edit  Adding this to the line above is all that is needed to stop the 90 second timeout (on my end)

Code Select Expand

x-systemd.automount,x-systemd.device-timeout=2

So the line should be:

Code Select Expand

auto,users,rw,quiet,umask=000,shortname=lower,x-systemd.automount,x-systemd.device-timeout=2  0   0

The exact same setup does not have this error on normal VSIDO without uEFI..

And there is nothing I can do to change it during the installation.. it is something that needs to be added or edited after the install