@VastOne:

Updated How-To is spot on, except that the entire "After installation" section is redundant and no longer needed ( since installer v7.0.7~fd2 ).

Also, "bricks" module is not used in VSIDO ( and cannot be used, without modifications ), so you might as well remove it's section to keep things simpler. 

Quote from: jedi on April 06, 2017, 08:55:29 PM

Quote from: filip on April 06, 2017, 08:16:29 PM
@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.

@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! ):
...
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:

QuoteI 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

Quote from: VastOne on April 05, 2017, 04:56:40 PM
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:

Thanks for testing mate!

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

Quoteyou 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:

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

QuoteDoes 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

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

QuoteI 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 )?

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

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

Hmm, "mkfs" is still bitching over here.  Though I'm starting to think it might be related to VBox or current kernel, or either.
The weirdest part is that it works normaly on TRIOS/Jessie and when called manualy from terminal, yet the very same call from installer makes it go blind ( see screens ). 

I'd be glad if someone with actual hardware would test and drop a note on how it went, since there's really no (obvious) reason in the installer itself for something like this to ever happen.

Besides that, everything else looks good, including the config package, UEFI/Grub, network conf etc...
Though I'll hold back the push to stable for a while, until we can find the cause for the "mkfs" lunacy, or at least rule it out on the real hardware!

Quote from: VastOne on April 02, 2017, 10:05:20 PM
^ Yes.. that particular uEFI ISO is very old and was designed to help one user with nvme

The tool I use to build (refracta) has been updated with uEFI support so it should go easier

I'll build some new ones later this week

I'll fix the VIM issue

Thanks mate..

No problem, great!

@Installer:

Allright, config is pushed and packaged ( in testing brach atm ).
From now on you should be able to simply do a "clone --> build packages --> install" without editing anything.
That is unless I missed something. Will recheck tomorow hopefully, and if all is ok push to master & release.

Changes are:

1. There's now a "vsido-net-interfaces" file that gets copied to "/etc/network/interfaces" -- no need to mess with network module py files anymore.
2. Updated "grub_cmdline_linux" option ( corectly sets "net.ifaces=0" )
3. rEFInd installation disabled -- no need to mess with bootloader module...

And all of that is neatly packaged into "linstaller-config-vsido" .deb, which btw conflicts with "linstaller-config-trios" ( it's a mutual conflict actualy ), so that only one of them can be installed at a time, for the obvious benefits of all parties involved.

For details, take a look here. 

Update:

Installing VSIDO UEFI is, umm, mostly fine.
After working around a couple issues it's installed properly using latest installer and config files from the (old) How-To. 

Issues @live:

1. net.ifaces=0 is missing from grub/kernel line, resulting in missing network ( in VBox ). Adding it manually solves the issue.
2. For some weird reason, mkfs is refusing to format any drive when called from installer ( compains that "/dev/xyz" doesn't exist, when it obviously does ). Calling it manualy from terminal works. 

Issue booting installed system:
1. local-filesystems.service fails trying to mount some UUID's I haven't actually seen exist at all. However, after it spends it's 1min30sec limit system boots normaly.

Now, I'll assume that atleast the mkfs issue stems from maybe SID being a b*tch at the time of ISO build, @Oct 2016. Unless I missed a newer ISO?

Nitpick:
1. You might wanna associate text files with Medit, since Vim is the current default, and it doesn't run when opening a file from SpaceFM ( Vim's .desktop file issue maybe? ). 

All in all, it's looking good, but the mkfs kinda rubbed me the wrong way...
It would be great if you have the time to build a fresh UEFI ISO so that we can, hopefully, learn that it was just a temporary Sid quirk.

EDIT:

QuoteHello Filip.. I have updated the How to with everything we have discussed including these files that I will include here for you

it is looking good.. Thanks mate!

Awesome, thanks! Will be in git soon.

Quote from: VastOne on April 02, 2017, 12:03:09 AM
Thank you Filip... Regarding eUFI I have a separate build environment just for that... so it is easy enough to implement what is needed on each

I appreciate it.. when I get this done I will send you the vsido base files that I have to edit if you want to include them

Cheers!

You're most welcome! 

@VSIDO UEFI:
Cool! Found & downloaded... 

@config files:
What I need is:
- /etc/linstaller/vsido
- /etc/linstaller/vsido-base
- /etc/network/interfaces

You can just paste them in a post ( easier to copy ) or don't bother if ones in the current How-To are up to date, I'll use them. 

@Changes:
Done! Network and Bootloader/rEFInd!

Btw, don't bother testing them yet, they don't apply without updated configs!

Quote(and some good coffee too)

...

QuoteProgrammer is an organism capable of converting coffee into software

Or, as I sometime like to put it:

QuoteNo bug can survive a good dosage of caffeine

---

QuoteRegarding the refind section.. with these changes to add uefi and nvme is it still necessary for me to continue to do this?

Commenting just these should be enough:

1. Currently line No.355, @/usr/share/linstaller/linstaller/modules/bootloader/inst/_init_.py
self._refind_inst = {"grub":self.install.refind_install}

2. Currently lines No.53--55, @/usr/share/linstaller/linstaller/modules/bootloader/inst/glade/_init_.py
# PASS 5: Install REFIND
self.parent.progress_set_text(_("Installing REFIND..."))
self.parent.moduleclass._refind_inst[bootloader]()
self.parent.progress_set_percentage(5)

Btw, I'll postpone the How-To update for a little bit, since this^ commenting stuff out should really be dealt with properly, including the additions in "network" module.
In other words, I'll put both behind config options, so no code editing will be needed. Then the How-To will follow. 

EDIT:

On the side note, in the existing How-To, you said:

QuoteEdit these files to take care of eufi refind that is not a part of VSIDO (yet)

And looking inside VSIDO ISO I don't see any "efi" images, leading me to think that VSIDO doesn't actually support UEFI!? If so, you don't need to comment REFIND related lines, since they're not gonna be called anyway ( they're called only when booted in UEFI mode ).

Also, if you'd like, I can put into git and package VSIDO linstaller config files ( "/etc/linstaller/vsido*" into eg. "linstaller-config-vsido_all.deb )??
The benefit here would be that:
- You would not need to worry about manually updating config when needed, like it was with "custom_kernel_args" preseed and will be with the incoming refind/network stuff,
- I can make code, and when it's necessary, config changes and know I've came full circle with that particular change/improvement.

QuoteAnd finally I cannot recall where this is even at.. (my bad memory)

Quote

    If I recall corectly "custom_kernel_args" is used in VSIDO to force persistent network names!?
    If so, it needs to be replaced by either "grub_cmdline_linux" or "grub_cmdline_linux_default" ( or both )!

@/etc/linstaller/vsido-base 

I forgot completely, sorry. 
Yes, it has moved from TRIOS group to my own.

I'll update the How-To properly hopefully tonight, but in the mean time, quick fix is to replace "trios-linux" in links for installer, bricks, keeptalking etc with "Cofi".
Thus:
git clone https://gitlab.com/trios-linux/trios-installer.git
Becomes:
git clone https://gitlab.com/Cofi/trios-installer.git

Also, this time latest version of installer is in the master branch, so:
git checkout testing
is no longer needed. 

Hello VSIDO community,

It took a while, but better late then ever, trios-installer 7.0.7 has landed in master. 

In short, new/fixed stuff:
  1. Support for NVMe drives
  2. Workaround for issue #5 ( root pass was not set if it existed on live system ( as it does on VSIDO ))
  3. Fixed "bug" in automatic partitioning by explicitly depending on "os-prober". Bug was that auto partitioning quetly only ever offered
      a complete disk wipe, instead of additionaly finding ( using "os-prober" ) existing distributions to replace.

Merged from upstream:
  1. GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX are now preseedable ( important for VSIDO, see bellow )
  2. User groups are now preseedable ( both default and additional ones )
  3. Improved support for Mac's

For full changes list, please take a look here. 

---

@NVMe:

Since I don't have the actual hardware to test properly, support for NMVe is fully tested on VBox only.
Even with that, it should be in good shape because it didn't require masive changes/additions, however usual caution
( backups/double checking summary before hiting "Forward" to begin install etc ) when installing on real hardware is still advised!

One known issue so far is that installer doesn't warn the user that, on legacy BIOS systems, booting from NVMe will fail!
Instead, it will happily perform the installation, but the system won't be bootable, 'cause AFAIK, no legacy BIOS supports booting
from NVMe devices.
This also applies to some older UEFI systems, however I don't think that there is a way to check this from installer or linux itself.

So, if you're about to buy NVMe SSD, and use it as the only drive in the system, be sure to verify that your BIOS can boot from it!
Otherwise, make sure that besides NVMe drive, you have:
- A regular hard drive/usb flash/SD card --> For legacy BIOS to boot from, if MBR partitioning scheme is employed
- A "/boot" partition on a regular hard drive/usb flash/SD card -- For legacy BIOS to boot from, if GPT partitioning scheme is employed
- Or "/boot/efi" partition on a regular hard drive/usb flash/SD card -- For UEFI's

And ofc, feedback on NVMe would be really apreciated!! 

@GRUB_CMDLINE_LINUX_DEFAULT and GRUB_CMDLINE_LINUX:

In favor of upstream and this better and more granular implementation, I've dropped the "custom_kernel_args" preseed.

If I recall corectly "custom_kernel_args" is used in VSIDO to force persistent network names!?
If so, it needs to be replaced by either "grub_cmdline_linux" or "grub_cmdline_linux_default" ( or both )!

The difference between the two is that parameters in "grub_cmdline_linux" are passed to kernel in both normal and recovery boot modes,
while ones in "grub_cmdline_linux_default" are passed to kernel only for normal (default) boot.

---

Installer future:

Due to some real life craziness I've been AFK for a while, and as it seems, probably will be again.
"AFK" here means I simply don't have enough free time to actualy think about cool stuff/improvements,
let alone sit down to implement them ( and when I think I finally do, for some ungodly reasons I get proven otherwise ).

So, until that gets sorted, in the nutshell:
- Installer will be in maintanance mode only == timely fixes for serious issues ( please do report, if any is encountered! )
- Feature requests are of course welcome, however beware that it might take a while for me to get to them.

Cheers,
Filip

@live-boot:

@VastOne:

I guess you're not using a "*-packages.remove" file with the installer?

If so, live-* packages ( live-boot in particular ) are/is 99.9% the culprit here.

Easiest fix would be to:
1. List "live-config/live-boot/live-*" packages in "/etc/linstaller/vsido-packages.remove"  ( one per line ),
2. And add to "/etc/linstaller/vsido-base" config:
[module:debian]
remove = /etc/linstaller/vsido.packages-remove
autoremove = True
# autoremove is not mandatory here, however if you do enable it, check the log after the install
# to make sure it didn't remove some package(s) it shoudn't have!!!

That way installer will remove listed packages during the installation, which should solve initramfs problems for good/everyone.

live-boot/config stuff is completelly useless outside of live system, and can cause problems like this ( I can't remember now which, but there is atleast one program, besides initramfs, that relies on existence of "/lib/live" dir to establish whether or not it's running in live, thus having live-* installed will make it "think" it is ).