[systemd-devel] default.target and external symlinks

[Alexander Sbitnev]

  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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20201223/4440d5c9/attachment.htm>