Bug#913061: systemd: stop shipping /bin/systemd

[Ansgar]

Control: clone -1 -2 -3
Control: reassign -2 initramfs-tools
Control: reassign -3 dracut
Control: retitle -2 initramfs-tools: fallback to /lib/systemd/systemd if init=/bin/systemd
Control: retitle -3 dracut: fallback to /lib/systemd/systemd if init=/bin/systemd
Control: block -1 by -2
Control: block -1 by -3

Dear initramfs maintainers,

would it be possible to add a fallback to try /lib/systemd/systemd if
the user provided init=/bin/systemd and the file no longer exists?

I would like systemd to stop shipping the /bin/systemd symlink as this
should not be run by users, however it was suggested to use
init=/bin/systemd for testing purposes in the past (see below).  So just
removing the symlink might make some systems unbootable.

Ansgar

Michael Biebl writes:
>> Running `systemd` in an interactive shell is not a good idea.  To
>> avoid this happening by accident, the /bin/systemd ->
>> /lib/systemd/systemd symlink should no longer be shipped.
>> 
>> Documentation such as [1] still suggests to use `init=/bin/systemd`
>> which would result in non-bootable systems.  (The initramfs might be
>> able to catch this and run /lib/systemd/systemd instead in most cases
>> as unbootable systems are not nice.)
>
> Continuing to ship the symlink is kinda cheap and I'm indeed a bit
> worried that this change might cause unbootable systems.
> We could either add some maintscript code to abort the upgrade if a
> installation is detected that uses init=/bin/systemd (e.g. by checking
> /proc/cmdline).
> But your initramfs idea might indeed by nicer. The initramfs should
> probably output a big, fat warning if it is found that the old
> /bin/systemd symlink is used, so people will migrate to the "new"
> location eventually.
>
> Could you file a bug report against initramfs-tools and block this one
> with it? I guess attaching a working patch for initramfs-tools will
> speed up the process :-)

Done so now, also for dracut.