app-admin/google-guest-configs: New package for udev rules and scripts

[chewi]

We already have GCE disk rules in coreos-init, but a user has pointed out that the newer NVMe rules are missing. Let's take the rules directly from upstream instead. This is loosely based on the ChromiumOS package of the same name.

When bumping, we must ensure that the Dracut modules do not install files that would make runtime changes to systems to other than GCE VMs because the initrd is shared between image types. The udev disk rules are currently safe.

This also adds Google's 60-gce-network-security.conf sysctl file. These settings are actually generic and not even networking-specific, but even if we're not going to apply them to Flatcar in general, we should apply them to Flatcar on GCE so that it behaves like other GCE VMs. I had to renumber our baselayout.conf file to take precedence though because Google's file disabled IP forwarding, which breaks Kubernetes.

The wider GCE packages are very outdated. I started looking into this in early 2025. I then noticed this had already been attempted the year before in #1826. This change at least implements a small part of what was in that PR without touching the rest.

This is being merged in tandem with flatcar/bootengine#125, flatcar/init#140, and flatcar/baselayout#43.

How to use

Spin up a VM with Kola using --gce-machinetype c3-standard-4 and check whether the "google" symlink exists under /dev/disk.

You can also take this further by adding an extra disk and trying to provision it by-id with Ignition. This is awkward to pull off though because Kola doesn't let you add an extra disk, so you need to stop it tearing down the VM, add a disk manually with gcloud, and then use flatcar-reset.

It's easy to check whether Google's sysctl settings have taken effect on GCE (and not elsewhere). One such setting is kernel.randomize_va_space = 2.

Testing done

This Jenkins run using GCE has passed. I've also done a lot of manual testing as above.

core@kola-1bbaa453890f254e976c ~ $ ls -l /dev/disk/by-id/google*            
lrwxrwxrwx. 1 root root 13 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd -> ../../nvme0n1
lrwxrwxrwx. 1 root root 15 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd-part1 -> ../../nvme0n1p1
lrwxrwxrwx. 1 root root 15 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd-part2 -> ../../nvme0n1p2
lrwxrwxrwx. 1 root root 15 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd-part3 -> ../../nvme0n1p3
lrwxrwxrwx. 1 root root 15 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd-part4 -> ../../nvme0n1p4
lrwxrwxrwx. 1 root root 15 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd-part6 -> ../../nvme0n1p6
lrwxrwxrwx. 1 root root 15 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd-part7 -> ../../nvme0n1p7
lrwxrwxrwx. 1 root root 15 Dec 29 22:26 /dev/disk/by-id/google-nvme_card-pd-part9 -> ../../nvme0n1p9

• 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.

[krnowak]

This seems to be missing your baselayout PR (flatcar/baselayout#43) or is the PR going to be pulled as a separate scripts PR?

[krnowak]

I see you are changing the versioning of the package. This makes sense, since the package now is not tied only with app-emulation/google-compute-engine, but I'm not sure if using a current date is a way to go - would making it 1.0 make more sense?

[chewi]

I can't remember why I picked 20260102. It was probably the version of google-guest-configs at the time, and I must have decided to use the later of the two. I still think that makes sense. Better than having a downgrade to some meaningless 1.0.

[chewi]

I've now bumped that and added a note to the ebuild.

[chewi]

This seems to be missing your baselayout PR...

As discussed, this was still in draft.