Hi!   :-)

I noticed a problem with 'sbuild-qemu-update'.

After:

  $ mkdir -p ~/.cache/sbuild/build
  $ 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/

I can run 'sbuild-qemu-boot':

  $ sbuild-qemu-boot --boot=efi --shared-dir $(pwd) unstable-autopkgtest-amd64.img

even though the '--shared-dir' option fails to work (see bug [#1101778])

[#1101778]: <https://bugs.debian.org/1101778>

But, as soon as I update the image with:

  $ sbuild-qemu-update --boot=efi unstable-autopkgtest-amd64.img

I can no longer run 'sbuild-qemu-boot':

  $ sbuild-qemu-boot --boot=efi --shared-dir $(pwd) unstable-autopkgtest-amd64.img

  >>Start PXE over IPv4.
    PXE-E16: No valid offer received.
  BdsDxe: failed to load Boot0002 "UEFI PXEv4 (MAC:525400123456)" from PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0): Not Found

  >>Start PXE over IPv6.
    PXE-E16: No valid offer received.
  BdsDxe: failed to load Boot0003 "UEFI PXEv6 (MAC:525400123456)" from PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1)/IPv6(0000:0000:0000:0000:0000:0000:0000:0000,0x0,Static,0000:0000:0000:0000:0000:0000:0000:0000,0x40,0000:0000:0000:0000:0000:0000:0000:0000): Not Found

  >>Start HTTP Boot over IPv4.....
  [...]
  UEFI Interactive Shell v2.2
  EDK II
  UEFI v2.70 (Debian distribution of EDK II, 0x00010000)
  Mapping table
        FS0: Alias(s):HD1b:;BLK2:
            PciRoot(0x0)/Pci(0x7,0x0)/HD(1,GPT,77BEA6C8-A86E-42FD-8D75-0AC28BD562D6)
       BLK0: Alias(s):
            PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
       BLK1: Alias(s):
            PciRoot(0x0)/Pci(0x7,0x0)
       BLK3: Alias(s):
  Press ESC in 1 seconds to skip startup.nsh or any other key to continue.9981CF96
  Shell>

In short, it does not boot.

Please fix 'sbuild-qemu-update' (and/or 'sbuild-qemu-boot').

Thanks for your time and patience!

Control: tag -1 + moreinfo

I cannot reproduce this at the momemt, could you try it again?

Note that from experience, it is quite possible that sbuild-qemu-update
just happened to update in a moment where a GRUB toolchain update within
the VM encountered an issue. This is what I'd suspect here.

Note that you can use pass the --snapshot option to sbuild-qemu-update
and it will create a snapshot of the original image within QCOW2. You
can have multiple of those, and delete them or rollback using qemu-img.

Best,
Christian

Control: tag -1 - moreinfo
[...]

I've just tried again.
I reproduce the same exact misbehavior I originally reported, with the
same exact output/errors.

After updating the image with 'sbuild-qemu-update', I can no longer use
'sbuild-qemu-boot'.
I don't know whether this is due to the image format conversion to QEMU
QCOW Image (v3), or to any other modification introduced by
'sbuild-qemu-update', but I still experience the bug.
[...]

Was the original image in QCOW format?!?

Just after creating the image with 'mmdebstrap-autopkgtest-build-qemu',
before updating it:

  $ 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)

After updating the image with 'sbuild-qemu-update':

  $ file unstable-autopkgtest-amd64.img
  unstable-autopkgtest-amd64.img: QEMU QCOW Image (v3), 26977780736 bytes (v3), 26977780736 bytes

Please clarify.

Thanks for your time and patience!

Ah yes. sbuild-qemu-update boots the image, runs apt-get inside, and
calls fstrim after to discard no longer used blocks on the root fs.

After that, there is a qemu-img convert call, which removes those unused
blocks from the image. Otherwise it would keep on growing and growing.

That could be the source of the problem, though I still can't reproduce
it. However I don't have a pure unstable system at the moment, just
tested this on bookworm will all backports.

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.

Best,
Christian

On Sun, 1 Jun 2025 22:38:40 +0200 Christian Kastner wrote:

[...]


  $ 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)?

Control: tags -1 + moreinfo

Thanks for the pointer, I'll keep that in mind for the next release.

No, not really. I've seen it happen when grub-efi got updated, and
wanted some interactive confirmation that sbuild-qemu-update can't give,
or something like that.

Please report if you see this issue again.

Best,
Christian