<div dir="ltr"><div>  Hi there!</div><div>  I am trying to use upcoming Debian 11 Bullseye with read-only root filesystem.<br></div><div>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.<br></div><div>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/).</div><div>For example next chain work fine:</div><div>/etc/systemd/system/default.target -> default.redirect.target -> /lib/systemd/system/default.test.target -> /lib/systemd/system/multi-user.target</div><div><br></div><div>And if I move default.redirect.target from /etc/systemd/system/ to /etc/ system will not boot correctly. Problematic chain looks next way:</div><div></div><div>/etc/systemd/system/default.target -> /etc/default.redirect.target -> /lib/systemd/system/multi-user.target</div><div><br></div><div>Chain by itself looks valid:</div><div></div><div>root@deb11tiny:/etc/systemd/system# cat /etc/systemd/system/default.target<br>#  SPDX-License-Identifier: LGPL-2.1-or-later<br>#<br>#  This file is part of systemd.<br>#<br>#  systemd is free software; you can redistribute it and/or modify it<br>#  under the terms of the GNU Lesser General Public License as published by<br>#  the Free Software Foundation; either version 2.1 of the License, or<br>#  (at your option) any later version.<br><br>[Unit]<br>Description=Multi-User System<br>Documentation=man:systemd.special(7)<br>Requires=basic.target<br>Conflicts=rescue.service rescue.target<br>After=basic.target rescue.service rescue.target<br>AllowIsolate=yes</div><div></div><div><br></div><div>root@deb11tiny:/etc/systemd/system# systemctl get-default<br>multi-user.target</div><div><br></div><div>And system actually booting. And SystemD seems to know which target it should boot as I can see in output next lines:</div><div>...<br></div><div>[    4.508581] systemd[1]: Queued start job for default target Multi-User System.</div><div>...<br></div><div> [  OK  ] Reached target Multi-User System.</div><div></div><div></div><div><br></div><div>But the booted system will get most of its units inactive. Network, sshd... even gettys stays unstarted.</div><div>Is it a problem with Debian SystemD build? Or is it correct behaviour? <br></div><div><br></div><div>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?</div><div><br></div><div><div>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.  <br></div></div></div>