Raspberry Pi Imager appears to ignore cloud_init and manifest for rpi-image-gen image

[r-colvin]

This issue could equally be raised on Raspberry Pi Imager - I am raising on rpi-image-gen as I have only experienced this issues on images built with rpi-image-gen; I recognise it falls in the overlap of the venn diagram between rpi-image-gen and Raspberry Pi Imager. If, after reading through, this would be best handled in Raspberry Pi Imager, let me know and I will move it there

This was discussed in the raspberry pi forums before raising here as I am very open to the possibility this is user error rather than an actual issue. See: https://forums.raspberrypi.com/viewtopic.php?p=2363442

I have built custom images with rpi-image-gen - when creating SD cards using Raspberry Pi Imager the customizations that are made don't seem to take effect - usernames, ssh keys, hostnames, wifi settings. I have used the image.json generated by rpi-image-gen and added customizations through the Raspberry Pi Imager GUI, in this case I was unable to even see the user-data, network-config and meta-data in the BOOT partition of the SD. When using rpi-imager --cli pointing to user-data and network-config taken from a previously imaged SD using the standard Raspberry Pi build, the cloud-data, meta-dat and network-config are on the SD BOOT partition, but the booted image has the wrong hostname, does not appear on the network and I am unable to login with the user/pass I configured.

My custom image is based on trixie-minbase.yaml; the network-config and user-data cloud_init files were taken from the BOOT partition of an SD I imaged from a standard Rasperry Pi Imager Trixie image.

When using the rpi-imager --cli I used --debug, here is a snippet of the logs

Applications/Raspberry\ Pi\ Imager.app/Contents/MacOS/rpi-imager --cli --cloudinit-userdata ~/Desktop/user-data --cloudinit-networkconfig ~/Desktop/network-config-home  --debug ~/rpi-image-work/artifacts/my_trixie.img /dev/disk4
...
setSrc: initFormat parameter: "cloudinit" -> _initFormat set to: "cloudinit"
...
Cloudinit: "#cloud-config\nmanage_resolv_conf: false\nhostname: MyHostName\n ..... enable_ssh: true\nssh_pwauth: false\nrpi:\n  interfaces:\n    serial: true\n"
initFormat parameter: "cloudinit" -> _initFormat: "cloudinit"
....
Checking customization: config= false cmdline= false firstrun= false cloudinit= true initFormat= "cloudinit" isEmpty= false
_customizeImage: _initFormat= "cloudinit" initCloud= true _cloudinit.isEmpty()= false
...
Write timing stats: writes= 199 syscall= 0 ms preHashWait= 137 ms postHashWait= 0 ms sync= 0 ms syncCount= 0 avgSize= 8192 KB
WriteProgressWatchdog: Stopped

Given the above, I assume that the customizations are being picked up - the imaging seem to complete and is verified. When I boot the Pi with the SD card though, it boots to a login prompt - however, the hostname is as was set in the config/project.yaml file in rpi-image-gen; The Pi doesn't appear on the network, I can't ssh in or login with the username/password I set in the user-data file (taken from a working raspberry pi imager generated SD card)

Thinking the rpi-image-gen was the cause, I cleared out the config/project.yaml to just point to image: trixie-minbase.yaml, removing all customizations (hostname, etc) passing the device type on the rpi-image-gen build command line (IGconf_device_layer=rpi3)

$ sudo rm -rf work/*; time ./rpi-image-gen build -S ./myProject/ -c project.yaml -- IGconf_device_layer=rpi3 IGconf_image_name=project_Pi3_v0.1

when I did this, the Pi got a random hostname - pi3-ivzytc - and otherwise everything else was the same, no network, unable to login with my username/pass, no ssh (no network of course!)

i am not sure if it's relevant, when I review the recording I made of the boot, everything is [ OK ] ... the only thing of note I have seen so far is

systemd[ 1 ]: Hostname set to <pi3-ivzytc>
systemd[ 1 ]: Failed to open libbpf, cgroup BPF features disabled: Operation not supported

Based on https://github.com/raspberrypi/rpi-imag ... formats.md - does the mention of systemd imply firstrun.sh and given I don't have a firstun.sh that might explain the issues - but everything else here is set to use cloud_init

I am using Raspberry Pi Imager 2.0.6 on an M3 Mac.

[tdewey-rpi]

Your report suggests that cloud-init isn't running in your image.

When you drive the rpi-imager cli in the manner you have, it simply copies your configuration into the VFAT partition of your image - provided you have one.

Do you see anything from the cloud-init services in the systemd journal?

[r-colvin]

thanks @tdewey-rpi - are we assuming the login is pi/raspberry so I can log in on the command line

(sorry, haven't tested as I don't have a Pi to hand just now :) )

[tdewey-rpi]

thanks @tdewey-rpi - are we assuming the login is pi/raspberry so I can log in on the command line

(sorry, haven't tested as I don't have a Pi to hand just now :) )

Only if your image is configured to use the Raspberry Pi OS user creation flow - which might not be true (you know your image better than me, I hope!).

Assuming you selected rpi-cloudinit-mods too, the journal will be the only location you can find the logs - I stopped them being emitted to the console after people mistook them for boot failures (they were not).

[r-colvin]

hrmm ok! ill have to do some digging, as yet i've not been able to login to my custom image..

[learmj]

Hi @r-colvin
rpi-image-gen currently does not support cloud-init. By "does not support", I mean there are no layers, configuration files or examples anywhere in the tree that would allow you to create a 'cloud-init compatible' image. Adding this support is on my todo list.

Please note that rpi-image-gen is not the tool that creates the official Raspberry Pi OS images (see here).

The goal with rpi-image-gen (at least at the moment) is to put the work into creating a configuration framework engine that enables users/developers to use well documented, well supported and structured declarative syntax to build up modular components enabling them to create their own custom images.

Have a look at:
pi-gen:
stage2/04-cloud-init
stage2/04-cloud-init/files
https://www.raspberrypi.com/news/cloud-init-on-raspberry-pi-os/

Basically - the image generation / build tool needs to install cloud-init metadata files into the vfat boot partition of your image in order for cloud-init to run and function. rpi-image-gen does not currently support this, but I intend to add it in future.

[learmj]

@r-colvin

when I did this, the Pi got a random hostname - pi3-ivzytc

If no hostname (IGconf_device_hostname) is provided, the device-base layer intentionally sets a random hostname.

[r-colvin]

hej @learmj thanks for those replies - makes things a bit more clear. I'm sure that information is somewhere, but in trying to wade through the rpi-image-gen docs and the rpi-imager docs and cross referencing i guess I missed it

do you see #184 in the short/medium or long term roadmap? only reason for asking is to figure out if I just wait for it, or if I need to find a new solution, at least temporarily.

I must admit I assumed (hoped?) that the difficulty would be in building the layers I need, and that user-management and network-management would be the easy part (as rpi-imager would handle it). If it helps with your process my use case is as follows:

I have gotten tired of flashing a standard RPi image to an SD card, then manually customizing it. In the fleet of Pi's I need to manage (a mix of Pi 3/4/5 with both NVME and SD boot devices and NVME storage devices) there is enough common components, tools and the like that it makes sense to have a common core image that can be deployed by anyone and anytime - in the event the SD corrupts its simple to flash a new one; in the event that the hardware dies a new Pi can be deployed instantly

some projects need graphical desktops and VNC, others are headless - the users that are installed to each Pi are different, the hostnames and wifi networks might be different as well.

Thus, rpi-image-gen looked ideal for my needs. I can have a core config.yaml, then each project just has some different layers that get enabled or not. At build time I can specify which devices type its intended for. Then with a wrapper to rpi-imager --cli I can specify the specifics - hostname, wifi and users. Anyone who needs to flash a new SD can just follow a simple lazy-dog document. To be honest I have not actually been able to get networking setup inside rpi-image-gen (have read plenty of others attempts, but it seems most are using old rpi-image-gen versions, or using ethernet). Same for users, initially I used the user1 as documented in the README, but I believe networking and users are best (for me) handled outside the image itself. Hostnames are also best outside otherwise for each hostname I need to build the image again.

Long story short, I think cloud_init with rpi-image-gen and rpi-imager are what I need :)

is firstrun an option in the meantime?

#146 mentions Example network configuration which appears to have been merged to master, but I don't see it in the docs/ folder yet. Also not sure if that would solve my use case!

lastly, rpi-image-gen generates an image.json manifest - which I can load in the GUI of rpi-image-gen, should that work to customize the image?

thanks :)

[learmj]

No, #146 or its corresponding #145 haven't been merged - the requester made a valid point that there is no built-in or documented way of declaring a custom network configuration. There was chat about submission of some examples into contrib/ (see their linked repo https://github.com/devopsbob/ke-net-screen/tree/feature/genericize where you can find different net config layers under layer/). These may or may not be something that can help you in the short-medium term.

The only thing we have right now as far as networking goes is systemd-net-min. That is extremely minimal, but it's also somewhat intentional. Rather than trying to provide parity with images produced by pi-gen, the rpi-image-gen development effort has prioritised the foundational core engine and building blocks that underpin every build, in order to make sure things are solid and scalable so the tool can deliver concrete functionality. Users who are already onboard with the tool have their own custom layers, configurations, etc working. For example, a user in #170 seems to have cloud-init functional despite there being nothing in the tree to use as a reference.

Today, there is no equivalent of a Raspberry Pi OS Lite or Desktop image that can be generated by rpi-image-gen. That's not to say it's not possible - it's just not where the development effort has been. It's in our (Raspberry Pi's) own interests to make sure that the tools we supply integrate well with each other, so to that point, yes - I envisage adding cloud-init support to rpi-image-gen at some point.

I don't think it's a sizeable task, but because of the flexible nature of the tool and cloud-init itself, care will need to be taken to utilise metadata conflict management between layers, and to provide modular layers that install packages required by cloud-init features that folks may want to use. For example, I don't think systemd-net-min would play nicely with cloud-init as-is because networkd is only listed as an 'activator' rather than a 'renderer'. Therefore a user of this layer who wanted cloud-init would have to hook up installing netplan (so they can use networkd as the backend), or they may want network-manager for the renderer, the activator, or both. These packages and any associated templated config files needing installing would need to be provided via clearly documented layers.

Other questions...

is firstrun an option in the meantime?

There isn't any first run support in rpi-image-gen. This comment explains some of the reasons why. Also, I know that some users have written their own firstrun implementation to fulfil their requirements.

lastly, rpi-image-gen generates an image.json manifest - which I can load in the GUI of rpi-image-gen, should that work to customize the image?

rpi-image-gen does't have a GUI. image.json is specifically for the provisioning of images using rpi-sb-provisioner. Some information can be found here.

[r-colvin]

rpi-image-gen does't have a GUI. image.json is specifically for the provisioning of images using rpi-sb-provisioner. Some information can be found here.

sorry, my mistake.. im constantly confusing myself with the names...!

rpi-image-gen generates an image.json manifest - which I can load in the GUI of rpi-imager, should that work to customize the image? without the image.json manifest the customization option is, of course, greyed out but when loading the image.json that rpi-image-gen creates, you can access the customization fields, they just don't do anything (which i guess is the cloud_init support, and i answered my own question!)

[learmj]

rpi-image-gen generates an image.json manifest - which I can load in the GUI of rpi-imager, should that work to customize the image?

Still no. Imager doesn't know anything about the format of that file.

[learmj]

im constantly confusing myself with the names...!

In case it helps, see https://www.raspberrypi.com/documentation/computers/software-sources.html