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

[VastOne]

I have finished building and testing a new ISO for testing uEFI hardware and it has been uploaded to the test download page

As stated above the 90 second delay can be solved after the install with an edit to fstab

I have corrected the issue with net.ifnames=0 on the grub line so now the LiveCD session does have a correct network setup and internet access

Anyone testing this be sure to remember to create the 30-100 MiB fat16 or fat32 partition and the installer will set it up for you. I am assuming that since Jedi is confirming than nvme is working since he got it to install .. (Did you use the new installer Jedi?  The Trios/VSIDO new one?) ... You must also run an update-grub on your new install as soon as you boot to it (after the vsido-welcome and before a reboot)

[filip]

@Jedi:

Thanks for testing mate!

Please do post the installation log for me to take a look at. It's at "/var/log/installation.log".

you can probably axe the 'proc' line as well.

I think that /proc is actually a must for the "update-grub" to find partitions/mount info.
At least I was never able to restore/reinstall GRUB from a live system without binding it to the mounted root first ( eg mount --bind /proc /path/to/root/partition/proc ).



@VastOne:

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...

Likewise/confirmed. 

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?

- AFAIK, it should be (any) FAT, most likely because every BIOS will support it.
- Should be a first one ( sdX1, nvmeXnXp1 etc ), though not a must, however the same "support issue" as above still applies.
- Yes, it needs "esp" flag to be set, which is what Parted/Gparted actually does when you set a "boot" flag.

Installer-wise, it sets the "boot" flag using parted itself, so that's unlikely to be the cause ( see here, @line 509 )

@fstab

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

That won't be too hard to implement as preseed ( including the entire "options" part of "fstab" for every file system available ).

I have finished building and testing a new ISO for testing uEFI hardware and it has been uploaded to the test download page

Looking good! 
Btw, should another build be required while we're debuging these issues, may I ask you to build with VBox Guest Additions ( I'm sorely missing the shared clipboard when fixing/testing installer stuff on a live system )?

[VastOne]

I have a good understanding of the preseed methodology and what it can do but have never used one in the installer to know how to make the changes.. I could use a How To on it if there is one. I did a search and have found very little info on it

Regarding the Guest Additions, can't you just install them on your end with the ISO? they add a huge amount of space to the ISO if I include them

[filip]

I have a good understanding of the preseed methodology and what it can do but have never used one in the installer to know how to make the changes.. I could use a How To on it if there is one. I did a search and have found very little info on it

Regarding the Guest Additions, can't you just install them on your end with the ISO? they had a huge amount of space to the ISO if I include them

