Package: sbuild-qemu
Version: 0.85.10
Severity: normal
X-Debbugs-Cc: invernom...@paranoici.org
Hello!
I've just found out something worrying about sbuild-qemu-update.
I noticed that my image allocated size was bigger than I remembered:
$ cd ~/.cache/sbuild/
$ ls -alrtFs --si OLD_unstable-autopkgtest-amd64.img
3.6G -rw-rw---- 1 $USER $USER 27G Jun 9 22:00
OLD_unstable-autopkgtest-amd64.img
Then, I tried to regenerate it from scratch:
$ cd /dev/shm
$ TMPDIR=/dev/shm mmdebstrap-autopkgtest-build-qemu \
--size=25G --boot=efi sid unstable-autopkgtest-amd64.img
$ mv -i unstable-autopkgtest-amd64.img ~/.cache/sbuild/
And I checked again:
$ cd ~/.cache/sbuild/
$ ls -altrFs --si
total 4.3G
4.1k drwx------ 37 $USER $USER 4.1k May 4 16:03 ../
4.1k drwxrwx--- 2 $USER $USER 4.1k May 13 23:19 build/
3.6G -rw-rw---- 1 $USER $USER 27G Jun 9 22:00
OLD_unstable-autopkgtest-amd64.img
705M -rw-rw---- 1 $USER $USER 27G Jun 16 18:22
unstable-autopkgtest-amd64.img
4.1k drwxrwx--- 3 $USER $USER 4.1k Jun 16 18:26 ./
What? The allocated size is 705 MB for the newly generated image, while
it is 3.6 GB for the old one ???
OK, using the image to test packages with autopkgtest or to build
packages with sbuild-qemu should not touch the image (just create
epheremal overlays, is that correct?).
Hence, it must be sbuild-qemu-update that increases the allocated size...
I tried to run sbuild-qemu-update on the newly generated image.
Of course it found nothing to update:
$ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img
qemu-system-x86_64 -enable-kvm -drive
if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd
-object rng-random,filename=/dev/urandom,id=rng0 -device
virtio-rng-pci,rng=rng0,id=rng-device0 -device virtio-serial -nic
user,model=virtio -m 1024 -smp 1 -nographic
/home/$USER/.cache/sbuild/unstable-autopkgtest-amd64.img
root
Linux host 6.8.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.8.12-1 (2024-05-31)
x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet update
DEBIAN_FRONTEND=noninteractive apt-get --quiet update
Hit:1 http://deb.debian.org/debian sid InRelease
Reading package lists...
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes
dist-upgrade
DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes dist-upgrade
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes clean
DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes clean
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes
autoremove
DEBIAN_FRONTEND=noninteractive apt-get --quiet --assume-yes autoremove
Reading package lists...
Building dependency tree...
Reading state information...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
root@host:~# sync
sync
root@host:~# sleep 1
sleep 1
root@host:~# shutdown -h now
But, the allocated size has significantly grown:
$ cd ~/.cache/sbuild/
$ ls -altrFs --si
total 4.4G
4.1k drwx------ 37 $USER $USER 4.1k May 4 16:03 ../
4.1k drwxrwx--- 2 $USER $USER 4.1k May 13 23:19 build/
3.6G -rw-rw---- 1 $USER $USER 27G Jun 9 22:00
OLD_unstable-autopkgtest-amd64.img
4.1k drwxrwx--- 3 $USER $USER 4.1k Jun 16 18:26 ./
832M -rw-rw---- 1 $USER $USER 27G Jun 16 18:26
unstable-autopkgtest-amd64.img
Now the allocated size is 832 MB, instead of 705 MB !!!
That could explain how I had reached 3.6 GB, one run of sbuild-qemu-update
after the other...
But why does the allocated size increase?
Maybe there's something about sparse file support that I do not
fully understand.
Is there anything that can be done inside sbuild-qemu-update to prevent
the allocated size from growing indefinitely?
Apart from periodically regenerating the image from scratch, I mean...
Please let me know.
Thanks again for developing sbuild-qemu.
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sbuild-qemu depends on:
ii autopkgtest 5.35
ii python3 3.11.8-1
ii python3-pexpect 4.9-2
ii python3-psutil 5.9.8-2
ii qemu-system-x86 1:8.2.4+ds-1
ii qemu-utils 1:8.2.4+ds-1
ii sbuild 0.85.10
ii vmdb2 0.40-1
Versions of packages sbuild-qemu recommends:
ii qemu-system-arm 1:8.2.4+ds-1
ii qemu-system-ppc 1:8.2.4+ds-1
sbuild-qemu suggests no packages.
-- no debconf information
