Hi, "pelzflorian (Florian Pelz)" skribis: > I got a locked /etc/shadow again now despite Ludovic’s patches (which > would nonetheless give me a better feeling when pushed). Will do. :-) > When booting an unbootable generation with Ludovic’s patches and then > rebooting a normal generation with Ludovic’s patches, /etc/shadow is > locked. So with this scenario, the problem is 100% reproducible, right? > Note that I get a message like “/dev/mapper/Guix: recovering journal” > when booting (I did not pay attention to that before). I shut down > the unbootable generation with Ctrl+Alt+Del. When I normally shut > down with Ctrl+Alt+Del I get no such message. Indeed, ‘shepherd’ calls ‘disable-reboot-on-ctrl-alt-del’ (which disables “hard” reboots upon ctrl-alt-del and instead notifies it) after it has loaded its config file. In your case, loading the config file never completes because the ‘start’ method is called from the config file for every service, and one of them, udev, never starts. Thus, when you press Ctrl-Alt-Del, you perform a hard reboot. The hard reboot happens after Guix has written to /etc/shadow. One possibility is that changes to this file haven’t been flushed to disk. Thus, on the next boot, we start off with an empty or truncated /etc/shadow, leading the activation snippet to initialize passwords. If that theory holds, the patch below (on top of the others) should help. Could you give it a try? Actually, the fact that ‘rename-file’ was called *before* ‘close-port’ could be problematic in itself; so perhaps, even without the ‘fdatasync’ call, we’d get better results… especially since ‘fdatasync’ won’t be available in the initrd anyway, hmm… Thanks, Ludo’.