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
pgp7NUqyXoPnf.pgp
Description: PGP signature
