** Description changed: + [Impact] + + systemd 256 changes behavior and makes /tmp a tmpfs by default. This causes some + problems with packages for which the sources weight more than the tmpfs size, + and this case often happen on the testbed because they usually don't have a lot + of RAM by default (see test case below for a concrete example). + + [Test case] + + (Untested yet, as it seems the current systemd in proposed is causing network + issues too, and this breaks with an unrelated problem) + + autopkgtest-buildvm-ubuntu-cloud -a amd64 -r oracular + autopkgtest -BU libreoffice --apt-pocket=proposed=src:systemd -- qemu autopkgtest-oracular-amd64.img + + Since the default RAM given to the QEMU VM is 2GB and the libreoffice source + take more than 4GB, this should have no trouble running in a "No space left on + device" error. + + [Fix] + + https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/362 + This was release in autopkgtest 5.36, currently in the process of being SRU'd to + Jammy and Noble in bug #2071609. + + [Regression potential] + + The current SRU has a lot of unrelated changes. While this increases the + chances of regression, this also come with a broader test suite, increasing test + coverage, and so regressions should only happen in corner-cases, hopefully less + important as the current lack of this /tmp bug fix. + + + [Original bug report] + Debian systemd now mounts a tmpfs on /tmp by default; relevant d/changelog entry: systemd (256~rc3-3) unstable; urgency=medium - * Make /tmp/ a tmpfs by default. Restore the upstream default and make - /tmp/ a tmpfs. Can be overridden with: touch - /etc/systemd/system/tmp.mount or: systemctl mask tmp.mount + * Make /tmp/ a tmpfs by default. Restore the upstream default and make + /tmp/ a tmpfs. Can be overridden with: touch + /etc/systemd/system/tmp.mount or: systemctl mask tmp.mount Ubuntu is aligning to this, however this means that available space under /tmp is limited to the half of the available ram. That is sometimes not enough to unpack source trees in /tmp, see for example [1]. We need to to decide how to deal with this. Possibilities I can think about: 1. Disable the tmpfs tmp.mount, as suggested in the d/changelog entry. To be done in setup-testbed. Good: easy. Bad: deviates from the Ubuntu defaults, requires rebuilding the images. 2. Make autopkgtest use /var/tmp. Good: we stick to the defaults: Bad: requires non trivial changes in src:autopkgtest, which makes assumptions on stuff being in /tmp, on /tmp being cleared on reboots, ... This under the assumption that the switch to a tmpfs has been discussed, and we want it in Ubuntu. [1] https://autopkgtest.ubuntu.com/results/autopkgtest- oracular/oracular/ppc64el/c/ceph/20240618_194813_d6efc@/log.gz
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2069834 Title: systemd defaulting to tmpfs for /tmp causes enospc errors To manage notifications about this bug go to: https://bugs.launchpad.net/auto-package-testing/+bug/2069834/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
