Tails

#1 Updated by anonym 2020-02-03 13:57:57

In Debian Buster we’ll have qemu 3.1, but it lacks support to save snapshots in a nested setup, which is bad news for our Jenkins setup (and everyone using nested setups). From the qemu 3.1 changelog: “x86 machines cannot be live-migrated if nested Intel virtualization is enabled. The next version of QEMU will be able to do live migration when nested virtualization is enabled, if supported by the kernel.”

It is fixed in qemu 4.2, which is in Debian Bullseye, so if it gets backported we could use that. Otherwise we can downgrade to Debian Stretch’s qemu 2.8, which also works. I have verified that both of these options work.

#5 Updated by intrigeri 2020-02-04 13:21:40

> It is fixed in qemu 4.2, which is in Debian Bullseye, so if it gets backported we could use that. Otherwise we can downgrade to Debian Stretch’s qemu 2.8, which also works. I have verified that both of these options work.

Just to be clear: you’ve locally backported 4.2 for Buster and it solves this problem, right?

I don’t expect there will be official backports for Buster and I don’t think maintaining them ourselves would be a good use of our resources.

Note that we’ve been requiring a custom QEMU package (in our isotester-stretch repo) for a while in order to run our test suite. I think it went mostly fine for developers. So we could do this:

• Bullseye and newer (developers): use QEMU from Debian
• Buster (developers, future CI): use custom backport uploaded to our isotester-stretch repo
• Stretch (developers, current CI): drop support once Stretch is EOL in a few months, so we can stop maintaining our Stretch QEMU; to make this work, notify sysadmins and developers a while before, so they have time to upgrade stuff to Buster

How does this sound?

#6 Updated by anonym 2020-02-05 09:27:20

intrigeri wrote:
> > It is fixed in qemu 4.2, which is in Debian Bullseye, so if it gets backported we could use that. Otherwise we can downgrade to Debian Stretch’s qemu 2.8, which also works. I have verified that both of these options work.
>
> Just to be clear: you’ve locally backported 4.2 for Buster and it solves this problem, right?

Ah, no, and I see how what I wrote was unclear, sorry! I meant that I have successfully run the test suite on:

• Debian Buster with qemu from stretch
• Debian Bullseye with its qemu

So I haven’t done any backport. I just now tried to see if a trivial rebuild would work, but it failed due to a new dependency missing in Buster, libslirp-dev. But that’s just a single dep, and backporting it as well looks easy (no additional deps). Of course, this might get harder as the Buster vs Bullseye delta grows.

> I don’t expect there will be official backports for Buster and I don’t think maintaining them ourselves would be a good use of our resources.

Are you saying that the plan you outline below is not a good use of our resources? Please clarify!

> Note that we’ve been requiring a custom QEMU package (in our isotester-stretch repo) for a while in order to run our test suite. I think it went mostly fine for developers. So we could do this:
>
> * Bullseye and newer (developers): use QEMU from Debian
> * Buster (developers, future CI): use custom backport uploaded to our isotester-stretch repo
> * Stretch (developers, current CI): drop support once Stretch is EOL in a few months, so we can stop maintaining our Stretch QEMU; to make this work, notify sysadmins and developers a while before, so they have time to upgrade stuff to Buster
>
> How does this sound?

Sounds good to me. Is there even any alternative? If Stretch is EOL soon, I guess it won’t receive security fixes so staying on Stretch’s version won’t work for long.

#7 Updated by intrigeri 2020-02-05 10:02:33

Hi!

anonym wrote:
> I just now tried to see if a trivial rebuild would work, but it failed due to a new dependency missing in Buster, libslirp-dev. But that’s just a single dep, and backporting it as well looks easy (no additional deps). Of course, this might get harder as the Buster vs Bullseye delta grows.

I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere). But indeed, this might not be the case for future new {build,runtime} deps.

> intrigeri wrote:
>> I don’t expect there will be official backports for Buster and I don’t think maintaining them ourselves would be a good use of our resources.
>
> Are you saying that the plan you outline below is not a good use of our resources? Please clarify!

