Revert "debian11-x32: Force enable IO-APIC" #286
Conversation
This has since been fixed in the upstream VirtualBox plugin. This reverts commit 87e3457.
|
Note: Marking as WIP since |
|
I'm in the midst of a major overhaul of the configs/pipeline, so I can add support for arches. Namely, adding a64 alongside the x64/x32 configs we already build. I'm also updatiung the upload scripts so they use the v2 Vagrant Cloud API, which supports setting an arch type when a box file is uploaded. As for this commit, it will be easy enough to make the change by hand. But if it requires the new Packer VirtualBox plugin, that could be an issue. The build robots currently use Packer 1.8.x, to avoid the big shift to plugins. Initially the Packer releases were causing lots of breakage, so left the robots on the older release. That said, I think I've figured out most of the initial issues, along with what plugins are needed. So it might be time to give Packer 1.9.x version another try, perhaps during the next release cycle. |
I'm not sure if the plugin itself is new, some form of it has been around since 2021 apparently. But yeah, it requires the (currently) newest tagged version, one that is new enough to not be contained in bleeding-edge In any case, this essentially just moves overriding the IOAPIC setting from the robox config to being implied by the plugin. There is no practical difference for the result (or our builders), so this might as well stay open as long as there are more important things to take care of. |
Your correct the "plugin per=se isn't new. What got fubarred was the setup/config process. I use the But at this point, I think I can make it work, or at least I can install the required dependencies, and validate the Robox JSON templates. But I since it doesn't have any new features we need, at least any II know of, I'll wait till things are quiet before trying to use to build 1000+ virtual machines. On a related note, a long term topic is whether it makes sense to convert the JSON templates to the HCP YAML syntax. I had to use the automated conversion to find the required dependencies. But didn't keep them, since there is a lot of tooling in place to automate things, and it would need to be rewritten if we switched. I haven't researched the issue all that much, to know what the pros/cons are.
The above was just a needless ramble. What I wanted to say is that if the distro requires the flag to run on VBox we should leave it. Some of the config settings get bundled into the box, (lost track of what, with what providers). With any luck, it ends up part of the template when a box gets provisioned, and saves users the pain of troubleshooting a VM which doesn't boot. The RHEL 9+ distros (and the forks) have an issues, where the kernel uses CPU instructions that don't always get exposed to the guest. And RHEL didn't implement the update properly. It would have been easy enough to test for the CPU features, and print useful. explanation if they're missing. But they didn't. Instead what you get is a cryptic kernel panic, and error messages whicha are unrelated to the underlying problem. It' was a massive headache. @timschumi any interest in adding a 3-4 more x32 configs to the pipeline? With Vagrant Cloud's new arch support it makes more sense to add more. I was hoping you'd be willing to add x32 configs for Devuan 5, Alpine 3.18, and FreeBSD 13 (or 14.). In the bonus category, OpenBSD and another Linux distro (not sure what the x32 support is like on Arch or Gentoo). I'm hoping to focus on the arm versions, or I add them myself. Either way, there is a good merge window the next ~2 weeks to add x32 and/or new x64 configs. Or any other major changes, since I'm touching just about everything as I work towards adding support ARM (and perhaps other arches, if I can get the hardware). |
It's even more fun - it will randomly crash. I don't think the IOAPIC setting here gets propagated into the box, but I will double-check that once I have the time. If I remember correctly, Vagrant didn't require this workaround for one reason or another, it was just packer that needed that particular setting to be added into its VM setup routines (which we previously/right now worked around by specifying those settings manually).
I personally don't have any use for it, even the ones that I added some time ago I have significantly scaled down my use of (since I had to switch to Valve's Steam Runtime Docker images on most of my projects for compatibility purposes). The selection of distributions looks reasonable, the biggest "problem" would be Arch Linux, which has since abandoned i686 support (but has been picked up as a separate project that almost exactly mirrors the original). I'll see if I can get to it sometime soon. |
This has since been fixed in the upstream VirtualBox plugin.
This reverts commit 87e3457.