Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1182297

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?

From Francesco Poli <invernomuto@paranoici.org>
Newsgroups linux.debian.bugs.dist
Subject Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR?
Date 2024-01-14 18:40 +0100
Message-ID <HWcCK-34U5-5@gated-at.bofh.it> (permalink)
References (7 earlier) <HVGCS-2KMn-3@gated-at.bofh.it> <HVRRD-2RTZ-3@gated-at.bofh.it> <HVTA5-2T0c-5@gated-at.bofh.it> <HUPIe-2eay-19@gated-at.bofh.it> <HVTA5-2T0c-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Sat, 13 Jan 2024 22:09:22 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]
> Quoting Johannes Schauer Marin Rodrigues (2024-01-13 20:18:34)
[...]
> > The problem occurs for Francesco when
> > using either /tmp or /dev/shm as a temporary directly. By default, those two
> > locations should have the desired permission bits set. Lets check whether
> > world-execute permissions are set for all directories up until root. I have
> > this:
> > 
> >     $ stat -c "%a %n" / /dev /dev/shm /tmp
> >     755 /
> >     755 /dev
> >     1777 /dev/shm
> >     1777 /tmp
> > 
> > Francesco, what are the world execute permissions on all path components up
> > to /tmp and /devv/shm in your case?

Just like yours:

  $ stat -c "%a %n" / /dev /dev/shm /tmp
  755 /
  755 /dev
  1777 /dev/shm
  1777 /tmp


> 
> scratch what I said in your last mail. Your problem is with the creation of the
> image and not with the temporary chroot directory. What Helmut said is likely
> correct and exactly the problem you are facing. To verify, you could run the
> command you posted initially inside your $HOME directory and show us the
> permission bits of your $HOME. Mine are these:
> 
>     stat -c "%a %n" $HOME
>     711 /home/josch
> 
> I assume in your case, you have a 0 at the end of the octal permissions?

Of course, I have!   ;-)

For privacy reasons: I don't want other users to be able to enter my
home directory and to read any file within it that I might have
forgotten with world-readable permissions!

So, the answer to your question is that I indeed have 0 at the end of
the octal permissions:

  $ stat -c "%a %n" $HOME
  700 /home/$USER


OK, please let me understand.

mmdebstrap-autopkgtest-build-qemu creates a chroot within the temporary
directory (TMPDIR=/dev/shm, in my case), but then performs some further
operations (such as mkfs.ext4) on the image file, which is being
created in the directory the user wanted it to be.

Hence, if the user issues the command

  $ cd ~/mysubdir
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
                    --boot=efi sid sid_amd64.img

the final touches to sid_amd64.img will be put with the file in its
intended destination directory, which is /home/${USER}/mysubdir, since
the command-line argument was "sid_amd64.img", a relative path to a
file directly within the current working directory (~/mysubdir).

And these final touches require all parent directories (up to the root
directory) to be world-executable.
In other words, the user would need:

  $ stat -c "%a %n" ~/mysubdir ~ /home /
  771 /home/${USER}/mysubdir
  701 /home/${USER}
  755 /home
  755 /

rather than:

  $ stat -c "%a %n" ~/mysubdir ~ /home /
  770 /home/${USER}/mysubdir
  700 /home/${USER}
  755 /home
  755 /

Is that correct?
Or am I completely off-track?


