Hi there! I am trying to use upcoming Debian 11 Bullseye with read-only root filesystem. And I discovered SystemD behaviour change compared to Debian 9. It is not related to read-only root by itself and can be easily reproduced with a normal installation. With new Debian 11 SystemD (247.1-3) it is not possible to use chain of symlinks from /etc/systemd/system/default.target to choose target if chain include elements outside of SystemD directories (/etc/systemd/system/ or /lib/systemd/system/). For example next chain work fine: /etc/systemd/system/default.target -> default.redirect.target -> /lib/systemd/system/default.test.target -> /lib/systemd/system/multi-user.target
And if I move default.redirect.target from /etc/systemd/system/ to /etc/ system will not boot correctly. Problematic chain looks next way: /etc/systemd/system/default.target -> /etc/default.redirect.target -> /lib/systemd/system/multi-user.target Chain by itself looks valid: root@deb11tiny:/etc/systemd/system# cat /etc/systemd/system/default.target # SPDX-License-Identifier: LGPL-2.1-or-later # # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Multi-User System Documentation=man:systemd.special(7) Requires=basic.target Conflicts=rescue.service rescue.target After=basic.target rescue.service rescue.target AllowIsolate=yes root@deb11tiny:/etc/systemd/system# systemctl get-default multi-user.target And system actually booting. And SystemD seems to know which target it should boot as I can see in output next lines: ... [ 4.508581] systemd[1]: Queued start job for default target Multi-User System. ... [ OK ] Reached target Multi-User System. But the booted system will get most of its units inactive. Network, sshd... even gettys stays unstarted. Is it a problem with Debian SystemD build? Or is it correct behaviour? If this behaviour is unexpected I can supply any additional info but I don't know there to put it. Should I open a new bug in Debian tracker and put it there or can I just share it from cloud storage and supply a link to this list? Another interesting note to add: manually adding "systemd.unit=multi-user.target" to boot params allows the system to boot normal. So it definitely looks like a bug to me.
_______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
