Tails

#1 Updated by anonym 2017-05-10 14:38:39

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

#3 Updated by anonym 2017-05-10 15:47:51

• 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 Feature #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 2017-05-15 13:31:20

• 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 2017-05-16 10:54:17

• 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 2017-05-30 08:31:05

• 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 2017-06-12 16:07:40

• Status changed from Fix committed to Resolved