> Are you saying that your boot partition has cloud-init metadata at its root? That's...unexpected.
Precisely -- we've used cloud-init this way since eoan (19.10 I think?), if memory serves. [ Use case ] The reasoning back then was simply that most people flash their SD cards for the Pi on machines other than Linux (Windows most likely or possibly Mac). Originally, the seed was just being read from the ext4 partition but that couldn't be mounted by anything but Linux. However, we already had a FAT formatted partition (the system-boot partition) which could be accessed by other OS', so I stuck the cloud-init seed there, pointed the config at it, and everything's worked nicely ever since. This also mirrored RaspiOS (or Raspbian as it was back then) which allowed some first-time boot customization by placing various files on the boot partition (I'm sure the reasoning was similar there: to make such customization possible from non-Linux machines). Fast forward a year or two, and the rpi-imager application comes along to simplify flashing SD cards. This supports customizing a freshly written image by writing various things, including a cloud-init configuration, to the (FAT) boot partition. You can have a look at the current boot partition for the server images here (this is incomplete; the image build process adds the kernel, dtbs, initrds, etc. but you can see the cloud-init config alongside the boot configuration here): https://github.com/canonical/pi-gadget/tree/classic/configs/plucky- arm64-server [ Change to cidata ] I *could* make an entirely separate cidata FAT partition ... but that'll break the rpi-imager case (which only looks at the first FAT partition). I can't place the cidata partition first, because that would break the boot ... unless I can also place a file in cidata pointing the Pi's boot loader at the separate partition. Also, I'm not sure how Windows (or macOS) handles multiple FAT partitions on an SD card (does it mount all of them, or just the first?). Bearing in mind that Pi users commonly want to customize the config.txt (boot configuration) too, in order to manually specify hardware overlays or other things. Keeping all the files users frequently want to customize in one easy-to-access place is generally "better" in my view. Or I could rename the boot partition to cidata. But that carries its own pain points with migrating old installs during dist-upgrade (not *too* hard admittedly -- probably just tweaking fstab, but there's probably a bunch of corner cases just waiting to bite me :). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2100232 Title: 99-fake-cloud.cfg uses a deprecated key fs_label for cloud-int >24.3 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2100232/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
