Hi, In v245 systemd started to default to `initrd.target`, instead of `default.target` in the initrd. However, unlike `default.target` in the running system, `initrd.target` is not an indirection symlink. Specifically, default.target is a symlink to like graphical.target or like multi-user.target and nothing depends on it. Thus one can bake images that that make default.target to be a symlink to something else, which can divert boot to a different transaction (reach it, start a few other transactions) and then isolate to regular graphical.target/multi-user.target etc. initrd.target however, is not an indirection symlink, but it s a real one. So in my case, I do want to subvert initrd boot, reach the transaction, run a few more transactions, and then start initrd.target to complete the initrd stage of the boot and pivot to real root. However it is not trivial to do so, because initrd.target semantics are those closer to "multi-user.target" or "graphical.target", rather than default.target (which is strictly only a symlink). Solution 1 - Would people be open to creating: 1) default-initrd.target which is a symlink to initrd.target 2) changing main.c initrd special target to be default-initrd.target This way, in the initrd "out of the box" things boot to default-initrd.target -> initrd.target, but also allow to subvert default-initrd.target to something else, and later start initrd.target without modifying any third party that already integrates with initrd.target (ie. dracut etc). This also fixes regression from v244, where initrd used to boot to default.target symlink, and one used to be able to point that symlink to something else, instead of initrd.target, whilst preserving the out-of-the-box correct behaviour. Or in a closer spirit to v244 can we do something like: Solution 2: 1) if rd.systemd.unit / --unit args passed use those 2) if default.target exists use that 3) else use initrd.target ? Because v245 has lost sensitivity to /etc/systemd/system/default.target symlink pointing at something else but initrd.target. -- Regards, Dimitri. _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel