On Sun, 28 Jan 2024 00:33:06 +0100 Johannes Schauer Marin Rodrigues wrote: [...] > Quoting Francesco Poli (wintermute) (2024-01-27 19:20:08) [...] > > My comments / suggestions for improvements: > > > > * I had to manually fix the permissions, since the image file was > > originally created with the following weird ones: > > > > $ ls -l --si sid-amd64.img > > -rw-r-xrwx 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img > > those are some funny permission bits. When I run > mmdebstrap-autopkgtest-build-qemu I get: > > $ ls -lha disk.img > -rw-r--r-- 1 josch josch 26G Jan 28 00:03 disk.img > > Looks fine to me.
What's *your* umask? Is it Debian default (022), by chance?
>
> > I think the file permissions should be set (possibly at the end of the
> > mmdebstrap-autopkgtest-build-qemu run) as they would "naturally" result
> > from the user's umask:
> >
> > $ cd /dev/shm
> > $ touch foo
> > $ ls -l --si foo
> > -rw-rw---- 1 $USER $USER 0 Jan 27 19:00 foo
>
> They are set, taking the user's umask into account. What is your umask?
Mine is James Bond's umask: 007 ;-)
$ umask
0007
>
> > That's why I manually changed the permissions at the end:
> >
> > $ chmod 660 sid-amd64.img
> > $ ls -l --si sid_amd64.img
> > -rw-rw---- 1 $USER $USER 27G Jan 27 17:48 sid-amd64.img
> >
> > I suggest that mmdebstrap-autopkgtest-build-qemu applies this fix
> > automatically.
>
> Lets first understand the problem before adding a workaround.
> mmdebstrap-autopkgtest-build-qemu runs this command to set the permissions:
>
> chmod "$(printf %o "$(( 0666 - 0$(umask) ))")" "$IMAGE"
This seems to work with Debian default umask (022):
$ printf '%o\n' "$(( 0666 - 00022 ))"
644
but fails whenever a umask includes an octal digit equal to 7, due to
the carryover:
$ printf '%o\n' "$(( 0666 - 00007 ))"
657
Shouldn't this use the bitwise AND combined with the bitwise NOT?
$ umask
0007
$ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
660
$ umask 022
$ umask
0022
$ printf '%o\n' "$(( 0666 & ~0$(umask) ))"
644
I would think that mmdebstrap-autopkgtest-build-qemu should run:
chmod "$(printf %o "$(( 0666 & ~0$(umask) ))")" "$IMAGE"
Does it make sense to you?
>
> Could you add some debugging output to the script to figure out what went
> wrong
> and where?
Feel free to suggest any further debug that could be useful, in case
the above reasoning is not enough to shed some light on what happened.
>
> > * I was surprised to see a 25 GiB image fit into a 7.7 GiB filesystem:
> >
> > $ cd /dev/shm
> > $ ls -l -h sid-amd64.img
> > -rw-rw---- 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
> > $ df -h .
> > Filesystem Size Used Avail Use% Mounted on
> > tmpfs 7.7G 765M 7.0G 10% /dev/shm
> >
> > Well, the mystery is solved by looking at the allocated size:
> >
> > $ ls -l -h -s sid-amd64.img
> > 662M -rw-rw---- 1 $USER $USER 26G Jan 27 17:48 sid-amd64.img
> >
> > Would it be less confusing, if mmdebstrap-autopkgtest-build-qemu created
> > .qcow2 images?
>
> I don't understand why sparse files are confusing to you.
I am clearly not very used to seeing files where the allocated size
greatly differs from the total size:
$ ls -n --si -s sid-amd64.img
694M -rw-rw---- 1 1000 1000 27G Jan 27 17:48 sid-amd64.img
I am more used to seeing files where the two sizes are approximately
equal:
$ ls -n --si -s sid-autopkgtest-amd64.qcow2
950M -rw-r--r-- 1 1000 1000 950M Dec 30 17:55 sid-autopkgtest-amd64.qcow2
Not exactly equal, agreed:
$ ls -n -s sid-autopkgtest-amd64.qcow2
927604 -rw-r--r-- 1 1000 1000 949878784 Dec 30 17:55
sid-autopkgtest-amd64.qcow2
$ calc '927604*1024'
949866496
but very similar, indeed...
> Why would qcow images be less confusing?
Because it seems to me that their total and allocated sizes tend to be
more similar...
> Can you list some reasons why qcow2 should be preferred over
> raw images?
I was under the impression that the qcow2 format was the recommended
one for QEMU/KVM virtual machine images. At least, qemu-img(1)
describes it as "the most versatile format"...
Anyway, if you think that the raw format is a better choice for
autopkgtest and sbuild VM images, I take your word for it.
> Compression comes to mind but that is at the cost of doing that
> compression in the first place and it is not obvious to me whether cpu cycles
> or disk space are more scarce. For example, my platform is an ARM Cortex A53.
> To give you some idea how slow it is: it takes 30 seconds before a youtube
> video starts playing. At the same time, the system has a 2 TB hard disk. I
> much
> prefer a bigger disk image which needs less CPU when I want to create and use
> it. What is your use-case?
I just like to see smaller file sizes, whenever possible.
And I was speaking on the basis of recommendations read in QEMU
documentation, as I said.
But I understand that smaller files come at the cost of more
computation, if they are obtained through compression.
I agree with you that it is not obvious which aspect one should be
willing to sacrifice, in order to improve the other aspect.
>
> Thanks!
Thanks to you. :-)
--
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
pgp5iuZHLoLPF.pgp
Description: PGP signature
