Dear Maintainer,

Trying to create an unstable arm64 sbuild qemu img from a stable system
fails.  The command I use:

,----
| $ time sudo sbuild-qemu-create unstable --arch arm64 https://deb.debian.org/debian --authorized-keys=<path_to_authorized_keys_file>  # Removed authorized_keys file path to avoid privacy leak.  File does exist.
`----

And it fails with the following error (first Python exception I observe
from the log):

,----
| 2025-01-15 17:19:39 INFO Exec: ['mount', '/dev/mapper/loop0p1', '/tmp/tmp0n3zu1jh/boot/efi']
| 2025-01-15 17:19:39 DEBUG STDOUT:
| 2025-01-15 17:19:39 DEBUG STDERR: mount: /tmp/tmp0n3zu1jh/boot/efi: /dev/mapper/loop0p1 already mounted on /tmp/tmp0n3zu1jh/boot/efi.
|        dmesg(1) may have more information after failed mount system call.
|
| 2025-01-15 17:19:39 ERROR Program failed: 32
| Traceback (most recent call last):
|   File "/usr/lib/python3/dist-packages/vmdb/app.py", line 243, in run_steps_helper
|     method(values, settings, state)
|   File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 103, in run
|     self.install_uefi(values, settings, state)
|   File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 133, in install_uefi
|     self.install_grub(values, settings, state, grub_package, grub_target)
|   File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 179, in install_grub
|     self.mount(chroot, efi_dev, "/boot/efi", state)
|   File "/usr/lib/python3/dist-packages/vmdb/plugins/grub_plugin.py", line 350, in mount
|     vmdb.runcmd(["mount"] + mount_opts + [path, chroot_path])
|   File "/usr/lib/python3/dist-packages/vmdb/runcmd.py", line 58, in runcmd
|     raise RuncmdError("Program failed: {}".format(p.returncode))
| vmdb.runcmd.RuncmdError: Program failed: 32
`----

This seems to suggest that it's a vmdb2 issue, but as the failure
originates from running sbuild-qemu-create I'm reporting to sbuild-qemu
as a first step just to be sure.  Please feel free to reassign.

I'm also attaching the full log in case I missed anything.

Hi Xiyue,

I can reproduce this on stable with vmdb2=0.27+really.0.26-1+deb12u1,
and it seems to be resolved with 0.28-2 which I still had around.

I guess sbuild-qemu should depend on at least 0.28 anyway, as that
version fixes Ubuntu EFI image builds which are otherwise broken
entirely (regardless of arch).

Best,
Christian

Hi Christian,

Christian Kastner <ckk@debian.org> writes:

Thanks for the info!  Is it possible to request a stable update for this
issue?  Personally if a newer vmdb2 version can be backported to stable
I'm happy :)

wrapper around autopkgtest-build-qemu, so the failure should already
occur with that tool.
but the one change I thought relevant did not fix this.

In any case, given the nature of this tool, I think it would be better
to have a backported 0.40 anyway. I'm happy to help with that, if time
is a concern.

sbuild and autopkgtest are already frequently backported, so a
backported vmdb2 would round things out nicely.

Best,
Christian

found 1093165 0.27+really.0.26-1+deb12u1
notfound 1093165 0.40-2
notfound 1093165 0.41-1
tags 1093165 wontfix
thanks

Hello,

I'm sorry for not having replied previously to this bug; I still have it
present in my mailbox, looking for some time opening to fix it.

However, given the affected version is now only in oldstable, my
recommendation would be to upgrade to stable.

I'm not closing this bug, as it is not formally fixed, but just noting it
is not a bug I'll be working on. I hope you find my reasoning acceptable!