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
# 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
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 systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel
