Hi, Quoting Francesco Poli (2024-01-11 08:58:49) > On Thu, 11 Jan 2024 00:45:50 +0100 Johannes Schauer Marin Rodrigues wrote: > > Interesting! I'm unable to reproduce either of these issues and I'm also > > puzzled why you get this "permission denied" error. On my system, I'm able > > run > > your command with the default (in /tmp) as well as in /dev/shm. Here is the > > free space each: > > > > $ df --si /tmp /dev/shm > > Filesystem Size Used Avail Use% Mounted on > > tmpfs 8.6G 4.1k 8.6G 1% /tmp > > tmpfs 2.0G 418k 2.0G 1% /dev/shm > So 2.0 GB should be enough. > And yet, it fails for me with 8.2 GB available on /dev/shm ... :-(
it's hard for me to debug this as I don't see the error myself. I wonder how I
can be of further assistance to you to figure out what is going on?
> > Maybe something is mounted in a funny way? Both my /tmp and my /dev/shm are
> > tmpfs. The former is mounted with
> > rw,nosuid,nodev,relatime,size=8388608k,inode64 and the latter with
> > rw,nosuid,nodev,inode64.
>
> $ mount | grep '/tmp\|shm'
> tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
> /dev/md3 on /tmp type ext4 (rw,relatime,discard)
Yes, that looks harmless.
> > I doubt that it fails for lack of system memory unless you have less than
> > 3.7
> > GB of RAM.
> $ free --giga
> total used free shared buff/cache
> available
> Mem: 16 2 12 0 2
> 14
> Swap: 17 0 17
$ free --giga
total used free shared buff/cache
available
Mem: 3 3 0 0 1
0
Swap: 8 0 8
Your values are all twice as big or more than mine.
> > Maybe permissions are somehow whacky? Both my /tmp and my /dev/shm are set
> > to
> > drwxrwxrwt (so there is a sticky bit set) and owned by root:root.
>
> $ ls -ld /tmp /dev/shm
> drwxrwxrwt 3 root root 200 Jan 11 08:25 /dev/shm
> drwxrwxrwt 13 root root 4096 Jan 11 08:36 /tmp
Looks good!
> > What happens with other locations for TMPDIR?
>
> Which other locations?
> I cannot use anything within my home directory, as you may recall from
> our past [discussions]
>
> [discussions]: <https://bugs.debian.org/944485#216>
Yes, this also reminds me of #1052471 which found libpam-tmpdir directories
like /tmp/user/1000 to be unusable in unshare mode.
> > Maybe. It's currently .img because it's easier to debug stuff and use kpartx
> > with it without having to extract it first. :)
> Do I understand correctly that you intend to switch to .qcow2 in the future?
> Or otherwise, what's your plan?
I don't have one yet. It's a work in progress. Your input helps me to decide in
which direction to move. :)
> > > Please clarify and/or improve mmdebstrap-autopkgtest-build-qemu .
> > > Thanks for your time!
> > Thanks for your bug! Lets hope we get to the bottom of this.
> You're welcome.
>
> Looking forward to hearing back from you!
Do you see yourself debugging this further by yourself? You probably understand
that it's hard for me to investigate something that I cannot test myself.
Thanks!
cheers, josch
signature.asc
Description: signature
