Hi,
Quoting Francesco Poli (wintermute) (2024-01-27 19:20:08)
> I've been able to create a QEMU/KVM virtual machine image for autopkgtests:
>
> $ mkdir -p ~/var/cache/sbuild/
> $ cd /dev/shm
> $ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
> --size=25G --boot=efi sid sid-amd64.img
> $ chmod 660 sid-amd64.img
> $ mv -i sid-amd64.img ~/var/cache/sbuild/
>
> It is able to run autopkgtests:
>
> $ autopkgtest --output-dir ./${SRCPKG}_autopkgtest.out \
> --summary ./${SRCPKG}_autopkgtest.summary \
> --apt-upgrade -B ./${SRCPKG}_amd64.changes -- \
> qemu --boot=efi --overlay-dir /dev/shm \
> ~/var/cache/sbuild/sid-amd64.img
>
> 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.
> 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?
> 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"
Could you add some debugging output to the script to figure out what went wrong
and where?
> * 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. Why would qcow images
be less confusing? Can you list some reasons why qcow2 should be preferred over
raw images? 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?
Thanks!
cheers, josch
signature.asc
Description: signature
