In the Fedora CoreOS Documentation, under the “Provisioning Machines” section, there is an extensive list of providers, each with instructions on how to boot a CoreOS image. The usual suspects are present there, from the big 3 AWS/GCP/Azure, then DO, Vultr and so on.
Intriguingly, Linode is not on the list. (yes, in many cases, CoreOS ends up installed as a custom image; but Linode can also install custom images, so it is a bit puzzling that custom image steps are provided for DO or Vultr and a few others but not for Linode).
Searching at the other end, in Linode’s docs and guides, there is a bit of a confusion.
There is no CoreOS in Linode’s list of supported distributions. OK, anyway probably the custom image install is the way to go.
But it seems that Linode had at some point the capability to directly install CoreOS : there is a guide for that, “Install CoreOS on Your Linode”. Or more precisely, it kind of was: the guide is marked as “deprecated”. Under that message however there is a note saying that “CoreOS Container Linux is now available for deployment from the Linode Manager.” So, it is available after all ?
The lack of a clear support message (especially in CoreOS docs) left me wondering. Is there some unmentioned pitfall that makes Linode a poor match for a CoreOS install ?
That guide refers to CoreOS Container Linux, not Fedora CoreOS. CoreOS Container Linux is no longer maintained, and Fedora CoreOS has never been available on Linode.
Yes. Fedora CoreOS uses one of two flows for launching in a cloud provider:
Official Fedora CoreOS images are published to the cloud provider. Users launch an image and provide an Ignition config via the provider’s userdata mechanism. The Ignition config specifies the customizations that should be made to the VM instance, such as config files and SSH keys.
Images are not published to the cloud provider, but Fedora CoreOS provides official images and instructions for uploading them. Users download the image from Fedora and upload it to the provider, and afterward the flow is the same as in the previous case: users can launch the image multiple times, each time providing an Ignition config to customize the VM instance.
Both flows require the cloud provider to provide a mechanism for passing arbitrary configuration data (“userdata”) to the VM. Linode doesn’t have one. Their provisioning system (including their StackScripts mechanism) injects configuration such as SSH keys by directly modifying the VM disk. This is unlikely to work due to specifics of the Fedora CoreOS disk layout, and in any event, that user experience isn’t consistent with Fedora CoreOS on other platforms.
There’s another approach: using the install flow for bare-metal machines with Linode’s direct disk boot support. This involves booting the Fedora CoreOS live ISO and running coreos-installer, passing it a URL to an Ignition config. This is an awkward flow for provisioning cloud VMs (since you’d need to perform an installation for every new VM) but might work. If you decide to try this, please let us know how it went. However, I’d encourage you to use a cloud provider with first-class userdata support instead.
Thank you, that was very good information. You put me on the right track.
As a quick summary, I was able to install Fedora Coreos on a Linode. The installation works reasonably well using the manual steps.
Trying to completely automate all that was a significant effort however, wrestling with the “Linode way” of doing custom installs. So it came as a bit of a surprise that in the end I could craft a fully automated procedure (i.e. a shell script that can take me from a butane file to a fresh new Linode instance with Coreos running on it). Despite this, indeed the overall feel is not very smooth and you are right that another provider probably would be a much better fit for Coreos.
Without going too deep on the nitty-gritty, here are some details:
The foundation is, yes, a coreos iso, from the “Bare Metal” section on the download page (or get it with coreos-installer download -s stable -p metal -f iso -C ...).
I did not go with your suggestion of passing it the Ignition through a URL: that would need yet another server somewhere, more or less under my control and the whole situation would get a strong chicken-and-egg flavor. I wanted an install procedure as self-contained as possible.
Instead, I’m embedding into the .iso a few ignition files using coreos-installer iso customize : the destination for the final system, with --dest-ignition, and a couple of live ignitions for the live installer itself, following this as a guide: Example manual customization via installer.d. One of the coreos-installer iso customize arguments is also a --dest-device /dev/sdX to trigger an automated install; that sdX will have to match the disk for the final system created for the Linode instance. (or use the equivalent dest-device: setting in the installer.d yaml, but not both, even if they have the same value)
Once I have this modified .iso with the embedded ignitions, it will be a matter of uploading it at the right time during the Linode custom image install procedure and in the right place.
More precisely, I use this custom iso in the step 2 of the Download and Install Image section in the Linode custom image guide (upload it through ssh and pipe it to dd, so careful with the fingers!).
The rest of the steps in the guide, before and after, should work the same.
As it can be seen from the guide, the manual procedure is quite involved. Some details in the guide were tiny bit off, but in the end it worked OK.
One of the automated steps used for scripting has some dark corners and I think it became quite a hack, but it seems to do the job.
Yes, for every new install and even for any change in the ignition you’ll have to create/update the custom iso and (re-)upload it into the installer disk (basically an install from scratch).
The first operation is very fast. The latter potentially takes longer but for me it was no more than 30s and a couple of times as little as 15s. These numbers are low though compared to other steps. First, it takes some time to download the final Coreos image during the coreos-installer install ... phase. Then the reboot durations have a wide spread, sometimes as little as 15s, but occasionally the Linode instance takes forever to boot, more than 2 minutes (and if you count the needed reboots in the guide, there are three of them)
I was wondering if it’s worth adding some of this information in an entry along the list of all the providers in the Coreos “Provisioning Machines” section of the docs (of course after rearranging it to match as much as possible the form and style there). On one hand, indeed, the “flow” is off. Does not match the rest. On the other, it could help, if someone really needs to do it; if nothing else, it can serve as a warning that, while possible, the experience is not as smooth as expected.