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

[filip]

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

[VastOne]

Great news Filip...

I started the process to build again but I think the How To Build the VSIDO Trios Installer is now obsolete or files have moved

On any of the git clone commands I run it is wanting a login and password.. Do you know what needs to be used now?

Thanks

[VastOne]

Logging in with my account shows:

Code Select Expand

fatal: repository 'https://gitlab.com/trios-linux/keeptalking.git/' not found

So everything has moved around it seems

[filip]

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:

Code Select Expand

git clone https://gitlab.com/trios-linux/trios-installer.git
Becomes:

Code Select Expand

git clone https://gitlab.com/Cofi/trios-installer.git

Also, this time latest version of installer is in the master branch, so:

Code Select Expand

git checkout testing
is no longer needed. 

[VastOne]

^ No worries Filip ... got it installed with Cofi (and some good coffee too)

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

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

Code Select Expand

sudo medit /usr/share/linstaller/linstaller/modules/bootloader/inst/_init_.py

Find and comment out these lines:

Code Select Expand

def refind_install(self):
""" Install REFIND """

if "uefidetect.inst" in self.moduleclass.modules_settings and self.moduleclass.modules_settings["uefidetect.inst"]["uefi"] == True:
verbose("Installing refind...")
m.sexec("/refind-inst.sh")
else:
pass
         
and comment this line in same file:

Code Select Expand

self._refind_inst = {"grub":self.install.refind_install}
         
and finally

Code Select Expand

sudo medit /usr/share/linstaller/linstaller/modules/bootloader/inst/glade/_init_.py

Find and comment out these lines (53,54 and 55)

Code Select Expand

                          #Pass 5: Install Refind
        self.parent.progress_set_text(_("Installing REFIND..."))
self.parent.moduleclass._refind_inst[bootloader]()
self.parent.progress_set_percentage(5)

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

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 )!

[filip]

(and some good coffee too)

...

Programmer is an organism capable of converting coffee into software

Or, as I sometime like to put it:

No bug can survive a good dosage of caffeine

Regarding 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

Code Select Expand

self._refind_inst = {"grub":self.install.refind_install}

2. Currently lines No.53--55, @/usr/share/linstaller/linstaller/modules/bootloader/inst/glade/_init_.py

Code Select Expand

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

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

And 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 

[VastOne]

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!

[filip]

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!

[VastOne]

Hello 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!

    /etc/linstaller/vsido

Code Select Expand

## MAIN LINSTALLER CONFIGURATION FILE FOR VSIDO

[linstaller:extends]
source = vsido-base

# Do not ask for language, use the system's one instead.
#[module:language]
#ask = False

# Do not ask for timezone, use the system's one instead.
#[module:timezone]
#ask = False

# Disable root
#[module:userhost]
#root = None

   /etc/linstaller/vsido-base

Code Select Expand

## BASE LINSTALLER CONFIGURATION FILE FOR VSIDO -- END USER WILL NOT (HOPEFULLY) NEED THIS

[linstaller]
distribution = VSIDO
modules = uefidetect.inst welcome.front language.front timezone.front userhost.front partdisks.front bootloader.front summary.front partdisks.inst unsquash.inst virtualpartitions.inst language.inst timezone.inst network.inst supportrepo.inst bootloader.inst userhost.inst debian.inst clean.inst fstab.inst finish.inst end.front
special = partdisks.inst unsquash.inst virtualpartitions.inst

[module:language]
ask = True

[module:timezone]
ask = True
timezone = Etc/GMT

[module:partdisks]
swap_noformat = True

[module:unsquash]
image = /lib/live/mount/medium/live/filesystem.squashfs

[module:debian]
remove = /etc/linstaller/trios.packages-remove
autoremove = True

[module:bootloader]
bootloader = grub
custom_kernel_args = grub_cmdline_linux
should_hide_menu = False

[module:supportrepo]
path = file:///lib/live/mount/medium/support
binarydir = ./

[filip]

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:

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

[VastOne]

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

[filip]

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

[VastOne]

Excellent work Filip!

I have uploaded the uEFI ISO's that can be downloaded here

Anyone with uEFI and/or nvme hardware can use these and both installers should work

[filip]

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!

[VastOne]

I have the same issues with V-Box and it not seeing the installation but it most likely has to do with grub-efi is not being installed correctly to the new installation..  I am pretty sure I can chroot into the new install from the LiveCD and manually install grub-efi and and update-grub everything would be fine

I am like you, I have no real efi hardware and will wait until someone with it reports back