I tried to do everything within /dev/shm, with:

  $ cd /dev/shm
  $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
                    --size=2G --boot=efi sid sid_amd64.img
  [...]
  cp: warning: behavior of -n is non-portable and may change in future; use --update=none instead
  I: running special hook: download vmlinuz '/dev/shm/tmp.hhjurdQFhk/kernel'
  I: running special hook: download initrd.img '/dev/shm/tmp.hhjurdQFhk/initrd'
  I: running --customize-hook in shell: sh -c 'mount --bind "$1" "$1/mnt"' exec /dev/shm/mmdebstrap.PeOPcJxciV
  I: running --customize-hook in shell: sh -c 'mount --bind "$1/mnt/mnt" "$1/mnt/dev"' exec /dev/shm/mmdebstrap.PeOPcJxciV
  I: running --customize-hook in shell: sh -c '/sbin/mkfs.ext4 -d "$1/mnt" -L autopkgtestvm -E 'offset=134217728,assume_storage_prezeroed=1' 'sid_amd64.img' '2G'' exec /dev/shm/mmdebstrap.PeOPcJxciV
  mke2fs 1.47.0 (5-Feb-2023)
  Creating filesystem with 524288 4k blocks and 131072 inodes
  Filesystem UUID: 6d0afa2d-5ee5-4a45-b2ef-1bdb74315ad7
  Superblock backups stored on blocks: 
          32768, 98304, 163840, 229376, 294912
  
  Allocating group tables: done                            
  Writing inode tables: done                            
  Creating journal (16384 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done 
  
  I: running --customize-hook in shell: sh -c 'umount --lazy "$1/mnt"' exec /dev/shm/mmdebstrap.PeOPcJxciV
  I: cleaning package lists and apt cache...
  done
  done
  I: removing tempdir /dev/shm/mmdebstrap.PeOPcJxciV...
  I: success in 120.0573 seconds
  determined efi vma alignment as 0x0001000
  determined minimum efi vma offset as 5603221504
  mkfs.fat 4.2 (2021-01-31)
  Checking that no-one is using this disk right now ... OK
  
  Disk sid_amd64.img: 2.13 GiB, 2281718784 bytes, 4456482 sectors
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  
  >>> Script header accepted.
  >>> Script header accepted.
  >>> Created a new GPT disklabel (GUID: 39BDEF0B-9FF8-4DB9-921B-FA7A6C2CDB54).
  sid_amd64.img1: Created a new partition 1 of type 'EFI System' and of size 127 MiB.
  sid_amd64.img2: Created a new partition 2 of type 'Linux filesystem' and of size 2 GiB.
  Partition #2 contains a ext4 signature.
  sid_amd64.img3: Done.
  
  New situation:
  Disklabel type: gpt
  Disk identifier: 39BDEF0B-9FF8-4DB9-921B-FA7A6C2CDB54
  
  Device          Start     End Sectors  Size Type
  sid_amd64.img1   2048  262143  260096  127M EFI System
  sid_amd64.img2 262144 4456447 4194304    2G Linux filesystem
  
  The partition table has been altered.
  Syncing disks.
  $ echo $?
  0
  $ ls -lF --si sid_amd64.img 
  -rw-r-xrwx 1 $USER $USER 2.3G Jan 14 18:17 sid_amd64.img*
  $ mv -i sid_amd64.img ~/Downloads/

It looks like it worked, but, unfortunately, it (again) fails to be
usable with autopkgtest:

  $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out  --summary ./${SRCPKG}_autopkgtest.summary --apt-upgrade -B ./${SRCPKG}_amd64.changes -- qemu --overlay-dir /dev/shm ~/Downloads/sid_amd64.img
  autopkgtest [18:24:23]: starting date and time: 2024-01-14 18:24:23+0100
  autopkgtest [18:24:23]: version 5.32
  autopkgtest [18:24:23]: host ${HOST}; command line: /usr/bin/autopkgtest --output-dir './${SRCPKG}_autopkgtest.out' --summary './${SRCPKG}_autopkgtest.summary' --apt-upgrade -B './${SRCPKG}_amd64.changes' -- qemu --overlay-dir /dev/shm ${HOME}/Downloads/sid_amd64.img
  qemu-system-x86_64: terminating on signal 15 from pid 115770 (/usr/bin/python3)
  <VirtSubproc>: failure: timed out waiting for 'login prompt on serial console'
  autopkgtest [18:25:24]: ERROR: testbed failure: unexpected eof from the testbed


What did I fail to understand?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Back to linux.debian.bugs.dist | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? "Francesco Poli (wintermute)" <invernomuto@paranoici.org> - 2024-01-11 00:00 +0100
  Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-11 00:50 +0100
    Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Francesco Poli <invernomuto@paranoici.org> - 2024-01-11 09:20 +0100
      Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-11 21:10 +0100
        Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Francesco Poli <invernomuto@paranoici.org> - 2024-01-12 20:10 +0100
          Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-12 23:50 +0100
            Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Francesco Poli <invernomuto@paranoici.org> - 2024-01-14 18:40 +0100
              Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-15 17:50 +0100
          Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Helmut Grohne <helmut@subdivi.de> - 2024-01-13 08:30 +0100
            Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-13 20:30 +0100
              Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-13 22:20 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Francesco Poli <invernomuto@paranoici.org> - 2024-01-14 18:40 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Helmut Grohne <helmut@subdivi.de> - 2024-01-15 07:40 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Francesco Poli <invernomuto@paranoici.org> - 2024-01-16 00:30 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Helmut Grohne <helmut@subdivi.de> - 2024-01-16 07:40 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-16 11:10 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-23 09:10 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-01-25 13:40 +0100
                Bug#1060416: mmdebstrap-autopkgtest-build-qemu fails on mkfs.ext4; does it require a 25 GiB TMPDIR? Francesco Poli <invernomuto@paranoici.org> - 2024-01-27 19:00 +0100

csiph-web