coreos-cloudinit: fix Equinix Metal cloudinit

[tormath1]

This has been raised on Slack:

Aug 08 19:03:33 shoot-79548-jlptk bash[1678]: 2024/08/08 19:03:33 Checking availability of "packet-metadata-service"
Aug 08 19:04:03 shoot-79548-jlptk bash[1678]: 2024/08/08 19:04:03 Checking availability of "packet-metadata-service"
Aug 08 19:04:33 shoot-79548-jlptk bash[1678]: 2024/08/08 19:04:33 Checking availability of "packet-metadata-service"
Aug 08 19:05:03 shoot-79548-jlptk bash[1678]: 2024/08/08 19:05:03 Checking availability of "packet-metadata-service"
Aug 08 19:05:33 shoot-79548-jlptk bash[1678]: 2024/08/08 19:05:33 Checking availability of "packet-metadata-service"
Aug 08 19:06:03 shoot-79548-jlptk bash[1678]: 2024/08/08 19:06:03 Checking availability of "packet-metadata-service"
Aug 08 19:06:09 shoot-79548-jlptk bash[1678]: 2024/08/08 19:06:09 No datasources available in time
Aug 08 19:06:09 shoot-79548-jlptk systemd[1]: oem-cloudinit.service: Main process exited, code=exited, status=1/FAILURE
Aug 08 19:06:09 shoot-79548-jlptk systemd[1]: oem-cloudinit.service: Failed with result 'exit-code'.
Aug 08 19:06:09 shoot-79548-jlptk systemd[1]: Failed to start oem-cloudinit.service - Run cloudinit.

The check for metadata endpoint availability (curl https://metadata.packet.net/) returns a 404 so it fails.

---

This PR is testing: flatcar/coreos-cloudinit#28 - once the PR merged, we can just update the commit revision and drop the user patch.

Once built, the image will be available at: https://bincache.flatcar-linux.net/images/amd64/9999.9.0+tormath1-cloudinit/flatcar_production_packet_image.bin.bz2 for testing.

Testing done

• Locally built coreos-cloudinit to try getting metadata.
• CI: http://jenkins.infra.kinvolk.io:8080/job/container/job/packages_all_arches/4470/cldsv/
• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[RiRa12621]

AFAIK the only way to test a custom image in Equinix is to use a custom image with ipxe booting, but for that we'd require vmlinux and initrd in separate bits.

[tormath1]

AFAIK the only way to test a custom image in Equinix is to use a custom image with ipxe booting, but for that we'd require vmlinux and initrd in separate bits.

@RiRa12621 These should be available here:

• https://bincache.flatcar-linux.net/images/amd64/9999.9.0+tormath1-cloudinit/flatcar_production_image.vmlinuz
• https://bincache.flatcar-linux.net/images/amd64/9999.9.0+tormath1-cloudinit/flatcar_production_pxe_image.cpio.gz

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/10486792450

[jepio]

Running CI here: http://jenkins.infra.kinvolk.io:8080/job/container/job/packages_all_arches/4518/cldsv/

[chewi]

This is failing, but I think that's because of flatcar/Flatcar#1514?

[jepio]

The github CI is failing on a test that shouldn't be running in the github CI (confused)
The EM CI is extremely unreliable, someone really needs to take a look.

[chewi]

The github CI is failing on a test that shouldn't be running in the github CI (confused) The EM CI is extremely unreliable, someone really needs to take a look.

Which test in particular?

[jepio]

I can't find the failing GHA run anymore, but it looked like [first_dual].cl.update.oem was failing because of not being able to fetch the oem sysext from bincache, which is checked as a precondition before adding the test case here:
https://github.com/flatcar/scripts/blob/main/ci-automation/vendor-testing/qemu_update.sh#L100-L108

[jepio]

Pushed a changelog entry, GHA had passed before, and the EM testing looks about as good as before this change.
Will cherry-pick to all channels.