As promised in the installer topic, I've pushed the connman-gtk to git, including debian packaging and a small patch allowing main window to be toggled by clicking the tray icon.



For details and more screenshots see: https://gitlab.com/Cofi/connman-gtk

Build instructions:

1. Clone & cd:
git clone https://gitlab.com/Cofi/connman-gtk.git && cd connman-gtk

2. Install build deps:
mk-build-deps --install ./debian/control      # if "mk-build-deps" is missing install "devscripts" package first

3. Build and install:
dpkg-buildpackage -j$(nproc)
cd ../ && sudo apt install ./connman-gtk_1.1.1-2_amd64.deb

Enjoy & god-forbid there be any issues, let me know! 

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