[Bug 1175850] MicroOS Desktop can't reboot?
https://bugzilla.suse.com/show_bug.cgi?id=1175850
https://bugzilla.suse.com/show_bug.cgi?id=1175850#c17
--- Comment #17 from Fabian Vogt
(In reply to Fabian Vogt from comment #15)
(In reply to Fabian Vogt from comment #14)
Created attachment 844939 [details] systemd debug logs
(In reply to Franck Bui from comment #13)
In reply to Fabian Vogt from comment #11)
So if unmounting /var needs udev, there's a cycle... Apparently cryptsetup@ units don't set a dependency on udev, so that's why it fails that way.
On boot there's no cycle, because /var and /etc are mounted from the initrd using the initrd's udev.
Then both /var and /etc are supposed to be unmounted in initrd, no ?
AFAICT the initrd is not used during shutdown currently.
I can trigger that manually by touching /run/initramfs/.need_shutdown only.
What do /etc/{fstab,crypttab} look like on the affected systems ?
I just installed MicroOS with encrypted / and /var partitions and was able to reproduce the problem.
f224:~ # cat /etc/crypttab cr_root UUID=1621a42e-c635-4b81-88a7-475267426692 none x-initrd.attach cr_var UUID=1d90dc3a-c9e2-4971-b8da-4751351c94a5
I can't reproduce the issue anymore with "none x-initrd.attach" added to the cr_var entry here. Can you confirm that?
yes, see man crypttab:
All other encrypted block devices that contain file systems mounted in the initramfs should use this option.
The /var+systemd-udevd cycle still exists
Why ? if both /var and /etc are setup in initrd, there shouldn't be any cycle with udevd (running in the host at least).
It's about shutdown. udevd needs /etc and /etc needs /var. Somehow unmounting /var triggers udev to start: [ OK ] Stopped Rule-based Manager for Device Events and Files. ... [ OK ] Unmounted /etc. ... Unmounting /var... ... shutdown.target: starting held back, waiting for: systemd-remount-fs.service umount.target: starting held back, waiting for: var.mount systemd-udevd-kernel.socket: Incoming traffic systemd-udevd.service: Trying to enqueue job systemd-udevd.service/start/replace ... Requested transaction contradicts existing jobs: Transaction for systemd-udevd.service/start is destructive (systemd-reboot.service has 'start' job queued, but 'stop' is included in transaction). systemd-udevd-kernel.socket: Failed to queue service startup job (Maybe the service file is missing or not a non-template unit?): Transaction for systemd-udevd.service/start is destructive (systemd-reboot.service has 'start' job queued, but 'stop' is included in transaction). ... [ OK ] Unmounted /var.
Your commit introducing the x-initrd.attach option (https://github.com/systemd/systemd/commit/ 1dc85eff1d0dff18aaeaae530c91bf53f34b726e) implies that the initrd is entered again on shutdown, but that doesn't seem to be triggered. Maybe the presence of x-initrd.attach should do that? It's not clear to me whether the device is still getting detached properly on shutdown.
Actually it's done by /usr/lib/systemd/systemd-shutdown, this binary will try to unmount all remaining file systems, disable all remaining swap devices, detach all remaining storage devices and kill all remaining processes, see man systemd-shutdown.
I'm not getting any log output from that though: [ OK ] Finished Reboot. Forcibly rebooting: unit systemd-reboot.service succeeded reboot.target changed dead -> active reboot.target: Job 567 reboot.target/start finished, result=done [ OK ] Reached target Reboot. Shutting down. systemd-journald.service: Releasing resources. systemd-journald.service: Releasing all stored fds [ 75.194224] BTRFS info (device dm-1): disk space caching is enabled [ 75.295280] reboot: Restarting system [ 75.298847] reboot: machine restart -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com