Re: Bug#978636: move to merged-usr-only?
On Jan 02, Matthias Klumpp wrote: > You wouldn't have to depend on PackageKit, the offline-upgrades stuff > can be implemented by other tools that aren't PK as well (you could > pretty much use the same mechanism, with some safeguards to not > interfere with PK/GNOME). However, ensuring that no service with > ProtectSystem starts may be a problem, as that feature is used quite > extensively by services that are part of the systemd project, and I > don't know whether it is possible to exclude them all from a potential > usrmerge target without causing other problems. I am not even sure that this is still an issue: Michael Biebl and me did a few tests (Debian 10, testing and Ubuntu 20.04) and convert-usrmerge never failed. Is anybody actually able to reproduce that on a Debian >= 10 system? Again, nothing bad will happen if you try and trigger that code path: just follow the instructions that will tell you to reboot the system and then run convert-usrmerge again. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#978636: move to merged-usr-only?
Am Di., 29. Dez. 2020 um 23:13 Uhr schrieb Marco d'Itri : > > On Dec 29, Matthias Klumpp wrote: > > > For package upgrades, we can already perform so-called "offline > > upgrades", where the system reboots into a smaller systemd target, > > applies all updates and then reboots again into the updated system. > > This is implemented in PackageKit as an option and used by GNOME. > > Fwupd uses similar concepts for certain firmware updates as well. > > Maybe hooking into these facilities is also an option for the usrmerge > > upgrade? (unless of course systemd is still interfering even in a > > minimal target, that would be a dealbreaker). > It depends on which units are started (this trouble is caused by the > ProtectSystem directive and maybe others like it): having usrmerge > stop and then restart the daemons involved would work as well, but I am > not sure of how many corner cases (gdm...) we would find before just > rebooting would become simpler again. > I think that depending on PackageKit would be more complex than an > initramfs-tools hook, since just about everybody is supposed to have > that around. You wouldn't have to depend on PackageKit, the offline-upgrades stuff can be implemented by other tools that aren't PK as well (you could pretty much use the same mechanism, with some safeguards to not interfere with PK/GNOME). However, ensuring that no service with ProtectSystem starts may be a problem, as that feature is used quite extensively by services that are part of the systemd project, and I don't know whether it is possible to exclude them all from a potential usrmerge target without causing other problems. Also, of course this would only work on systemd systems, in the same way that the initramfs-tools solution won't work for Dracut users. Looks like quite a tricky problem, but one that could definitely be addressed by the project. Cheers, Matthias -- I welcome VSRE emails. See http://vsre.info/
Re: Bug#978636: move to merged-usr-only?
On Tue, 2020-12-29 at 23:12 +0100, Marco d'Itri wrote: [...] > I think that depending on PackageKit would be more complex than an > initramfs-tools hook, since just about everybody is supposed to have > that around. I'm afraid not - dracut, tiny-initramfs, and custom kernels that don't need an initramfs are also supported options. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Re: Bug#978636: move to merged-usr-only?
On Dec 29, Matthias Klumpp wrote: > For package upgrades, we can already perform so-called "offline > upgrades", where the system reboots into a smaller systemd target, > applies all updates and then reboots again into the updated system. > This is implemented in PackageKit as an option and used by GNOME. > Fwupd uses similar concepts for certain firmware updates as well. > Maybe hooking into these facilities is also an option for the usrmerge > upgrade? (unless of course systemd is still interfering even in a > minimal target, that would be a dealbreaker). It depends on which units are started (this trouble is caused by the ProtectSystem directive and maybe others like it): having usrmerge stop and then restart the daemons involved would work as well, but I am not sure of how many corner cases (gdm...) we would find before just rebooting would become simpler again. I think that depending on PackageKit would be more complex than an initramfs-tools hook, since just about everybody is supposed to have that around. -- ciao, Marco signature.asc Description: PGP signature
Re: Bug#978636: move to merged-usr-only?
Am Di., 29. Dez. 2020 um 17:39 Uhr schrieb Marco d'Itri : > > On Dec 29, Ansgar wrote: > > > as suggested in [1], I would like to see Debian to move to support > > only the merged-usr filesystem layout. This would simplfy things for > > the future and also address the problem with installing files under > > aliased trees that dpkg has to do for both variants to be supported. > As the architect of the Debian merged-usr transition, I agree: removing > support for unmerged systems would simplify many things. > Thank you Ansgar for bringing this to the CTTE. Indeed! > > I'm not asking the committee to decide on a concrete technical > > implementation for this. Obviously we would need to also implement a > > migration path for legacy installations for a move to merged-usr-only > > to be implemented. This also isn't relevant for Debian 11 (bullseye), > > but I would like to have enough time in the Debian 12 (bookworm) > > cycle. > Agreed. > FWIW: we have had for a long time a reliable migration method, the > usrmerge package. > Except that on a live system it requires a reboot mid-conversion (due to > bind mounts created by systemd): since this is inconvenient and mildly > scary I did not propose wider adoption for buster. > The best workaround would probably be to run it from the initramfs, but > I have not been able to actually make this[1] work: I expect that > somebody who knows initramfs-tools better than I do can fix it quickly. For package upgrades, we can already perform so-called "offline upgrades", where the system reboots into a smaller systemd target, applies all updates and then reboots again into the updated system. This is implemented in PackageKit as an option and used by GNOME. Fwupd uses similar concepts for certain firmware updates as well. Maybe hooking into these facilities is also an option for the usrmerge upgrade? (unless of course systemd is still interfering even in a minimal target, that would be a dealbreaker). More info about offline-upgrades can be found at [1], could be interesting to look into. This discussion is probably OT through for the issue at hand (*if* we make that switch, not the *how* we make it in particular). Cheers, Matthias [1]: https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html -- I welcome VSRE emails. See http://vsre.info/
Re: Bug#978636: move to merged-usr-only?
On Dec 29, Ansgar wrote: > as suggested in [1], I would like to see Debian to move to support > only the merged-usr filesystem layout. This would simplfy things for > the future and also address the problem with installing files under > aliased trees that dpkg has to do for both variants to be supported. As the architect of the Debian merged-usr transition, I agree: removing support for unmerged systems would simplify many things. Thank you Ansgar for bringing this to the CTTE. > I'm not asking the committee to decide on a concrete technical > implementation for this. Obviously we would need to also implement a > migration path for legacy installations for a move to merged-usr-only > to be implemented. This also isn't relevant for Debian 11 (bullseye), > but I would like to have enough time in the Debian 12 (bookworm) > cycle. Agreed. FWIW: we have had for a long time a reliable migration method, the usrmerge package. Except that on a live system it requires a reboot mid-conversion (due to bind mounts created by systemd): since this is inconvenient and mildly scary I did not propose wider adoption for buster. The best workaround would probably be to run it from the initramfs, but I have not been able to actually make this[1] work: I expect that somebody who knows initramfs-tools better than I do can fix it quickly. [1] https://salsa.debian.org/md/usrmerge/-/tree/initramfs -- ciao, Marco signature.asc Description: PGP signature
Bug#978636: move to merged-usr-only?
Package: tech-ctte X-Debbugs-Cc: debian-devel@lists.debian.org Hi, as suggested in [1], I would like to see Debian to move to support only the merged-usr filesystem layout. This would simplfy things for the future and also address the problem with installing files under aliased trees that dpkg has to do for both variants to be supported. merged-usr has been the default for new installations since the last release and (as far as I am aware) no world-breaking bugs have happened since; some environments such as buildd chroots still do not use merged-usr. I would like to ask the technical committee to decide whether we want to move to merged-usr-only. It seems to be a case of overlapping jurisdiction (6.1.2 in the constitution). I'm not asking the committee to decide on a concrete technical implementation for this. Obviously we would need to also implement a migration path for legacy installations for a move to merged-usr-only to be implemented. This also isn't relevant for Debian 11 (bullseye), but I would like to have enough time in the Debian 12 (bookworm) cycle. Ansgar [1]: https://lists.debian.org/debian-devel/2020/11/#00232 continued in December: https://lists.debian.org/debian-devel/2020/12/#00386
