[enhancement]: Allow `NoCloud` to specify alternative `cidata` fs label.

[mjsir911]

Enhancement

This is kind of a regression since I've been depending on behaviour that was recently removed.

Basically I want the behaviour of fs_label back. When configuring custom raspberry pi images to be bootable with cloud-init, it's useful to just drop the cloud config files into /boot/ (with vfat label boot) as opposed to having to provision a whole new partition solely for cloud-init.

Related: 7a686bfac9f17745c40831b01f54438a4d78f161 (#5515) #386 #3694 #5062

[holmanb]

This is kind of a regression since I've been depending on behaviour that was recently removed.

Basically I want the behaviour of fs_label back.

It is still there. This "feature" was not removed. Feel free to keep using it for now if you wish.

It is just deprecated because there are several other ways to accomplish the same thing, so the existence of the code to support this adds maintenance costs (test, refactor, new features must take it into account, etc) without a clear end-user benefit.

it's useful to just drop the cloud config files into /boot/ (with vfat label boot) as opposed to having to provision a whole new partition solely for cloud-init

Provisioning a new partition for cloud-init isn't required - in fact the old partition wasn't required either. You're already modifying fs_label in the base configuration - you could just include the user-data in the base configuration directly:

just drop:

fs_label: boot

and replace it with:

datasource:
  NoCloud:
    meta-data: |
      # whatever your meta-data file contained
    user-data: |
      # whatever your user-data file contained

if for whatever reason you'd rather keep your files under /boot/, you could always just replace:

fs_label: boot

with:

datasource:
  NoCloud:
    seedfrom: file://boot/

and cloud-init should continue sourcing your configurations from /boot/

[holmanb]

@mjsir911 please let me know if your use case isn't addressed by one of the suggested workarounds

[mjsir911]

Thank you all for the prompt response! seedfrom: file://boot/ should do what I want, I'll confirm this but I appreciate the plain outlining of alternatives :-)

[holmanb]

Thank you all for the prompt response! seedfrom: file://boot/ should do what I want, I'll confirm this but I appreciate the plain outlining of alternatives :-)

Of course! Happy to help. Let me know how it goes.

[holmanb]

@mjsir911 Also quick question: do you already have something like datasource_list: [NoCloud] set in your base configuration? If not, you might be able to optimize something.

If you don't already set datasource_list in your config, then cloud-init is likely taking unnecessary time during boot attempting to find a configuration from datasources besides NoCloud. Once 23be88d0 gets released (likely 24.3), this should be automatically fixed if you use seedfrom: file://boot/. The way to check if cloud-init is wasting time is to check for DataSourceMAAS and DataSourceConfigDrive in your /etc/cloud/cloud-init.log - if it doesn't exist then you won't benefit from this optimization.

[mjsir911]

@mjsir911 Also quick question: do you already have something like datasource_list: [NoCloud] set in your base configuration? If not, you might be able to optimize something.

Yeah, copying from another pi-cloud-init project, I have:

datasource_list: [ NoCloud, None ]
datasource:
  NoCloud:
...

which seems to not be hanging but I'm still tinkering with loading up user-data.yaml files & such

[holmanb]

The issue raised has been addressed.