Current solution relies on usermod -G $grpname -a $username (notably -a -- which does not exist in all system toolkits).

If time comes, fix this to use a new helper script with a more complex but portable solution to find all the secondary groups the user is a member of, and pass the standard usermod -G $grp,name,list $username command. Scripting elements can be found in setup/10-bios-gpio.sh scriptlet.

See #333 for more context

It would make more sense to support a conf.d style directory for calling additional diags tools scripts, and provide the support for collecting data on vendor-extensions there, separately from common FOSS scope.

FYI: Based on our old suggestion to snoopy, there was recent progress with issue a2o/snoopy#200 so their current git master should be more functional for logging systemd units.

It would be helpful to spin an experimental branch to check if it works and solves 42ity dev/test logging more neatly than it was addressed before, and tell the snoopy team if this feature is good.

If I run:
update-rc3 -R -FF -U <1.5.0 image>
on 1.5.1 version, the script reports success and triggers reboot, but after the system boots again, it's still running 1.5.1 version. Factory reset works as expected.
Forceflash flag probably should allow downgrade, and if we decide it shouldn't, the script should return error.

Sometimes Linux loopback gets stuck with a loop device that can not be managed - neither destroyed nor removed. This then blocks re-mounting of e.g. same squashfs image for different VMs or even reusing it for a single new one. Host has to be rebooted to clear that state. Different images can be used however.

CI-RESETVM-INFO: /root/ci-reset-virtual-machine.sh:
    Creating a new VM rootfs at '/srv/libvirt/rootfs/fty-upstream-devel'
CI-RESETVM-INFO: /root/ci-reset-virtual-machine.sh:
    Mount the common RO squashfs at
    '/srv/libvirt/snapshots/../overlays-ro/fty-devel-image-18.01.05-10.09.04+1_x86_64_fty-devel_x86_64_upstream.squashfs-ro'
mount: /dev/loop1 is already mounted or
    /var/scratch/_lxc/_srv_libvirt/overlays-ro/fty-devel-image-18.01.05-10.09.04+1_x86_64_fty-devel_x86_64_upstream.squashfs-ro busy
CI-RESETVM-FATAL: /root/ci-reset-virtual-machine.sh: Can't mount squashfs

This is documented quite a lot over the years, so is a system issue. Maybe ci-reset-virtual-machine.sh can do something to try to avoid it however - e.g. if it is discovered how to trigger the issue.

Also update the code which processes this data (OS image init, sysinfo, maybe others?) to consider two different files.

See #333 for context