lavabit / robox

The tools needed to robotically create/configure/provision a large number of operating systems, for a variety of hypervisors, using packer.
626 stars 139 forks source link

alt architectures #177

Open mcandre opened 3 years ago

mcandre commented 3 years ago

Debian supports a variety of architectures, not just amd64. Could we get some boxes going for aarch64 (arm64), ppc64[el], and so on?

ladar commented 3 years ago

@timschumi took the lead, and added a Debian 9 x32 variant, but so far that's the extent of our multi-arch support. In theory it would be nice if that example got flushed out to a few a other operating systems for x32, but nobody has picked up the task yet.

As for more exotic architectures, I've wanted to add arm, and possibly other platforms for awhile now, but I don't have been able to get my hands on the hardware. I realize it might be possible to use emulation, but based on experience thought that would be incredibly slow, and in the end, I wouldn't be able to test the finished the product so the effort remains in stasis for now.

Naturally if someone else wants to step up, you can look at the Debian 9 x32 variant as a model for how to add alt arch configs to the pipefile/repo.

timschumi commented 3 years ago

@timschumi took the lead, and added a Debian 9 x32 variant, but so far that's the extent of our multi-arch support.

Although "multi-arch" is debatable in that case, isn't it? ;-)

At least I'm pretty sure that Vagrant doesn't even care that this isn't a true amd64 box.

In theory it would be nice if that example got flushed out to a few a other operating systems for x32, but nobody has picked up the task yet.

I wouldn't mind having a debian8-x32 box (which I already have some changes for, that I could clean up and push), and maybe an Ubuntu counterpart depending on how broken their multiarch support is. Although, that doesn't really diversify the collection of available examples, does it?

"Unfortunately", most distros do have decent multiarch support now, so there is rarely an actual need for a true x32 box.

As for more exotic architectures, I've wanted to add arm, and possibly other platforms for awhile now, but I don't have been able to get my hands on the hardware. I realize it might be possible to use emulation, but based on experience thought that would be incredibly slow, and in the end, I wouldn't be able to test the finished the product so the effort remains in stasis for now.

The only provider that I can see being reasonable (at least on arm/arm64) is libvirt (and maybe docker by extension). As far as I know, VirtualBox doesn't support anything outside of x86, and I'm not sure if there is anything available in Apple-land.

I do have an unused Raspberry Pi (3B+ if I remember correctly, my 4B is in use unfortunately), so I could do a few tests and check wether building natively (arm should have KVM support) or building on a more powerful PC using QEMU is more efficient (although a Raspberry Pi is in no way representative for the machines one would usually use).

ladar commented 3 years ago

@timschumi from my perspective, the x32 boxes provide the most value as a gateway into adding other more exotic platforms to the build pipeline. As they allowed us to work out some of the naming, organizational issues.

I don't think a Rasberry Pi will work as a build host. I've been trying to get my hands on a Ampere machine, or one of the other workstation/server class Arm systems, but they are far too expensive new, and rare enough that you won't find any bargains on used equipment on eBay/Craigslist.

I'm also personally rooting for the RISC V and PPC chips to gain traction, so we can move towards a world where the hardware is closer in openness to what we have with software.

But I don't know how practical emulation is in terms of performance (last time I tried was probably 10 years ago, and it was pitiful back then). But virtualization as come a long way since then. So it might work well, and if it does, then having alt arch boxes means developers can get the software working properly, so that when hardware does finally arrive on our desks, we, the users, aren't hunting bugs with a volt meter, and complaining to the world about system crashes. You may think I'm jesting, but that's only because you don't know the joys of JTAG.

So yes, I suuport multi-arch and would love to play with it. I just don't personally have the time to take the lead on adapting/testing all the box configurations.

mcandre commented 3 years ago

The Vagrant libvirt plugin allows for managing VM's with a guest architecture differing from the host.

For example, my Debian builds work this way.

https://github.com/mcandre/packer-templates/tree/master/debian

One caveat with the libvirt provider. qemu and libvirt are really only maintained for Linux hosts. I would not expect this stuff to work for users with Apple or Microsoft hardware. Any CI system that produces these images, should use a Linux host, such as a Linux EC2 instance. Just FYI.

Upstream, a better emphasis on qemu and libvirt support for Mac and Windows hosts will be critical, as ARM begins to take over the desktop world. I would expect libvirt could get to Mac and Windows before VirtualBox or VMware finally implement emulation.

timschumi commented 3 years ago

I have briefly looked at ARM builds in the past, and if I remember correctly the two options always ended up being "import a prebuilt system image/tarball" (which not many distributions support and I have no idea how to do programmatically in packer) or "get UEFI going and use an ISO" (which is meh at best for the end user and probably the build servers, because they have to install UEFI firmware).