Project

General

Profile

Bug #12529

Feature #5630: Reproducible builds

Vagrant box creation needlessly downloads Linux from debian-security

Added by intrigeri 4 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Build system
Target version:
Start date:
05/10/2017
Due date:
% Done:

100%

QA Check:
Pass
Feature Branch:
bugfix/12529-simplify-kernel-install-in-vagrant
Type of work:
Code
Blueprint:
Easy:
Affected tool:

Description

The bootstrap installs Linux from Jessie, which we can't do much about. Then the upgrade downloads an updated kernel from debian-security, which will be unused, since we install Linux from jessie-backports later on.

We should instead install the backports kernel immediately after apt-get update, then purge the jessie kernel, and finally upgrade. This would save quite some time on slow connections when debian-security has a newer kernel than stable.

Similarly, the "Installing Tails build dependencies" bits could be run before apt-get -y dist-upgrade, so we would never upgrade anything twice :)

This matters more now that we will be creating Vagrant boxes locally much more often than before.

What do you think?

Associated revisions

Revision c461974f (diff)
Added by bertagaz 4 months ago

Install kernel from backports and Tails build deps before performing APT upgrade.

Refs: #12529

Revision b6eb7fa0
Added by anonym 4 months ago

Merge remote-tracking branch 'origin/bugfix/12529-simplify-kernel-install-in-vagrant' into testing

Fix-committed: #12529

History

#1 Updated by anonym 4 months ago

  • Assignee changed from bertagaz to anonym

intrigeri wrote:

The bootstrap installs Linux from Jessie, which we can't do much about. Then the upgrade downloads an updated kernel from debian-security, which will be unused, since we install Linux from jessie-backports later on.

We should instead install the backports kernel immediately after apt-get update, then purge the jessie kernel, and finally upgrade. This would save quite some time on slow connections when debian-security has a newer kernel than stable.

Sounds good!

While we're at it, we should consider pinning the exact kernel version installed during base box creation so the kernel is never upgraded during provisioning. Of course, since we install the kernel from backports, and we only get upgrades from debian-security during provisioning, it is highly unlikely that debian-security would provide a newer version. OTOH I guess there will be a short window close to Debian releases where we do not install the backported kernel (because it doesn't exist) when this issue is quite likely to happen. Is my reasoning sound here?

Similarly, the "Installing Tails build dependencies" bits could be run before apt-get -y dist-upgrade, so we would never upgrade anything twice :)

I'd be a bit surprised if this affected us in anything more but some extreme edge cases. Any way, I think it makes sense!

This matters more now that we will be creating Vagrant boxes locally much more often than before.

Yup!

What do you think?

Let's do it!

I'm taking over this ticket since it's not jenkins-specific, or otherwise related to the deployment on the infra.

#2 Updated by intrigeri 4 months ago

While we're at it, we should consider pinning the exact kernel version installed during base box creation so the kernel is never upgraded during provisioning. Of course, since we install the kernel from backports, and we only get upgrades from debian-security during provisioning, it is highly unlikely that debian-security would provide a newer version. OTOH I guess there will be a short window close to Debian releases where we do not install the backported kernel (because it doesn't exist) when this issue is quite likely to happen. Is my reasoning sound here?

Sorry, I don't follow. If you feel it's worth it, please file a dedicated ticket about it (as this is orthogonal to this one if I got it right) and try to rephrase.

I'm taking over this ticket since it's not jenkins-specific, or otherwise related to the deployment on the infra.

Well, some design updates we did already moved tons of work from bertagaz' plate to Vagrant bits, so perhaps bertagaz wants to handle some of them?

#3 Updated by anonym 4 months ago

  • Assignee changed from anonym to bertagaz

intrigeri wrote:

While we're at it, we should consider pinning the exact kernel version installed during base box creation so the kernel is never upgraded during provisioning. Of course, since we install the kernel from backports, and we only get upgrades from debian-security during provisioning, it is highly unlikely that debian-security would provide a newer version. OTOH I guess there will be a short window close to Debian releases where we do not install the backported kernel (because it doesn't exist) when this issue is quite likely to happen. Is my reasoning sound here?

Sorry, I don't follow. If you feel it's worth it, please file a dedicated ticket about it (as this is orthogonal to this one if I got it right) and try to rephrase.

Filed as #12532. I'd appreciate your input/sanity checking!

I'm taking over this ticket since it's not jenkins-specific, or otherwise related to the deployment on the infra.

Well, some design updates we did already moved tons of work from bertagaz' plate to Vagrant bits, so perhaps bertagaz wants to handle some of them?

Ok, assigning back. I mostly took it since it felt like crap I've caused, so feel free to give it back to me if you don't want it. :)

#4 Updated by bertagaz 4 months ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 20
  • Feature Branch set to bugfix/12529-simplify-kernel-install-in-vagrant

anonym wrote:

Ok, assigning back. I mostly took it since it felt like crap I've caused, so feel free to give it back to me if you don't want it. :)

That's something we've discussed elsewhere but missed to implement. Just pushed a branch doing what this ticket description says.

#5 Updated by bertagaz 4 months ago

  • Assignee changed from bertagaz to anonym
  • % Done changed from 20 to 70
  • QA Check set to Ready for QA

bertagaz wrote:

Just pushed a branch doing what this ticket description says.

Seems to work well.

#6 Updated by anonym 4 months ago

  • Status changed from In Progress to Fix committed
  • Assignee deleted (anonym)
  • % Done changed from 70 to 100
  • QA Check changed from Ready for QA to Pass

Merged!

#7 Updated by intrigeri 3 months ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF