On Sun, 1 Jun 2025 22:38:40 +0200 Christian Kastner wrote: [...] > Could you create an image, boot is with sbuild-qemu-boot, and manually > run commands found in the update_interaction() function of > /usr/bin/sbuild-qemu-boot? I'm particularly interested in whether the > remount and fstrim are causing this. > > If not, it has to be the qemu-img convert after that.
Well...
$ 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/
$ cd ~/.cache/sbuild/
$ sbuild-qemu-boot --boot=efi --read-write unstable-autopkgtest-amd64.img
host login: root
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet update
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet \
--assume-yes dist-upgrade
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet \
--assume-yes clean
root@host:~# DEBIAN_FRONTEND=noninteractive apt-get --quiet \
--assume-yes autoremove
root@host:~# sync
root@host:~# mount -o remount,discard /
root@host:~# fstrim /
root@host:~# sync
root@host:~# sleep 1
root@host:~# shutdown -h now
$ sbuild-qemu-boot --boot=efi unstable-autopkgtest-amd64.img
host login: root
root@host:~# df --si -x tmpfs
Filesystem Size Used Avail Use% Mounted on
udev 1.1G 0 1.1G 0% /dev
/dev/vda2 27G 743M 25G 3% /
efivarfs 263k 9.8k 248k 4% /sys/firmware/efi/efivars
/dev/vda1 132M 49M 83M 38% /efi
root@host:~# poweroff
At this point the image is still bootable with 'sbuild-qemu-boot'...
$ qemu-img convert -O qcow2 unstable-autopkgtest-amd64.img
unstable-autopkgtest-amd64.img.tmp
$ mv unstable-autopkgtest-amd64.img.tmp unstable-autopkgtest-amd64.img
N.B.: this temporary file should be created in a safer way (with something
similar to mktemp)...
$ file unstable-autopkgtest-amd64.img
unstable-autopkgtest-amd64.img: QEMU QCOW Image (v3), 26977780736 bytes (v3),
26977780736 bytes
$ cd
$ sbuild-qemu-boot --boot=efi unstable-autopkgtest-amd64.img
host login: root
root@host:~# df --si -x tmpfs
Filesystem Size Used Avail Use% Mounted on
udev 1.1G 0 1.1G 0% /dev
/dev/vda2 27G 743M 25G 3% /
efivarfs 263k 9.8k 248k 4% /sys/firmware/efi/efivars
/dev/vda1 132M 49M 83M 38% /efi
root@host:~# poweroff
After this conversion, the image is still bootable with 'sbuild-qemu-boot'.
Why?!?
Was I seeing ghosts?!?
Let's retry with the automated procedure:
$ rm ~/.cache/sbuild/unstable-autopkgtest-amd64.img
$ 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/
$ cd ~/.cache/sbuild/
$ file unstable-autopkgtest-amd64.img
unstable-autopkgtest-amd64.img: DOS/MBR boot sector; partition 1 : ID=0xee,
start-CHS (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 52690977 sectors,
extended partition table (last)
$ cd
$ sbuild-qemu-boot --boot=efi unstable-autopkgtest-amd64.img
host login: root
root@host:~# df --si -x tmpfs
Filesystem Size Used Avail Use% Mounted on
udev 1.1G 0 1.1G 0% /dev
/dev/vda2 27G 527M 25G 3% /
efivarfs 263k 11k 247k 5% /sys/firmware/efi/efivars
/dev/vda1 132M 49M 83M 38% /efi
root@host:~# poweroff
$ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img
$ cd ~/.cache/sbuild
$ file unstable-autopkgtest-amd64.img
unstable-autopkgtest-amd64.img: QEMU QCOW Image (v3), 26977780736 bytes (v3),
26977780736 bytes
$ cd
$ sbuild-qemu-boot --boot=efi unstable-autopkgtest-amd64.img
host login: root
root@host:~# df --si -x tmpfs
Filesystem Size Used Avail Use% Mounted on
udev 1.1G 0 1.1G 0% /dev
/dev/vda2 27G 743M 25G 3% /
efivarfs 263k 9.8k 248k 4% /sys/firmware/efi/efivars
/dev/vda1 132M 49M 83M 38% /efi
root@host:~# poweroff
I don't know what to say... When I tried again two days ago, I was
reproducing the same exact bug as originally reported!
Now, I am no longer seeing it.
I am really puzzled.
I would like this to always work, not intermittently...
Any idea about what could have changed (in unstable, since the VM is a
sid image, or in testing, since the host is a trixie system)?
--
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
pgptog26aq5Nv.pgp
Description: PGP signature
