!SakMJmpDOgVMlGukUp:matrix.org

Flatcar

77 Members
https://github.com/flatcar/flatcar - Linux for containers. Meetings every second and fourth Wednesday of the month at 2:30pm UTC. Agendas here: https://github.com/flatcar/Flatcar/discussions?discussions_q=is%3Aopen+category%3A%22Flatcar+Office+Hours%22+category%3A%22Flatcar+Developer+Sync%2210 Servers

Load older messages


SenderMessageTime
11 Apr 2024
@tormath1:matrix.orgtormath1 that should work too. Do you run butane via the Docker image? 13:05:30
@mopedtobias4242:matrix.orgTimo Kramerno, 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 away13:21:09
@apricote:matrix.orgJulian 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" emerge-amd64-usr coreos-modules && emerge-amd64-usr coreos-kernel fixed it.

I now have a working Hetzner (Cloud) OEM image, without any custom OEM ignition configs 🥳 PRs incoming

16:30:51
@mopedtobias4242:matrix.orgTimo Kramer
In reply to @mopedtobias4242:matrix.org
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
works fine now with not piping but specifying the file when running butane. Thanks!
16:43:18
@apricote:matrix.orgJulian Tölle

PRs:

  • https://github.com/flatcar/bootengine/pull/94
  • https://github.com/flatcar/init/pull/118
  • https://github.com/flatcar/scripts/pull/1880
17:33:48
12 Apr 2024
@tormath1:matrix.orgtormath1Thanks! 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_r156136465011:04:41
@apricote:matrix.orgJulian TölleAddressed all open comments in the PR :)19:49:33
15 Apr 2024
@tormath1:matrix.orgtormath1Thanks a lot, a CI build has been started. I let you know how it goes! 08:02:10
@apricote:matrix.orgJulian 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 ore/mantle, but its a PITA that you can not upload images directly.

08:05:41
@tormath1:matrix.orgtormath1Images 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
@apricote:matrix.orgJulian Tölle

Yup, doing what packer is doing is the only way right now (through the public API)

  • https://docs.hetzner.cloud/#server-actions-create-image-from-a-server
08:12:36
@apricote:matrix.orgJulian TölleFWIW I added an upvote to our internal feedback tracker for "Uploading Images"08:15:43
@tormath1:matrix.orgtormath1Mm... 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
@apricote:matrix.orgJulian Tölle

We boot the rescue system (debian) and use install-flatcar to overwrite the full disk of the server. Then we shut it down and take the snapshot.

Flatcar was never booted when the snapshot is taken, ignition never ran.

08:47:15
@tormath1:matrix.orgtormath1Ah yes, exactly! Then it's OK in this regard. It's just an extra step... 08:48:33
@apricote:matrix.orgJulian Tölle

Or 9 extra steps :(

  • Generate temp ssh key, upload to API
  • Create Server
  • Enable Rescue
  • Boot
  • scp Image to server
  • ssh + install-flatcar
  • Shutdown server
  • Take snapshot
  • Delete server & ssh key
08:50:15
@jewe37:malined.comJendrik Weisehey, 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:matrix.orgtormath1Yeah, and it's not really convenient to perform this kind of provisioning steps from Terraform for example. 08:52:29
@apricote:matrix.orgJulian 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:matrix.orgtormath1
In reply to @jewe37:malined.com
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?
Hello, 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:matrix.orgtormath1Is PXE booting could be a solution? 08:58:28
@tormath1:matrix.orgtormath1 * Does PXE booting could be a solution? 08:58:48
@jewe37:malined.comJendrik Weisei 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
@pothos:matrix.orgkailuekeThe 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:matrix.orgtormath1

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 amd64 to arm64 in the URL to get the arm64 version)

11:48:12
@tormath1:matrix.orgtormath1 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
@apricote:matrix.orgJulian TölleThat 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/merged16:09:36
@apricote:matrix.orgJulian Tölle

Does PXE booting could be a solution?

I dont know anything about PXE really, where would that fit into this?

16:10:14
@tormath1:matrix.orgtormath1I 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
@apricote:matrix.orgJulian Tölle

The built images work great, running the arm64 one in my infra as we speak. So much faster to download from your object storage than upload from my local desktop pc :D

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

Show newer messages


Back to Room ListRoom Version: 6