canonical-ubuntu-qa team mailing list archive

[Ural Tunaboyu <2069834@xxxxxxxxxxxxxxxxxx>]

Performing the verification on Jammy.

First, we check if we can reproduce the problem.

$ apt policy autopkgtest
autopkgtest:
  Installed: 5.32ubuntu3~22.04.1
  Candidate: 5.32ubuntu3~22.04.1
  Version table:
     5.37ubuntu3~22.04.1 400
        400 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        400 http://archive.ubuntu.com/ubuntu jammy-proposed/main i386 Packages
 *** 5.32ubuntu3~22.04.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
        100 /var/lib/dpkg/status
     5.20 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

After creating an Oracular image we boot it and connect to it:
$ kvm -m 4096 -display none -boot c -net nic -net user,hostfwd=tcp:127.0.0.1:10030-:22 -hda autopkgtest-oracular-amd64.img

Now we check:
$ mount -t tmpfs | grep /tmp
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)
$ stat /etc/systemd/system/tmp.mount
stat: cannot statx '/etc/systemd/system/tmp.mount': No such file or directory

So the bug is successfully replicated.
Now we verify the fix.
$ apt policy autopkgtest
autopkgtest:
  Installed: 5.37ubuntu3~22.04.1
  Candidate: 5.37ubuntu3~22.04.1
  Version table:
 *** 5.37ubuntu3~22.04.1 400
        400 http://archive.ubuntu.com/ubuntu jammy-proposed/main amd64 Packages
        400 http://archive.ubuntu.com/ubuntu jammy-proposed/main i386 Packages
        100 /var/lib/dpkg/status
     5.32ubuntu3~22.04.1 500
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu jammy-updates/main i386 Packages
     5.20 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu jammy/main i386 Packages

We recreate the Oracular image and connect to it again:
$ kvm -m 4096 -display none -boot c -net nic -net user,hostfwd=tcp:127.0.0.1:10030-:22 -hda autopkgtest-oracular-amd64.img

Now we check:
$ mount -t tmpfs | grep /tmp
$ stat /etc/systemd/system/tmp.mount
  File: /etc/systemd/system/tmp.mount
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: 8,1	Inode: 66          Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-07-25 16:34:24.461607976 -0700
Modify: 2024-07-25 16:34:24.461607976 -0700
Change: 2024-07-25 16:34:24.461607976 -0700
 Birth: 2024-07-25 16:34:24.460607752 -0700

As can be seen, systemd has been instructed to not make /tmp a tmpfs and
has done so without issue.

This concludes the verification for Jammy.

-- 
You received this bug notification because you are a member of
Canonical's Ubuntu QA, which is subscribed to autopkgtest in Ubuntu.
https://bugs.launchpad.net/bugs/2069834

Title:
  systemd defaulting to tmpfs for /tmp causes enospc errors

Status in Auto Package Testing:
  New
Status in autopkgtest package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Won't Fix
Status in autopkgtest source package in Jammy:
  Fix Committed
Status in autopkgtest source package in Noble:
  Fix Committed

Bug description:
  [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]

  autopkgtest-buildvm-ubuntu-cloud -a amd64 -r oracular
  autopkgtest --shell gzip -- qemu ./autopkgtest-oracular-amd64.img
  Jump to the shell when prompted and verify the following:
  mount -t tmpfs | grep /tmp   # this returns nothing, /tmp is not a tmpfs anymore
  stat /etc/systemd/system/tmp.mount   # this file has correctly been created, which explains the previous result

  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

  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/auto-package-testing/+bug/2069834/+subscriptions