Keep linux-kernel-header package installed for Parallels builds #1526
Conversation
mpdude
force-pushed
the
keep-parallels-linux-kernel-headers
branch
from
ec149fb
to
2eb984e
Compare
When using [this Ubuntu Vagrant box](https://app.vagrantup.com/bento/boxes/ubuntu-22.04/versions/202303.13.0) with Parallels Desktop, the `vagrant-parallels` plugin upon boot detects that the version of Parallels Tools installed in the box is outdated and tries to update it. The problem is that a due re-compilation of Parallels Tools depends on `linux-headers-5.15.0-67-generic`, with the package name/version matching the version of the currently running kernel. However, the Kernel version included in the box image has since then replaced with a newer version (in the upstream Ubuntu repositories), and it seems the matching header files can no longer be installed. They probably came from an Ubuntu security update release channel where the package has been replaced with a newer version since the box was built. Full details can be found in the issue at Parallels/vagrant-parallels#458. By keeping the `linux-headers-*` package during/after installation, also a freshly booted box should be able to perform the update. The package is, in fact, installed automatically when Parallels Tools are added, but after that is is removed by the `cleanup_ubuntu.sh` script. Signed-off-by: Matthias Pigulla <[email protected]>
mpdude
force-pushed
the
keep-parallels-linux-kernel-headers
branch
from
2eb984e
to
b9cf689
Compare
|
Will a merge also lead to a new box being built and published? |
|
Yes I'll make sure to do an adhoc build for parallels. |
|
Did this PR break the GHA workflows? |
|
No they are running. With the switch to hcl2 there is still more tweaking and testing of various builds that need to happen. Most probably need a variable for the boot_wait per provider and tweaks to the os_pkrvariables for each OS to get them to work. |
|
You need #1527 first to fix outdated Ubuntu 22.04 ISO URLs |
|
Kudos, SonarCloud Quality Gate passed!
|
* 'main' of github.com:chef/bento: Keep linux-kernel-header package installed for Parallels builds (chef#1526) Update Ubuntu 22.04 `iso_url` (chef#1527) Do not defrag and zerofill the disk twice during Windows cleanup and optimize (chef#1525) Update vmware vars for el9 derivitives (chef#1519) Update Debian from 12.0 to 12.1 (https://www.debian.org/News/2023/20230722) (chef#1517) provision.ps1: fixed virtio-win-guest-tools.exe installation (chef#1516)
|
😱 Did this really necessitate to run more than 100 VM image builds, spending more than 17h in CI? The ecological footprint 🌱 is devastating 🤔 |
|
eventually I want to add logic to only build the pkvars files that have changed. in the changelog there is a list of things to do with this repo. I'm the only one working on it on the side. Right now all the builds happen on 3 mac mini's running in my basement hosting the build runners. |
|
😩 sorry if that sounded like criticism, that was not my intention. I know almost nothing about packer and the stuff you’re doing here… not sure, you think I can help? Would it be possible to re-organize files in a way that make it clear which VM images depend on changes in which directories? |
|
You can limit GHA workflows to run only when files in a directory changed. So, when there were directories for files that affect all VMs of a certain distro, or all of a certain hypervisor etc, maybe that mechanism could be used? |
|
It's all good. That approach would still build a lot of boxes. I've done something similar here to only run json-lint job if a json file has been added or modified. Simply need to get the list of files as output from the previous job and use it as input to the build matrix. https://github.com/Stromweld/github-workflows/blob/main/.github/workflows/json-lint.yml may need to run custom script to parse them out based on cpu architecture. |
|
I can confirm the initial issue seems to be fixed in https://app.vagrantup.com/bento/boxes/ubuntu-22.04/versions/202309.08.0 – at least, no Parallels Tools update problem at boot (no surprise, it's all fresh and shiny and new) and the box comes with the header files installed. |
|
Thanks, real test will be the next update for parallels. These new machines were built with the latest parallels 19.0.0 version so there shouldn't be a tools upgrade. |
|
Should the v19 tools also work with previous versions of Parallels? |
|
from my understanding yes. I haven't tested and verified though. |
|
@mpdude will the ubuntu-22.04-arm64 box updated too to fix the issue? |
|
@shir Generally yes, but I don't know if that image has been successfully rebuilt and published at all |
|
@mpdude the latest released version for arm64 is v202306.30.0 and it doesn't have this fix. https://app.vagrantup.com/bento/boxes/ubuntu-22.04-arm64 |
|
@Stromweld Could you please build/publish a new version of the ubuntu-22.04-arm64 box for parallels provider with this fix? Thank you! |
|
yes I'll work on that now. |
|
this should be up there now |
|
Great, thanks again! |
When using this Ubuntu Vagrant box with Parallels Desktop, the
vagrant-parallelsplugin upon boot detects that the version of Parallels Tools installed in the box is outdated and tries to update it.The problem is that a due re-compilation of Parallels Tools depends on
linux-headers-5.15.0-67-generic, with the package name/version matching the version of the currently running kernel.However, the Kernel version included in the box image has since then replaced with a newer version (in the upstream Ubuntu repositories), and it seems the matching header files can no longer be installed. They probably came from an Ubuntu security update release channel where the package has been replaced with a newer version since the box was built.
Full details can be found in the issue at Parallels/vagrant-parallels#458.
By keeping the
linux-headers-*package during/after installation, also a freshly booted box should be able to perform the update. The package is, in fact, installed automatically when Parallels Tools are added, but after that is is removed by thecleanup_ubuntu.shscript.