Bug#1061636: mmdebstrap-autopkgtest-build-qemu VM image cannot be updated with sbuild-qemu-update

[Francesco Poli (wintermute)]

Package: mmdebstrap
Version: 1.4.1-1
Severity: normal

Hello again Johannes!

As I said in bug report [#1061634], 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/

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

It works for autopkgtests, but I wanted to use the same virtual machine
image to build Debian packages with sbuild-qemu.
The first thing I tested is the update of the VM image with
sbuild-qemu-update:

$ sbuild-qemu-update --arch=amd64 sid-amd64.img
qemu-system-x86_64 -enable-kvm -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 sid-amd64.img

This command does not seem to work: it uses 100 % of one CPU core and
seemingly does nothing, until I interrupt it by pressing [Ctrl+C].

Is there any special tweak or configuration needed to use
sbuild-qemu-update with mmdebstrap-autopkgtest-build-qemu VM images?
Where is this documented?

Otherwise, if this is an actual bug, please fix
mmdebstrap-autopkgtest-build-qemu
or help sbuild-qemu developers to fix sbuild-qemu-update.

Thanks for your time and dedication!



-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (800, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-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 mmdebstrap depends on:
ii apt 2.7.10
ii perl 5.38.2-3
ii python3 3.11.6-1

Versions of packages mmdebstrap recommends:
ii arch-test 0.21-1
ii fakechroot 2.20.1+ds-15
ii fakeroot 1.33-1
ii gpg 2.2.40-1.1+b1
ii libdistro-info-perl 1.7
ii libdpkg-perl 1.22.2
ii mount 2.39.3-6
ii uidmap 1:4.13+dfsg1-3+b1

Versions of packages mmdebstrap suggests:
pn apt-transport-tor <none>
ii apt-utils 2.7.10
ii ca-certificates 20230311
ii debootstrap 1.0.134
ii distro-info-data 0.60
ii dpkg-dev 1.22.2
pn genext2fs <none>
ii perl-doc 5.38.2-3
pn qemu-user <none>
pn qemu-user-static <none>
pn squashfs-tools-ng <none>
ii systemd 255.2-4

-- no debconf information

[Johannes Schauer Marin Rodrigues]

Quoting Francesco Poli (wintermute) (2024-01-27 19:44:15)

> As I said in bug report [#1061634], 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/
>
> [#1061634]: <https://bugs.debian.org/1061634>
>
> It works for autopkgtests, but I wanted to use the same virtual machine
> image to build Debian packages with sbuild-qemu.
> The first thing I tested is the update of the VM image with
> sbuild-qemu-update:
>
> $ sbuild-qemu-update --arch=amd64 sid-amd64.img
> qemu-system-x86_64 -enable-kvm -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 sid-amd64.img
>
> This command does not seem to work: it uses 100 % of one CPU core and
> seemingly does nothing, until I interrupt it by pressing [Ctrl+C].
>
> Is there any special tweak or configuration needed to use
> sbuild-qemu-update with mmdebstrap-autopkgtest-build-qemu VM images?
> Where is this documented?
>
> Otherwise, if this is an actual bug, please fix
> mmdebstrap-autopkgtest-build-qemu

The images you create with mmdebstrap-autopkgtest-build-qemu require efi. But
sbuild-qemu does pass the --boot parameter to autopkgtest-virt-qemu. If you are
on amd64 and if your image is for amd64, then autopkgtest-virt-qemu will
default to bios boot which is incompatible with the images created by
mmdebstrap-autopkgtest-build-qemu. You could add a dirty local hack to
sbuild-qemu and let it add --boot=efi via --autopkgtest-virt-server-opt to see
if this is it. If that is the problem, please re-assign this bug to sbuild.

> or help sbuild-qemu developers to fix sbuild-qemu-update.

Did you look up who the sbuild developers are? ;)

> Thanks for your time and dedication!

Thank you for your bugs!! <3

cheers, josch

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Johannes Schauer Marin Rodrigues (2024-01-28 00:46:10)

> Quoting Francesco Poli (wintermute) (2024-01-27 19:44:15)

> > Is there any special tweak or configuration needed to use
> > sbuild-qemu-update with mmdebstrap-autopkgtest-build-qemu VM images? Where
> > is this documented?
> >
> > Otherwise, if this is an actual bug, please fix
> > mmdebstrap-autopkgtest-build-qemu
>
> The images you create with mmdebstrap-autopkgtest-build-qemu require efi. But
> sbuild-qemu does pass the --boot parameter to autopkgtest-virt-qemu. If you are
> on amd64 and if your image is for amd64, then autopkgtest-virt-qemu will
> default to bios boot which is incompatible with the images created by
> mmdebstrap-autopkgtest-build-qemu. You could add a dirty local hack to
> sbuild-qemu and let it add --boot=efi via --autopkgtest-virt-server-opt to
> see if this is it. If that is the problem, please re-assign this bug to
> sbuild.

you found bugs in both sbuild as well as in mmdebstrap. The fixes for sbuild
are in this MR:

https://salsa.debian.org/debian/sbuild/-/merge_requests/54

Feel free to comment and improve on the code as well to get this forward.

The mmdebstrap bug is fixed here:

https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/3e233e10dfe414e43b31d328eecb0c776afc2ec3

Thanks!

cheers, josch

[Francesco Poli]

On Sun, 28 Jan 2024 17:22:32 +0100 Johannes Schauer Marin Rodrigues
wrote:

[...]

> you found bugs in both sbuild as well as in mmdebstrap.

Well, actually *you* found the bugs, I have just attempted to run a
command and reported that it didn't work...
Credit where credit is due! :-)

> The fixes for sbuild are in this MR:
>
> https://salsa.debian.org/debian/sbuild/-/merge_requests/54
>
> Feel free to comment and improve on the code as well to get this forward.

I am not familiar with the sqbuild code base, so I won't comment on the
code style.
I am confident that the MR will fix the bug.

Thanks for preparing it!

Maybe this bug report should cloned and reassigned to sbuild-qemu?

>
> The mmdebstrap bug is fixed here:
>
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/3e233e10dfe414e43b31d328eecb0c776afc2ec3
>
> Thanks!

Good to see that this other bug is going to be fixed, as well.

I am looking forward to seeing all these changes uploaded to Debian.
Thanks a lot!


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

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Francesco Poli (2024-01-29 00:12:27)

> Maybe this bug report should cloned and reassigned to sbuild-qemu?

if you like (for example because you want to subscribe to it and notified when
it gets closed) then feel free to clone it. Personally, as long as the issue is
tracked some place obvious (and that includes a salsa MR) I'm fine with it as I
just want to make sure that the issue is not getting lost. Whether it gets
tracked in the debian bts or as a salsa MR dosen't matter to me. But as i said,
if for you, a bts issue makes more sense, feel free to clone.

Thanks!

cheers, josch

[Francesco Poli]

Control: clone -1 -2
Control: reassign -2 sbuild-qemu 0.85.4
Control: reopen -2

On Mon, 29 Jan 2024 08:38:59 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]

> Quoting Francesco Poli (2024-01-29 00:12:27)
> > Maybe this bug report should cloned and reassigned to sbuild-qemu?
>
> if you like (for example because you want to subscribe to it and notified when
> it gets closed) then feel free to clone it.

[...]

Yes, I think it makes sense to have a separate bug report, so that I
can be easily notified, once it becomes pending and once it gets closed.

Thanks!

[Francesco Poli]

On Mon, 29 Jan 2024 21:07:52 +0100 Francesco Poli wrote:

[...]
> Yes, I think it makes sense to have a separate bug report, so that I
> can be easily notified, once it becomes pending and once it gets closed.
>
> Thanks!

Hello!
I see that [MR 54] has been merged.

[MR 54]: <https://salsa.debian.org/debian/sbuild/-/merge_requests/54>

Is there anything else that needs to be fixed/enhanced in sbuild-qemu,
in order for sbuild-qemu-update to be able to update
mmdebstrap-autopkgtest-build-qemu VM images?

If not, I think this bug report (#1061816) should be marked as pending.
And probably mentioned in some debian/changelog entry. Or in some
commit message, if you generate debian/changelog from commit messages...

Please let me know, thanks for your time!

[Johannes Schauer Marin Rodrigues]

Control: tag -1 + pending

Hi Francesco


Quoting Francesco Poli (2024-02-12 22:46:29)

> On Mon, 29 Jan 2024 21:07:52 +0100 Francesco Poli wrote:
> > Yes, I think it makes sense to have a separate bug report, so that I
> > can be easily notified, once it becomes pending and once it gets closed.
> >
> > Thanks!

> I see that [MR 54] has been merged.
>
> [MR 54]: <https://salsa.debian.org/debian/sbuild/-/merge_requests/54>

yes, thanks to the work of Christian (in CC).

> Is there anything else that needs to be fixed/enhanced in sbuild-qemu,
> in order for sbuild-qemu-update to be able to update
> mmdebstrap-autopkgtest-build-qemu VM images?

Theoretically not. If you want to make sure, feel free to clone the git and try
it out.

> If not, I think this bug report (#1061816) should be marked as pending.

Done.

> And probably mentioned in some debian/changelog entry. Or in some
> commit message, if you generate debian/changelog from commit messages...

Christian is probably going to do this on the next upload.

Thanks!

cheers, josch

[Francesco Poli]

Control: notfixed 1061636 sbuild/0.85.5

On Mon, 12 Feb 2024 23:19:40 +0100 Johannes Schauer Marin Rodrigues wrote:

[...]

> Quoting Francesco Poli (2024-02-12 22:46:29)

[...]

> > If not, I think this bug report (#1061816) should be marked as pending.
>
> Done.
>
> > And probably mentioned in some debian/changelog entry. Or in some
> > commit message, if you generate debian/changelog from commit messages...
>
> Christian is probably going to do this on the next upload.

Yes, he has just done so, but he apparently closed the original bug
report (which was against mmdebstrap and was already closed), rather
than the cloned bug report.

The above control commands should rectify the situation for the
original bug report, if I am not mistaken...