Sysvinit works, Systemd doesn't [Solved]

[zoli62]

Here is output of journalctl -bx https://pastebin.com/raw/JfC1X6Ns

Well done. Looks like a dmesg equivalent. It doesn't look good, but I don't speak "systemd." I expect someone else may be able to help.

Because I knew MX Linux ai a systemd-free distribution, I probably never tried to start MX Linux with systemd, only now, after upgrading to MX 21, when the problem arose that the network manager is not running, so the network-manager-sysvinit-compat package had to be installed. Only then did systemd come into play. So I don't really know if booting with systemd ever worked at all or not. It is also possible that booting with systemd worked after the original installation, but not after the system upgrade. One of the biggest advantages of Debian is that you can keep upgrading from an older release to a new one without reinstalling. On MX Linux, I've updated the system twice, as I'm used to with Debian, but I'm aware that this obviously increases the chance of an error.

[siamhie]

What's the output of "systemctl status" ?

[asqwerth]

In MX21 KDE I understand that the network manager is disabled upon every reboot, unless you change the settings so that network is enabled for ALL users. A user who upgraded from MX19 KDE to 21 may not have that setting enabled in network manager.

I wonder if something similar is at work in respect of your twice-upgraded MX (18 to 19 to 21). You would have moved from xfce 4.12 to 4.14 to 4.16, among other things. Some config/setting might be different now. Or some new package needed in later releases has not been installed.

Since MX is not a pure systemd-only Debian derivative, and has various packages to ensure that the Debian base can work with either sysV or systemd, repeated upgrades to newer Debian bases (where the systemd tendrils may have spread) will certainly increase the chance of error.

[zoli62]

Can you do a clean install, but preserve /home? Unless it's encrypted, you can preserve home with the MX installer, even if it's on the root partition.

Thanks, I know this method, it came in handy during one of the system upgrades, but now there are several well-functioning and configured distributions on the machine with multiple boot, so I wouldn't mind if that, but obviously I'll try it on a next installation. although in this case the root partition obviously does not need to be formatted if it also contains the home directory, which can obviously cause errors again after installation.

[zoli62]

What's the output of "systemctl status" ?

● mx
State: maintenance
Jobs: 0 queued
Failed: 0 units
Since: Fri 2021-11-26 04:37:04 CET; 3min 9s ago
CGroup: /
├─init.scope
│ └─1 /lib/systemd/systemd
└─system.slice
├─haveged.service
│ └─1059 @usr/sbin/haveged --Foreground --verbose=1
├─systemd-udevd.service
│ └─349 /lib/systemd/systemd-udevd
├─nfs-mountd.service
│ └─1102 /usr/sbin/rpc.mountd --manage-gids
├─systemd-journald.service
│ └─329 /lib/systemd/systemd-journald
├─nfs-blkmap.service
│ └─343 /usr/sbin/blkmapd
├─rpcbind.service
│ └─1061 /sbin/rpcbind -f -w
├─nfs-idmapd.service
│ └─1047 /usr/sbin/rpc.idmapd
└─emergency.service
├─1116 /lib/systemd/systemd-sulogin-shell emergency
├─1117 bash
└─1120 systemctl status

[zoli62]

In MX21 KDE I understand that the network manager is disabled upon every reboot, unless you change the settings so that network is enabled for ALL users. A user who upgraded from MX19 KDE to 21 may not have that setting enabled in network manager.

I wonder if something similar is at work in respect of your twice-upgraded MX (18 to 19 to 21). You would have moved from xfce 4.12 to 4.14 to 4.16, among other things. Some config/setting might be different now. Or some new package needed in later releases has not been installed.

Since MX is not a pure systemd-only Debian derivative, and has various packages to ensure that the Debian base can work with either sysV or systemd, repeated upgrades to newer Debian bases (where the systemd tendrils may have spread) will certainly increase the chance of error.

You will most likely be right. This may be evidenced by the fact that I had a package dependency error in the middle of the system update, the broken packages had to be repaired first, and then the installation continued, but this could have resulted in an unhealthy updated system. Perhaps this is also the reason why starting with systemd failed. So I'm not going to work any further. Probably a new installation keeping the home directory wouldn't solve the systemd problem for sure, just a clean installation.

[siamhie]

What's the output of "systemctl status" ?

● mx
State: maintenance
Jobs: 0 queued
Failed: 0 units
Since: Fri 2021-11-26 04:37:04 CET; 3min 9s ago
CGroup: /
├─init.scope
│ └─1 /lib/systemd/systemd
└─system.slice
├─haveged.service
│ └─1059 @usr/sbin/haveged --Foreground --verbose=1
├─systemd-udevd.service
│ └─349 /lib/systemd/systemd-udevd
├─nfs-mountd.service
│ └─1102 /usr/sbin/rpc.mountd --manage-gids
├─systemd-journald.service
│ └─329 /lib/systemd/systemd-journald
├─nfs-blkmap.service
│ └─343 /usr/sbin/blkmapd
├─rpcbind.service
│ └─1061 /sbin/rpcbind -f -w
├─nfs-idmapd.service
│ └─1047 /usr/sbin/rpc.idmapd
└─emergency.service
├─1116 /lib/systemd/systemd-sulogin-shell emergency
├─1117 bash
└─1120 systemctl status

In the log you posted, I caught these errors.

[zoli62]

What's the output of "systemctl status" ?

● mx
State: maintenance
Jobs: 0 queued
Failed: 0 units
Since: Fri 2021-11-26 04:37:04 CET; 3min 9s ago
CGroup: /
├─init.scope
│ └─1 /lib/systemd/systemd
└─system.slice
├─haveged.service
│ └─1059 @usr/sbin/haveged --Foreground --verbose=1
├─systemd-udevd.service
│ └─349 /lib/systemd/systemd-udevd
├─nfs-mountd.service
│ └─1102 /usr/sbin/rpc.mountd --manage-gids
├─systemd-journald.service
│ └─329 /lib/systemd/systemd-journald
├─nfs-blkmap.service
│ └─343 /usr/sbin/blkmapd
├─rpcbind.service
│ └─1061 /sbin/rpcbind -f -w
├─nfs-idmapd.service
│ └─1047 /usr/sbin/rpc.idmapd
└─emergency.service
├─1116 /lib/systemd/systemd-sulogin-shell emergency
├─1117 bash
└─1120 systemctl status

In the log you posted, I caught these errors.

Yes, I also saw these errors in the log. It is probably not possible to fix the bugs without a clean reinstall (leaving the home directory during the installation is probably not a good solution either), but it is interesting that everything works fine when started with sysvinit.

[dolphin_oracle]

I wonder if the systemd-fstab-generator or maybe the systemd-gpt-generator is failing. I tend to think its the second, since a swap file is also referenced.

maybe make an empty file

Code: Select all

sudo touch /etc/systemd/system-generators/systemd-gpt-auto-generator

and reboot. can't hurt to try.

[Huckleberry Finn]

I know, you meant "sudo touch" :)