Package: systemd Version: 257.4-3 Severity: critical Justification: breaks apt completely
I was upgrading my system from bookworm to trixie when it broke in the middle with apt complaining about not finding a set of .debs in /tmp. It turned out that systemd had activated the tmp.mount unit in the middle of the upgrade. As this was a large dist-upgrade, I'm not sure exactly what happened, but some excerpts from the journal: Mar 24 06:54:36 x systemd[1]: tmp.mount: Directory /tmp to mount over is not empty, mounting anyway. Mar 24 06:54:36 x systemd[1]: Mounting tmp.mount - Temporary Directory /tmp... Mar 24 06:54:36 x systemd[1]: Mounted tmp.mount - Temporary Directory /tmp. Mar 24 06:54:36 x systemd[1]: Starting man-db.service - Daily man-db regeneration... Mar 24 06:54:40 x systemd[1]: man-db.service: Deactivated successfully. Mar 24 06:54:40 x systemd[1]: Finished man-db.service - Daily man-db regeneration. man-db.service is a service with PrivateTmp=true, and according to advice on #debian-devel, such a service will have Wants/After=tmp.mount. The masking of the tmp.mount unit happens in postinst, so there's a race where the new package might be unpacked, something calls systemctl daemon-reload and then a service with PrivateTmp gets activated before systemd's postinst is called. I'm filing this as critical since it left the system completely broken and required extensive use of dpkg -i to recover. A better solution is probably to do the masking in preinst instead of postinst, assuming my analysis is correct. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are