Feature #12532

Do not upgrade the kernel while provisioning the Vagrant builder VM

Added by anonym 2017-05-10 15:45:35 . Updated 2017-09-28 19:00:03 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Build system
Target version:
Tails_3.2
Start date:
2017-05-10
Due date:
% Done:

50%

Feature Branch:
Type of work:
Discuss
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

The Vagrant builder VMs will never reboot, so upgrading the kernel while provisioning (which can happend due to the apt-get dist-upgrade) would just slow down each build.

All APT repos are frozen (via time-based snapshots) for any given base box, except debian-security, so the only way a kernel update could happen is if it’s in debian-security. But we currently install the kernel from Debian backports, which has a higher version than the one in stable/debian-security, so it’s highly unlikely that an upgrade will be pulled, so caring about this might seem unnecessary.

However, I expect that once we upgrade the builder VM to Debian Stretch, we will not install any backported kernel for a while (there probably won’t be one) and during this window we will be affected by this. We’ll probably have such a window each time we upgrade to a new Debian release. Hence we should, when generating the base box, pin the kernel that we end up with so that it is never upgraded.

Subtasks

History

#1 Updated by intrigeri 2017-05-10 16:24:30

  • Target version changed from Tails_3.0 to Tails_3.1

IMO we’ll just use the Stretch kernel once we have upgraded our Vagrant basebox to Stretch, and we do control when we upgrade it to Stretch, so we can skip the part about backports in this reasoning. I agree this would be a nice optimization to have once we’ve upgraded the basebox to Stretch, but it’ll be useless until then, and we have more urgent things to do by June 13, so I’m postponing this ticket a little bit. It would be nice to mark this as related to the ticket we (should?) have about upgrading our Vagrant basebox to Stretch. Also, IMO we could stick to Jessie in the basebox until it’s not supported anymore (~3 more years thanks to LTS) and not bother until then.

#2 Updated by bertagaz 2017-07-03 09:16:55

anonym wrote:
> The Vagrant builder VMs will never reboot, so upgrading the kernel while provisioning (which can happend due to the apt-get dist-upgrade) would just slow down each build.

Since then we install the jessie-backports kernel during the box creation. So that’s the kernel booted to build Tails, no kernel upgrade for nothing.

intrigeri wrote:
> Also, IMO we could stick to Jessie in the basebox until it’s not supported anymore (~3 more years thanks to LTS) and not bother until then.

I propose we open a ticket “Upgrade Vagrant build basebox to Stretch” and refer to this very ticket in a note about the kernel subtilities it may involve (conclusion of this ticket description).

Pining (or un-pining) a kernel in the build VM is not such a big patch in the box generation script, we should manage to find something, when the need comes. :)

#3 Updated by intrigeri 2017-07-04 10:12:23

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 50
  • Type of work changed from Code to Discuss

bertagaz wrote:
> I propose we open a ticket “Upgrade Vagrant build basebox to Stretch” and refer to this very ticket in a note about the kernel subtilities it may involve (conclusion of this ticket description).

jessie-backports won’t support LTS, so at some point (when non-LTS Jessie reaches EOL mid-2018) we won’t be able to build our Jessie-based Vagrant VM anymore. So I think we should:

  • install the kernel from Stretch (and not from jessie-backports) in our build VM; we could do this in 2017, to avoid having to do it in a hurry when everything suddenly breaks;
  • stick to Jessie LTS for non-kernel packages, until Buster is out; we’ll need to enable the LTS repo mid-2018 BTW (in our APT time-based snapshots and in the Vagrant build VM config);
  • file a ticket the way bertagaz suggests, modulo s/Stretch/Buster/;
  • reject this ticket.

anonym, what do you think?

#4 Updated by anonym 2017-07-06 14:15:07

  • Target version changed from Tails_3.1 to Tails_3.2

#5 Updated by intrigeri 2017-09-07 07:18:47

  • Status changed from In Progress to Rejected
  • Assignee deleted (anonym)

So, our basebox now runs Stretch and Linux from Stretch. Kernel upgrades still happen when provisioning e.g. I’ve just seen an upgrade of linux-image-4.9.0-3-amd64 to 4.9.30-2+deb9u3 (FWIW, I was building the bugfix/8281-replace-florence-with-gnome-osk branch).

This useless upgrade takes ~30 seconds (download + unpack + update initramfs & GRUB config) on recent builds of the devel branch on Jenkins, which is totally irrelevant considering a full build takes around 75 minutes.

So the only expected benefits from working on this are: 1. avoid build system developer confusion (somewhat hypothetical); 2. improve developer UX when building locally with a poor Internet connection (every time a kernel upgrade lands in the Debian stable security repos they’ll have to download it; this happened 9 times in the last 12 months for the Jessie kernel; they’ll have to download kernel upgrades and various other updates for the ISO anyway, so I think the optimization this ticket is about won’t make a big difference for them).

=> I see extremely little value in spending any time on this problem. Surely our optimization efforts would be better focussed elsewhere.

#6 Updated by anonym 2017-09-28 18:56:05

  • Target version changed from Tails_3.2 to Tails_3.3

#7 Updated by anonym 2017-09-28 19:00:03

  • Target version changed from Tails_3.3 to Tails_3.2