Fix dev-branch installer to work on Debian Testing ("Bookworm")

[stevemoca]

The FOG installer in dev-branch can install FOG server on Debian Testing ("Bookworm"), when invoked as follows:

linuxReleaseName=Debian OSVersion=12 OSMinorVersion=0 ./installfog.sh

Unfortunately, the installer installs the sysv-rc-conf package, which breaks systemd. This prevents the FOG service units from working, effectively crippling the FOG server.

I have created a pull request (#530) that proposes a simple solution: Modify the installer to not install sysv-rc-conf on Debian hosts. This works because sysv-rc-conf is not used on Debian hosts anyway, since service control is done using systemd tooling.

[Sebastian-Roth]

@stevemoca Thanks for this issue report an the pull request!

Unfortunately, the installer installs the sysv-rc-conf package, which breaks systemd. This prevents the FOG service units from working, effectively crippling the FOG server.

Can you provide some more details on the issues sysv-rc-conf is causing, e.g. error messages?

I have thought about removing the legacy SystemV stuff completely but have not had the time to do so. Now that we seem to run into trouble with this it might be time to do so. I am not sure if any current Linux OS still uses SystemV, Debian and Ubuntu definitely don't use it since many years.

Would you be able and willing to update the PR to remove all references to legacy SystemV from the installer scripts?

[stevemoca]

@Sebastian-Roth Thanks for reviewing my submissions. My responses are below.

Can you provide some more details on the issues sysv-rc-conf is causing, e.g. error messages?

I think the title I gave this issue is perhaps a bit misleading. The dev-branch installer does not crash out dramatically, or otherwise fail to install the FOG server on a Debian Testing ("Bookworm") host, in any obvious way. The installer does run to completion successfully, and the server does appear to function normally, at first. The breakage of the install is obscured by the fact that systemd continues to function (more or less) correctly until the server is rebooted.

After a reboot, the init (PID 1) process is no longer systemd. So if you try to query or control services via the systemctl tool on the command line, you get errors such as, e.g.:

root@fog:~# systemctl status
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

The FOG service units (e.g. FOGScheduler, FOGMulticastManager, FOGImageReplicator, etc.) all fail to start at boot time, because they are defined as systemd service units, and these units only work when systemd is the init system.

Looking at the installation log (bin/error_logs/fog_error_1.5.9.235.log), I believe the issue is explained by this snippet of the log:

...
sysv-rc-conf
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  initscripts insserv libcurses-perl libcurses-ui-perl orphan-sysvinit-scripts
  startpar sysv-rc sysvinit-core
Suggested packages:
  bootchart2 bootlogd
The following packages will be REMOVED:
  dbus-user-session libpam-systemd systemd-sysv
The following NEW packages will be installed:
  initscripts insserv libcurses-perl libcurses-ui-perl orphan-sysvinit-scripts
  startpar sysv-rc sysv-rc-conf sysvinit-core
0 upgraded, 9 newly installed, 3 to remove and 0 not upgraded.
Need to get 686 kB of archives.
...

So it turns out that installing sysv-rc-conf removes systemd-sysv and adds initscripts, orphan-sysvinit-scripts, and sysvinit-core. The net effect of this is to change the init system from systemd to System-V. It is easy enough to change it back by reinstalling the systemd-sysv package, which causes the System-V packages (including sysv-rc-conf) to be removed.

The PR I submitted (#530) has merely the effect of avoiding the installation of sysv-rc-conf in the first place (specifically, on Debian hosts only).

Would you be able and willing to update the PR to remove all references to legacy SystemV from the installer scripts?

I will have a look and see what I can do, but I'm not promising anything!

[Sebastian-Roth]

@stevemoca said:

After a reboot, the init (PID 1) process is no longer systemd.

Good heavens! I didn't expect that to happen. Thanks heaps for bringing this issue up and your detailed description. We highly appreciate this.

I will have a look and see what I can do, but I'm not promising anything!

As mentioned in the PR code review I suggest we get the initial problem fixed for bookworm and later on remove the rest.

[Sebastian-Roth]

@stevemoca PR merged, thanks again.