Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
Control: severity -1 important On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann wrote: > Package: systemd > Version: 252.6-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts Given what was discussed: - bookworm is in hard freeze - there is no functional impact - unmerged-usr paths are no longer supported - as soon as trixie opens for business we might just canonicalize everything (assuming all the ducks will be in a row) if it's all right with you Andreas, I am going to go ahead and downgrade this. If we don't manage to canonicalize early in trixie's cycle we can revisit. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On Mon, 29 May 2023 15:17:51 +0200 Andreas Beckmann wrote: > On 29/05/2023 14.57, Luca Boccassi wrote: > >> Side question first: does systemd evaluate both > >> /usr/lib/modules-load.d/* and /lib/modules-load.d/* ? > >> Otherwise all packages shipping something in /lib/modules-load.d/ are > >> broken on unmerged-/usr because their config snippets are not being > >> taken into account. > > > > The correct path since bullseye was /usr/lib/modules-load.d, see: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282 > > I read this as these packages have been buggy on unmerged-/usr in > bullseye. Why weren't there bugs filed? Good question, I guess nobody ever noticed because most users are on merged-usr anyway? But as you can see from the bug, it's been years. > > Anyway, we don't really care about what happens on unmerged > > installations, as they are no longer supported since Bookworm. > > Well, there is still limited support, e.g. for buildd usage. But > probably (hopefully?) for the last time. IIRC the plan was to switch buildds as soon as bookworm ships, but I don't think that's finalised. Also I don't think it's supported to install and load kernel modules for a package build, at least I've never came across that, but I might be wrong. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On May 29, Luca Boccassi wrote: > Does it matter that much if the empty directory is removed? Next time > a package shipping a modules-load config is installed it will be just > re-added, no? Or are there functional issues? I do not think that it is a big deal if /usr/lib/modules-load.d/ disappears from time to time. Local users are expected to install local files in /etc/modules-load.d/ anyway. -- ciao, Marco signature.asc Description: PGP signature
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
Hi Andreas, On Mon, May 29, 2023 at 02:42:14PM +0200, Andreas Beckmann wrote: > during a test with piuparts I noticed your package ships an empty > directory (/usr/lib/modules-load.d/) which disappears after installation > and removal of another package (e.g. multipath-tools) in a merged-/usr > setup. This is not a bug in the other package, but an effect of our > merged-/usr implementation. Thank you Andreas for your attention to detail in locating and reporting these kind of issues. Your QA work is being very useful again as it was when you noticed how we broke adduser users. I caution that this is an instance of a generic problem that affects all sorts of packages shipping empty directories in aliased locations. It is a problem that has not previously been on my radar of things to watch out for and now is. I have yet to do the math of figuring out how many other packages are affected in a similar way and intend to follow up with that on d-devel@l.d.o. > This is happening to trigger the bug: In what sense is the behaviour actually buggy? Quite obviously, this is a reproducibility issue, because depending on how you order operations, different things happen. I somewhat question though that this is a serious issue and would expect systemd to deal with the absence in a sane way. Do you have any evidence of it behaving otherwise? If you file further bugs pertaining issues related to /usr-merge, I'd appreciate an X-Debbugs-Cc. Helmut
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On 29/05/2023 14.57, Luca Boccassi wrote: Side question first: does systemd evaluate both /usr/lib/modules-load.d/* and /lib/modules-load.d/* ? Otherwise all packages shipping something in /lib/modules-load.d/ are broken on unmerged-/usr because their config snippets are not being taken into account. The correct path since bullseye was /usr/lib/modules-load.d, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282 I read this as these packages have been buggy on unmerged-/usr in bullseye. Why weren't there bugs filed? Anyway, we don't really care about what happens on unmerged installations, as they are no longer supported since Bookworm. Well, there is still limited support, e.g. for buildd usage. But probably (hopefully?) for the last time. Andreas
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On Mon, 29 May 2023 at 14:07, Andreas Beckmann wrote: > > On 29/05/2023 14.57, Luca Boccassi wrote: > > Wouldn't the correct workaround be to list /usr/lib/modules-load.d in > > systemd.dirs so that dpkg leaves it alone? Seems way too late for > > Bookworm though? > > for dpkg, /usr/lib/modules-load.d is already owned by systemd, dpkg only > accidentally deletes it while removing /lib/modules-load.d > > That's the reason for adding some placeholder file there, to prevent > accidental removal of the (no longer empty) directory. > Could be part of the first bookworm point release. Does it matter that much if the empty directory is removed? Next time a package shipping a modules-load config is installed it will be just re-added, no? Or are there functional issues? Kind regards, Luca Boccassi
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On 29/05/2023 14.57, Luca Boccassi wrote: Wouldn't the correct workaround be to list /usr/lib/modules-load.d in systemd.dirs so that dpkg leaves it alone? Seems way too late for Bookworm though? for dpkg, /usr/lib/modules-load.d is already owned by systemd, dpkg only accidentally deletes it while removing /lib/modules-load.d That's the reason for adding some placeholder file there, to prevent accidental removal of the (no longer empty) directory. Could be part of the first bookworm point release. Andreas
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann wrote: > Package: systemd > Version: 252.6-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: piuparts > > Hi, > > during a test with piuparts I noticed your package ships an empty > directory (/usr/lib/modules-load.d/) which disappears after installation > and removal of another package (e.g. multipath-tools) in a merged- /usr > setup. This is not a bug in the other package, but an effect of our > merged-/usr implementation. > > Side question first: does systemd evaluate both > /usr/lib/modules-load.d/* and /lib/modules-load.d/* ? > Otherwise all packages shipping something in /lib/modules-load.d/ are > broken on unmerged-/usr because their config snippets are not being > taken into account. The correct path since bullseye was /usr/lib/modules-load.d, see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282 Anyway, we don't really care about what happens on unmerged installations, as they are no longer supported since Bookworm. > This is happening to trigger the bug: > > systemd ships /usr/lib/modules-load.d/ (empty directory) > multipath-tools ships /lib/modules-load.d/multipath.conf > dpkg doesn't know that /lib/modules-load.d/ and /usr/lib/modules- load.d/ > are the same, and therefore removal of multipath-tools causes removal of > * /lib/modules-load.d/multipath.conf (OK) > * /lib/modules-load.d/ (if it was the last owner of that directory), while > it effectively is /usr/lib/modules-load.d/ getting removed > > When adding a placeholder file, it needs to be something that is ignored > by the processing of the .d directory (the pattern could be *.conf, but I > might be mistaken here). > > An alternative to shipping a placeholder file could be shipping > /lib/modules-load.d/ as additional empty directory, but I don't know > whether this would be allowed w.r.t. merged-/usr. > > > From the attached log (scroll to the bottom...): > > 0m39.2s ERROR: FAIL: After purging files have disappeared: > /usr/lib/modules-load.d/ owned by: systemd > > > This is not caught by default piuparts tests as there is no test with > systemd explicitly installed. > > I could not reproduce this issue in bullseye (and haven't tried to > reproduce it in earlier releases). Wouldn't the correct workaround be to list /usr/lib/modules-load.d in systemd.dirs so that dpkg leaves it alone? Seems way too late for Bookworm though? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/
Package: systemd Version: 252.6-1 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package ships an empty directory (/usr/lib/modules-load.d/) which disappears after installation and removal of another package (e.g. multipath-tools) in a merged-/usr setup. This is not a bug in the other package, but an effect of our merged-/usr implementation. Side question first: does systemd evaluate both /usr/lib/modules-load.d/* and /lib/modules-load.d/* ? Otherwise all packages shipping something in /lib/modules-load.d/ are broken on unmerged-/usr because their config snippets are not being taken into account. This is happening to trigger the bug: systemd ships /usr/lib/modules-load.d/ (empty directory) multipath-tools ships /lib/modules-load.d/multipath.conf dpkg doesn't know that /lib/modules-load.d/ and /usr/lib/modules-load.d/ are the same, and therefore removal of multipath-tools causes removal of * /lib/modules-load.d/multipath.conf (OK) * /lib/modules-load.d/ (if it was the last owner of that directory), while it effectively is /usr/lib/modules-load.d/ getting removed When adding a placeholder file, it needs to be something that is ignored by the processing of the .d directory (the pattern could be *.conf, but I might be mistaken here). An alternative to shipping a placeholder file could be shipping /lib/modules-load.d/ as additional empty directory, but I don't know whether this would be allowed w.r.t. merged-/usr. >From the attached log (scroll to the bottom...): 0m39.2s ERROR: FAIL: After purging files have disappeared: /usr/lib/modules-load.d/ owned by: systemd This is not caught by default piuparts tests as there is no test with systemd explicitly installed. I could not reproduce this issue in bullseye (and haven't tried to reproduce it in earlier releases). cheers, Andreas PS: packages shipping files in modules-load.d/ (in sid): # apt-file search /lib/modules-load.d/ aoetools: /usr/lib/modules-load.d/aoetools.conf dlm-controld: /usr/lib/modules-load.d/configfs.conf drbd-utils: /lib/modules-load.d/drbd.conf ecryptfs-utils: /lib/modules-load.d/ecryptfs.conf fwupd: /usr/lib/modules-load.d/fwupd-msr.conf iwd: /usr/lib/modules-load.d/pkcs8.conf libddccontrol0: /usr/lib/modules-load.d/ddccontrol-i2c-dev.conf mbpfan: /lib/modules-load.d/mbpfan.depend.conf multipath-tools: /lib/modules-load.d/multipath.conf open-vm-tools-desktop: /usr/lib/modules-load.d/open-vm-tools-desktop.conf osspd: /lib/modules-load.d/osspd.conf zfsutils-linux: /lib/modules-load.d/zfs.conf systemd-modules-load.d.log.gz Description: application/gzip
