Page MenuHomePhabricator

Upgrade linux kernel used on Vagrant to 4+
Closed, ResolvedPublic


While our Debian version now matches production, kernel version does not:

vagrant@mediawiki-vagrant:~$ uname -r

gilles@thumbor1001:~$ uname -r

We should at least aim for the same major version, if possible.

Event Timeline

Noting these are seemingly fairly major WMF backports...

ii  linux-image-4.4.0-2-amd64            4.4.2-3+wmf6                      amd64        Linux 4.4 for 64-bit PCs
ii  linux-image-4.4.0-3-amd64            4.4.2-3+wmf8                      amd64        Linux 4.4 for 64-bit PCs

vs (not from a vagrant box)

ii  linux-image-3.16.0-4-amd64     3.16.39-1+deb8u2                   amd64        Linux 3.16 for 64-bit PCs

There isn't a 4.* kernel in debian stable. testing has 4.9...

Do we want vagrant using the WMF build kernels?

All that seems to be needed is to install the following:

linux-headers-4.4.0-2-amd64 linux-image-4.4.0-2-amd64

And reload the VM. Even if I was doing that only for the Thumbor role, I don't know how I would schedule a graceful reload in the middle of the role getting provisioned.

The most elegant thing to do would be to do that in the initial provisioning of the VM, though, IMHO. Same problem there, I'm not sure if anything at the moment schedules a VM reload as part of that initial provisioning?

Yeah I don't have a particular opinion about using backports versus generic ones, I mostly care about running at least 4.*

We don't have anything that triggers a reload from Puppet today (although we did at one time), but we do trigger reloads via role enable/disable when ports change. It should be possible to add some custom provisioning step that checks the kernel version, does an update if needed, and triggers a reload of the VM. This may be fragile however.

I thought about the port things, but that happens before puppet is applied, right? In this case it would be preferable to reboot as the very last action of provisioning. Do you know a way I could schedule a command to run last, or even better, after provisioning is done? Because rebooting at the point of the provisioning where the kernel is installed doesn't feel like it would work.

Changing the order would just be a matter of moving the config.vm.provision :mediawiki_reload if mwv.reload? line in Vagrantfile to come after the config.vm.provision :puppet do |puppet| or adding another provisioning check at that later point. The reload block was moved in rMWVA32771508726f: plugin: New role settings system when the implementation switched from the old Puppet managed trigger file to the settings integration. It would be trivial to restore this to the end and make the guard be the env flag or a Puppet managed trigger file.

I've tried simply touching /vagrant/tmp/RELOAD from the role, and adding config.vm.provision :mediawiki_reload if mwv.reload? at the end of the Vagrant.configure('2') block, but it doesn't pick it up until the next vagrant provision (when it actually hits the existing mwv.reload check at the top).

It seems like the whole block in the Vagrantfile is executed/parsed at the beginning of the provision call, which doesn't leave room for changing things during the puppet run?

Change 345584 had a related patch set uploaded (by Gilles):
[mediawiki/vagrant@master] [WIP] Make Thumbor role upgrade linux kernel

I've uploaded the patch so you can see exactly what I'm talking about. It's the version I mention in my last comment.

"Fixed" on Stretch based VMs.

$ vagrant ssh -- uname -a
Linux vagrantdisposable 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64 GNU/Linux
bd808 claimed this task.

Change 345584 abandoned by Gilles:
[WIP] Make Thumbor role upgrade linux kernel