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
