Bug#886332: autopkgtest-virt-qemu: how to make persistent dist-upgrades
Hi Martin,
Quoting Martin Pitt (2018-01-04 16:19:07)
> Johannes Schauer [2018-01-04 15:46 +0100]:
> > 2. document which options to use so that the qemu image is persistently
> > upgraded every time that sbuild runs autopkgtest
>
> The point of autopkgtest is to use ephemeral overlays, not to make anything
> persistent. So this isn't and shouldn't be possible.
>
> > As for (1.), when I run:
> >
> > $ sudo qemu-system-x86_64 -enable-kvm -m 4G -drive format=raw,file=/srv/qemu/unstable-amd64-autopkgtest.img
> >
> > Then I get "no bootable device".
>
> Possibly because this is not a raw device, but a qcow2 image? There's little
> reason to explicitly specify it, just let qemu figure it out by itself. Try
>
> -drive file=/srv/qemu/unstable-amd64-autopkgtest.img,if=virtio
>
> > As for (2.), I was unsuccessful to use the -U option or --setup-commands
> > options to do persisting upgrades. This didn't work:
>
> Right, because autopkgtest-virt-qemu always creates an ephemeral overlay. It
> never ever touches the given VM image.
Thanks! The image indeed turned out to be a qcow image. I should've chosen a
better extension to not get confused about this. ^^
Hrm... but I have some more thoughts and I see how they are out of scope of
this bug and I should maybe open a new one (just tell me if you'd like me to).
My central question: is it totally out of scope for autopkgtest to support
modifying the underlying base image?
When I added the autopkgtest backend to sbuild in addition to schroot, I did
this with the long term goal in mind that at some point I could also update the
sbuild-update program to support the autopkgtest backend. Users could then use
sbuild-update which would automatically do the right thing independent of the
backend. But if you say that autopkgtest never ever touches the VM image this
feature seems to be impossible to implement.
So do you really see such a feature totally out of scope for autopkgtest?
Because unless I'm mistaken, I don't think there exists another software
besides autopkgtest which offers a unified interface to such a wide range of
backends.
Thanks!
cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20180112/af9fb8fb/attachment.sig>
Reply to: