Bug#913061: systemd: stop shipping /bin/systemd
Control: tags -1 pending Control: unblock -1 by 940051 940050 On Sat, 9 Nov 2019 02:36:20 +0100 Michael Biebl wrote: > Hi Ansgar > > On Thu, 12 Sep 2019 09:00:12 +0200 Ansgar wrote: > > Ben Hutchings writes: > > > On Wed, 2019-09-11 at 19:20 +0200, Ansgar wrote: > > >> 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. > > > > > > I don't think it's appropriate for the initramfs to do this sort of > > > magic. Even if they did, this wouldn't cover systems using a custom > > > kernel that doesn't need an initramfs. > > > > > > I think that a better way to handle this would be for systemd itself to > > > warn on upgrade if /proc/cmdline contains init=/bin/systemd. > > > > The problem is that many people don't read warning or don't react on > > them right away. So I would prefer if we had an additional safety net. > > If this wouldn't result in unbootable systems, I agree that a warning > > would be sufficient. > > Since Ben was against adding such a fallback to initramfs-tools, we > either need a different solution or continue to ship the symlink. > > I wonder whether aborting in preinst is acceptable or not. A warning > message probably won't cut it. This compat symlink has been around for many years, and documentation has long since been updated. Given the initrd tools are not going to add checks, I will just drop it now. Any user still setting manually init=/bin/systemd will just have to fix their local configuration after they notice the breakage. The systemd binary should most definitely not be in the default PATH, and that is more important than supporting hypothetical broken and unsupported local-only changes. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#913061: systemd: stop shipping /bin/systemd
Hi Ansgar On Thu, 12 Sep 2019 09:00:12 +0200 Ansgar wrote: > Ben Hutchings writes: > > On Wed, 2019-09-11 at 19:20 +0200, Ansgar wrote: > >> 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. > > > > I don't think it's appropriate for the initramfs to do this sort of > > magic. Even if they did, this wouldn't cover systems using a custom > > kernel that doesn't need an initramfs. > > > > I think that a better way to handle this would be for systemd itself to > > warn on upgrade if /proc/cmdline contains init=/bin/systemd. > > The problem is that many people don't read warning or don't react on > them right away. So I would prefer if we had an additional safety net. > If this wouldn't result in unbootable systems, I agree that a warning > would be sufficient. Since Ben was against adding such a fallback to initramfs-tools, we either need a different solution or continue to ship the symlink. I wonder whether aborting in preinst is acceptable or not. A warning message probably won't cut it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#913061: systemd: stop shipping /bin/systemd
Ben Hutchings writes: > On Wed, 2019-09-11 at 19:20 +0200, Ansgar wrote: >> 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. > > I don't think it's appropriate for the initramfs to do this sort of > magic. Even if they did, this wouldn't cover systems using a custom > kernel that doesn't need an initramfs. > > I think that a better way to handle this would be for systemd itself to > warn on upgrade if /proc/cmdline contains init=/bin/systemd. The problem is that many people don't read warning or don't react on them right away. So I would prefer if we had an additional safety net. If this wouldn't result in unbootable systems, I agree that a warning would be sufficient. Ansgar
Bug#913061: systemd: stop shipping /bin/systemd
On Wed, 2019-09-11 at 19:20 +0200, Ansgar wrote: > 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. I don't think it's appropriate for the initramfs to do this sort of magic. Even if they did, this wouldn't cover systems using a custom kernel that doesn't need an initramfs. I think that a better way to handle this would be for systemd itself to warn on upgrade if /proc/cmdline contains init=/bin/systemd. Ben. -- Ben Hutchings Unix is many things to many people, but it's never been everything to anybody. signature.asc Description: This is a digitally signed message part
Bug#913061: systemd: stop shipping /bin/systemd
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.
Bug#913061: systemd: stop shipping /bin/systemd
Hi Ansgar On Tue, 06 Nov 2018 15:24:18 +0100 Ansgar Burchardt wrote: > Package: systemd > Version: 239-11 > Severity: minor > File: /bin/systemd > > 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 :-) Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#913061: systemd: stop shipping /bin/systemd
Package: systemd Version: 239-11 Severity: minor File: /bin/systemd 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.) Ansgar [1]: https://wiki.debian.org/systemd#Configuring_for_testing
