Slightly confused about the procedure here. This bug was introduced in Debian in 0.2.39 as a fix for LP #1766872. This is the current version in cosmic and disco, and the bug was backported into xenial and bionic. I guess this should be tagged as regression-update? But it should also be fixed in Debian, where it has been abandoned.
Filling out an SRU template below.
[Impact]
* A recovery mode boot is effectively a normal boot on any system that has ever had systemctl set-default run on it, i.e., the recovery kernel parameter does nothing. In particular, ubiquity calls systemctl set-default as part of the oem-config process, rendering recovery mode useless on any oem-configured machine.
* This is a regression from previous behavior, where recovery mode would override a user-set default target.
* This would also restore the intuitive behavior of this package. It is intended to be run by setting a kernel parameter for a one-time boot, and should therefore take priority over any other settings (such as configuring a different default target).
[Test Case]
* Run systemctl set-default multi-user.target
* Use the GRUB menu to try to boot into recovery mode
* Observe that you end up at a TTY, not in recovery mode
[Regression Potential]
* Possible regression if someone set recovery as a default kernel parameter, then relied on the default systemd target to override it. This seems like an unlikely use-case.
Slightly confused about the procedure here. This bug was introduced in Debian in 0.2.39 as a fix for LP #1766872. This is the current version in cosmic and disco, and the bug was backported into xenial and bionic. I guess this should be tagged as regression-update? But it should also be fixed in Debian, where it has been abandoned.
Filling out an SRU template below.
[Impact]
* A recovery mode boot is effectively a normal boot on any system that has ever had systemctl set-default run on it, i.e., the recovery kernel parameter does nothing. In particular, ubiquity calls systemctl set-default as part of the oem-config process, rendering recovery mode useless on any oem-configured machine.
* This is a regression from previous behavior, where recovery mode would override a user-set default target.
* This would also restore the intuitive behavior of this package. It is intended to be run by setting a kernel parameter for a one-time boot, and should therefore take priority over any other settings (such as configuring a different default target).
[Test Case]
* Run systemctl set-default multi-user.target
* Use the GRUB menu to try to boot into recovery mode
* Observe that you end up at a TTY, not in recovery mode
[Regression Potential]
* Possible regression if someone set recovery as a default kernel parameter, then relied on the default systemd target to override it. This seems like an unlikely use-case.