Well, here's a somewhat sparse wiki page @Semplice, however, besides the short documentation of the existing preseeds, there's also the issue of missing ones, which occasionaly popup as needed ( like it's the case with "fstab", or was for rEFInd etc. ).
The only way around second one is to actually code them in, which is not hard per se, but it does requires basic knowledge of Python and installer internals.
I'm certanly willing to write a HowTo if you're up for it.

As an example, here you can see what it took to add the "copy specified file to /etc/network/interfaces" functionality I've added for VSIDO ("custom_net_ifaces" preseed):
https://gitlab.com/Cofi/trios-installer/commit/a7fedd9ddcc58244a5e3241c44332b666621a9ca

On the doc side, I will eventualy get to documenting and explaining existing preseeds, however that is not likely to happen soon.

@VBox GA:
Of course I can, however I need them in live mode, since there I'm testing and fixing the installer on-the-fly...
Anyway, it's not a must have, I've basically asked for this one time exception, mostly because it would make the ^work much faster and easier to do. 

[jedi]

@Jedi:

Thanks for testing mate!

Please do post the installation log for me to take a look at. It's at "/var/log/installation.log".

Attached is the log file Filip.

To be clear; Using the 02Apr ISO was very "painfully" installed.  The attached log file is from the successful install tonight of the 04Apr ISO.  This time the install went A LOT smoother.  It DID create the new UEFI entry in the NVRAM/BIOS. (vsido_x64 is the name of the uefi entry)  This worked at the first shot tonight on the new install.  Last time not so much.  In short, the install went perfectly (exceptions already mentioned by VastOne, and totally expected) including installing grub-efi-amd64 or grub-efi correctly.  Yes I did setup drives with gparted BEFORE running the installer to avoid the mkfs error.  After reboot, the expected 90 sec delay occurred.  Again, easily fixed.  I noticed a difference this time with the installer when choosing not to specify a swap partition.  On reboot, the 'swapfile' line was NOT in fstab as it was last time on the 02Apr ISO.

[jedi]

Oh yeah, IT BOOTS INSTANTLY!!!!   

So while VSIDO is my default goto OS,  I'm now switching to the "Testing" version of VSIDO! bwahahahahahaha... 

[VastOne]

@Jedi:

Thanks for testing mate!

Please do post the installation log for me to take a look at. It's at "/var/log/installation.log".

Attached is the log file Filip.

To be clear; Using the 02Apr ISO was very "painfully" installed.  The attached log file is from the successful install tonight of the 04Apr ISO.  This time the install went A LOT smoother.  It DID create the new UEFI entry in the NVRAM/BIOS. (vsido_x64 is the name of the uefi entry)  This worked at the first shot tonight on the new install.  Last time not so much.  In short, the install went perfectly (exceptions already mentioned by VastOne, and totally expected) including installing grub-efi-amd64 or grub-efi correctly.  Yes I did setup drives with gparted BEFORE running the installer to avoid the mkfs error.  After reboot, the expected 90 sec delay occurred.  Again, easily fixed.  I noticed a difference this time with the installer when choosing not to specify a swap partition.  On reboot, the 'swapfile' line was NOT in fstab as it was last time on the 02Apr ISO.

The only differences between the April 02 and the April 04 was the changes to make ifnames=0 added so that there was internet access on the LiveCD.. other than that everything was identical.. I know on the 04 I took more time with the partition setup and allowed the Installer to create and partition the /boot/efi drive that I had already created.  As Filip said it did apply the boot flag and all I had to do was an update-grub once I booted into it and all was well

The good thing is we are light years ahead of where we have ever been with uEFI and nvme technologies

Thanks for the assist Jedi it is appreciated

[filip]

@Jedi:

Thanks!
Log looks perfectly fine. No errors, and most importantly GRUB is corectly installed and updated ( btw, going by the log, there shouldn't be a need to update it manualy on first boot! ):

Code Select Expand

...
Installing for x86_64-efi platform.
Installation finished. No error reported.
...
Found Debian V-SID-O jedi (V-Ger) on /dev/nvme0n1p1
Found Manjaro Linux (17.0) on /dev/nvme0n1p5
Adding boot menu entry for EFI firmware configuration
done

I forgot it last time:

I simply deleted the swapfile line in fstab and it solved the 90 sec issue...

Installer doesn't support the swapfile at all, so unless we're looking at another "mkfs"-like wierdness, it couldn't have came from installer itself.



I've been quite busy in the last couple of days, so the actual fstab/mkfs work/investigation will have to wait for the weekend ( I'll also push a "connman-gtk" with some fixes and packaging to GitLab, so you can take it for a spin if you'd like ).
In the mean time, unrelated, but you might be interested to know that unfortunately Ignorant Guru is no longer developing SpaceFM, however there's now a fork and a new version at https://github.com/Teklad/spacefm-ng

[jedi]

@Jedi:

Thanks!
Log looks perfectly fine. No errors, and most importantly GRUB is corectly installed and updated ( btw, going by the log, there shouldn't be a need to update it manualy on first boot! ):

Installer doesn't support the swapfile at all, so unless we're looking at another "mkfs"-like wierdness, it couldn't have came from installer itself.

@filip, yes it went perfectly.  As you saw in the log, there was indeed no need of any grub finessing   With the 02Apr ISO it warned me about not choosing a swap file but that it was fine to proceed.  On the 04Apr ISO, this did not happen, and the line in fstab did not show up either. (mkfs? beats me) All in all, a pretty impressive result and jump forward for VSIDO...

My initial testing with the 02Apr ISO should probably be totally disregarded.  I did most of it in the garage.  Never a conducive work environment.  Turns out it's a lonely winter up here!  I really need some Spring...

[filip]

@Jedi:

Thanks!
Log looks perfectly fine. No errors, and most importantly GRUB is corectly installed and updated ( btw, going by the log, there shouldn't be a need to update it manualy on first boot! ):

Installer doesn't support the swapfile at all, so unless we're looking at another "mkfs"-like wierdness, it couldn't have came from installer itself.

@filip, yes it went perfectly.  As you saw in the log, there was indeed no need of any grub finessing   With the 02Apr ISO it warned me about not choosing a swap file but that it was fine to proceed.  On the 04Apr ISO, this did not happen, and the line in fstab did not show up either. (mkfs? beats me) All in all, a pretty impressive result and jump forward for VSIDO...

My initial testing with the 02Apr ISO should probably be totally disregarded.  I did most of it in the garage.  Never a conducive work environment.  Turns out it's a lonely winter up here!  I really need some Spring...

Great! 

@garage:
While I certanly understand where you're coming from, I do on the other hand have to differ about it not being a conducive work env. But I guess it depends on the actual garage ( I see mine as a den of sorts )... 



fstab preseed for EFI partition is now exposed and preset in "vsido-base" to "x-systemd.automount,x-systemd.device-timeout=2".
Details: https://gitlab.com/Cofi/trios-installer/compare/60e481752253d822c5b2baf67b40c54ae9d20eeb...a9aa560c1e14d08025e21110f496b1dbc04ff588

For now, preseed is applied only if EFI partition is formated with FAT16 or FAT32 (vfat actually)!
Can be easily extended for other FS's if the need be.

[VastOne]

HAHA  ... the garage at Jedi's is a definite place for the mind to relax and chill.. to the point of grand illusions          

A perfect install .. no delays, a perfect boot

And STILL less than three minutes even with new procedures during the installation


 


I also attached is the installation log of the install if you wanted to check it out

[filip]

HAHA  ... the garage at Jedi's is a definite place for the mind to relax and chill.. to the point of grand illusions          

Well, that explains it then... 

A perfect install .. no delays, a perfect boot

And STILL less than three minutes even with new procedures during the installation


 


I also attached is the installation log of the install if you wanted to check it out

Awesome! 

Though you might wanna recreate the partition table on that hdd ( via Gparted or installer ), to avoid potential issues in future testing. 

Code Select Expand

GUID Partition Table Header signature is wrong: be5608740128e852 != 5452415020494645

[jedi]

   Yes my 'garage' is definitely Kush.  My den, man-cave, secret hideout, etc.  It is especially Kush this weekend!  Totally unbelievable!! 

[filip]

Update @mkfs:

I'm perplexed and out of ideas really.   

Been sifting trough the installer for most of the evening --> found nothing obviously wrong. 
Heck, "partprobe" is being executed before every call to "mkfs", for the very reason of avoiding the issue we're seeing, which btw shouldn't be even needed, since we're just formating existing partitions, no changes were made to them or the partition table, warranting a need for "partprobe"...

[VastOne]

^ You say you do not see this on the Trios side right?  What distro level are they?

My thinking is this could be a SID issue ..