What I wrote above applies only to an official backport, as in “uploaded to Debian and maintained — until Buster in EOL — under Debian rules”. I don’t think maintaining such a backport would be a good use of our resources.

While what I proposed below instead applies to a custom backport, i.e. uploaded to our custom APT repository.

Clearer?

>> How does this sound?
>
> Sounds good to me.

:)

> Is there even any alternative? If Stretch is EOL soon, I guess it won’t receive security fixes so staying on Stretch’s version won’t work for long.

I expect QEMU will be in the scope of Stretch LTS (and hopefully so because we have no plan to upgrade to Buster our main virtualization server), so yes, in theory we could keep maintaining support for running the test suite on Stretch. But I’d rather not have to maintain 2 custom QEMU packages for too long. A 6 months transition period would be OK, I guess, but longer than that, please, no ⇒ the earlier the clock countdown starts, the better, IMO :)

#8 Updated by anonym 2020-02-05 11:04:02

intrigeri wrote:
> anonym wrote:
> > I just now tried to see if a trivial rebuild would work, but it failed due to a new dependency missing in Buster, libslirp-dev. But that’s just a single dep, and backporting it as well looks easy (no additional deps). Of course, this might get harder as the Buster vs Bullseye delta grows.
>
> I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere).

Cool, I was unsure what it was used for.

> But indeed, this might not be the case for future new {build,runtime} deps.
>
> > intrigeri wrote:
> >> I don’t expect there will be official backports for Buster and I don’t think maintaining them ourselves would be a good use of our resources.
> >
> > Are you saying that the plan you outline below is not a good use of our resources? Please clarify!
>
> What I wrote above applies only to an official backport, as in “uploaded to Debian and maintained — until Buster in EOL — under Debian rules”. I don’t think maintaining such a backport would be a good use of our resources.
>
> While what I proposed below instead applies to a custom backport, i.e. uploaded to our custom APT repository.
>
> Clearer?

Yes, now I get it!

> >> How does this sound?
> >
> > Sounds good to me.
>
> :)

Let’s settle on this plan, then!

> > Is there even any alternative? If Stretch is EOL soon, I guess it won’t receive security fixes so staying on Stretch’s version won’t work for long.
>
> I expect QEMU will be in the scope of Stretch LTS (and hopefully so because we have no plan to upgrade to Buster our main virtualization server), so yes, in theory we could keep maintaining support for running the test suite on Stretch. But I’d rather not have to maintain 2 custom QEMU packages for too long. A 6 months transition period would be OK, I guess, but longer than that, please, no ⇒ the earlier the clock countdown starts, the better, IMO :)

Agreed.

#9 Updated by intrigeri 2020-02-05 11:08:12

>> I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere).
>
> Cool, I was unsure what it was used for.

IIRC slirp is some kind of userspace networking mode which is mostly useful when running QEMU without root, or to hook all kinds of interesting userspace network mangling in the loop (this sort of things could be useful some day for post-Wayland Unsafe Browser confinement or similar, for example). AFAICT we don’t use this anywhere with QEMU in Tails-land :)

#10 Updated by anonym 2020-02-05 13:24:37

intrigeri wrote:
> >> I suspect that in the context of a private, Tails-only backport, we could simply drop this build-dep and disable the corresponding feature when calling ./configure (I doubt we use this functionality anywhere).

I dropped --enable-slirp=system and the corresponding libslirp-dev and built a backported qemu 4.2, and I see no more snapshot problems under Buster. Yay!

> > Cool, I was unsure what it was used for.
>
> IIRC slirp is some kind of userspace networking mode which is mostly useful when running QEMU without root, or to hook all kinds of interesting userspace network mangling in the loop (this sort of things could be useful some day for post-Wayland Unsafe Browser confinement or similar, for example). AFAICT we don’t use this anywhere with QEMU in Tails-land :)

Thanks for the explanation!

#11 Updated by intrigeri 2020-02-05 20:24:50

> I dropped --enable-slirp=system and the corresponding libslirp-dev and built a backported qemu 4.2, and I see no more snapshot problems under Buster. Yay!

Oooooh yeah!

#19 Updated by intrigeri 2020-04-16 09:01:25

What’s left to do here?