[Bug 2100232] Re: 99-fake-cloud.cfg uses a deprecated key fs_label for cloud-int >24.3

[Dave Jones]

> 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
Foundations Bugs, which is subscribed to ubuntu-raspi-settings in
Ubuntu.
https://bugs.launchpad.net/bugs/2100232

Title:
  99-fake-cloud.cfg uses a deprecated key fs_label for cloud-int >24.3

Status in cloud-init package in Ubuntu:
  Incomplete
Status in ubuntu-raspi-settings package in Ubuntu:
  Confirmed

Bug description:
  When cloud-init reads 99-fake-cloud.cfg, it reports:

  2024-10-07 17:14:13,272 - lifecycle.py[DEPRECATED]: Custom fs_label
  keys is deprecated in 24.3 and scheduled to be removed in 29.3. This
  key isn't supported by ds-identify.

  ubuntu-raspi-settings version 24.10.1
  Ubuntu 24.10

  This logs a deprecation warning in the cloud-init-output logs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2100232/+subscriptions