Bug#1101175: systemd: mounts a tmpfs on /tmp in the middle of upgrade

[Tollef Fog Heen]

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