Sender | Message | Time |
---|---|---|
11 Apr 2024 | ||
tormath1 | that should work too. Do you run butane via the Docker image? | 13:05:30 |
Timo Kramer | no, locally installed... I am running it with python subprocess and maybe I should not pipe it there but specify the file input and then it should acknowledge --files-dir hopefully... will try it out right away | 13:21:09 |
Julian Tölle | I hit https://github.com/flatcar/Flatcar/issues/1389 when I first trying to boot my custom images for the first time, took a few hours to find the issue, but a "quick" I now have a working Hetzner (Cloud) OEM image, without any custom OEM ignition configs 🥳 PRs incoming | 16:30:51 |
Timo Kramer | In reply to @mopedtobias4242:matrix.orgworks fine now with not piping but specifying the file when running butane. Thanks! | 16:43:18 |
Julian Tölle | PRs:
| 17:33:48 |
12 Apr 2024 | ||
tormath1 | Thanks! I prepared the CI to build Hetzner images for testing your PRs. I think only this needs to be addressed at the moment: https://github.com/flatcar/scripts/pull/1880#discussion_r1561364650 | 11:04:41 |
Julian Tölle | Addressed all open comments in the PR :) | 19:49:33 |
15 Apr 2024 | ||
tormath1 | Thanks a lot, a CI build has been started. I let you know how it goes! | 08:02:10 |
Julian Tölle | Perfect, are you building for amd64 and arm64 or only amd? I spent the weekend moving my personal cluster Flatcar, using images built from the branch. Also tried my luck at | 08:05:41 |
tormath1 | Images should be built for both arch (i.e amd64 and arm64). What's the process for importing images on Hetzner? You can only deploy a live instance then create a snapshot from it? This is what the Packer example you did suggest. For example with Scaleway we import images in a bucket then we create the snapshot from the bucket content. | 08:11:23 |
Julian Tölle | Yup, doing what packer is doing is the only way right now (through the public API)
| 08:12:36 |
Julian Tölle | FWIW I added an upvote to our internal feedback tracker for "Uploading Images" | 08:15:43 |
tormath1 | Mm... If you need to create a Flatcar instance to create a Flatcar snapshot it means that it won't be the first boot of the instance when deploying the snapshot... | 08:45:02 |
Julian Tölle | We boot the rescue system (debian) and use Flatcar was never booted when the snapshot is taken, ignition never ran. | 08:47:15 |
tormath1 | Ah yes, exactly! Then it's OK in this regard. It's just an extra step... | 08:48:33 |
Julian Tölle | Or 9 extra steps :(
| 08:50:15 |
Jendrik Weise | hey, i ve been using the podman sysext for a while, but it s been rather more of a pain whenever i had to update it(or the underlying flatcar for that matter). i know that official podman support is on the roadmap, but i m wondering whether there is any way for me to adopt either the sysext-bakery or https://github.com/flatcar/scripts/blob/main/build_sysext this script to generate an up-to-date sysext image? has ther been any work to that end/is there any documentation for these? | 08:50:38 |
tormath1 | Yeah, and it's not really convenient to perform this kind of provisioning steps from Terraform for example. | 08:52:29 |
Julian Tölle | Packer is really nice for this, but I did not want to pull it in as a dependency of mantle | 08:53:15 |
tormath1 | In reply to @jewe37:malined.comHello, I agree it's a pain to maintain the Podman "non-official" extension. A good approach would be to build official sysext images (from the Flatcar CI). Similar as ZFS or Incus (https://github.com/flatcar/scripts/pull/1742, https://github.com/flatcar/scripts/pull/1655). | 08:55:32 |
tormath1 | Is PXE booting could be a solution? | 08:58:28 |
tormath1 | * Does PXE booting could be a solution? | 08:58:48 |
Jendrik Weise | i see, those examples should help me along somewhat. may i ask, what s the role of the sysext bakery in this context? i take it it is designed for generating comparatively more simple, non-official, user provided images? | 09:07:08 |
kailueke | The extensions from the sysext-bakery repo are not bound to the OS version. In the Podman example this would be possible with crun and Podman being compiled in a way that doesn't link to the base OS (or as compromise, only links against few common libraries and their oldest ABIs). Normally the published release binaries are ok in that regard. With a Podman Flatcar extensions we could use the Gentoo packages and dynamic linking. | 09:39:37 |
tormath1 | Test images are built and available here: http://bincache.flatcar-linux.net/images/amd64/9999.0.0+hetzner/flatcar_production_hetzner_image.bin.bz2 First "official" Flatcar images for Hetzner 🥳 (just need to change | 11:48:12 |
tormath1 | I'm wondering if the hc-utils you mentioned https://github.com/hetznercloud/hc-utils could not be shipped inside the oem-hetzner sysext image and we could even add the fetching of the root password here | 15:45:38 |
Julian Tölle | That would be the next step, yea. I personally do not need any of this functionality (volume automount & automatic network interface configuration from hc-utils, root password). So it was not a priority to me so far. Wanted to take another look after the initial work is done/merged | 16:09:36 |
Julian Tölle |
I dont know anything about PXE really, where would that fit into this? | 16:10:14 |
tormath1 | I checked the Hetzner documentation and there is no mention of PXE neither. So I think for now we can stick to the Packer approach, as long as it is documented that's alright in a first step. :) | 16:17:05 |
Julian Tölle | The built images work great, running the I updated my test docs to use these images instead of building locally: https://github.com/apricote/flatcar-packer-hcloud/tree/oem-image-prebuilt | 19:00:53 |