Ubuntu Core 24 image hangs at “Installing Ubuntu Core…” on Raspberry Pi CM5 eMMC with custom gadget snap

device
1

Hi, I’m building a custom Ubuntu Core 24 image for the Raspberry Pi Compute Module 5 (CM5) eMMC using a modified gadget snap.

What I’ve done so far

  1. Started from the official pi-gadget recipe (Core 24 branch).
  2. Confirmed that the produced gadget snap includes bcm2712-rpi-cm5-cm5io.dtb.
  3. Updated configs/config.txt-cm4-support and configs/config.txt-fkms to add a [pi5] section that includes:
[pi5]
dtoverlay=dwc2,dr_mode=host
device_tree=bcm2712-rpi-cm5-cm5io.dtb
  1. Built the gadget snap and used it with ubuntu-image to generate a custom Core 24 image.
  2. Flashed the image to the CM5 eMMC (via rpiboot) and booted the CM5.

What works

  • Boot loader, firmware, kernel, and DTB load successfully.
  • The system shows the Ubuntu Core “Installing…” splash screen.
  • HDMI and USB host functionality work as expected.

Where it gets stuck

  • The display remains indefinitely at “Installing Ubuntu Core…”
  • No further progress is visible, and no login prompt appears.
  • Network and console-conf never start or complete.

My ultimate goal

I want to build a fully-sealed Ubuntu Core 24 image for CM5 (IO-board + eMMC), using a custom gadget snap.

Are there any CM5-specific known issues during the Core installation stage?

2

console-conf moved out of the core24 snap to being its own package, does your model assertion have it listed as separate snap ? Else there wont be any dialog …

(While the symptoms admittedly look like you actually hang at the install step, the above is indeed still relevant in case you expect interactive network and user setup from your image)

3

Here’s what I have in my model assertion:

{
  "type": "model",
  "series": "16",
  "model": "ubuntu-core-24-pi-arm64",
  "architecture": "arm64",
  "grade": "dangerous",
  "base": "core24",
  "snaps": [
    { "name": "pi",             "type": "gadget" },
    { "name": "pi-kernel",      "type": "kernel",  "default-channel": "latest/stable" },
    { "name": "core24",         "type": "base",    "default-channel": "latest/stable" },
    { "name": "snapd",          "type": "snapd",   "default-channel": "latest/candidate" },
    { "name": "console-conf",   "type": "app",     "default-channel": "24/stable" },
    { "name": "automount-core", "type": "app",     "default-channel": "latest/stable" },
    { "name": "ubuntu-frame",   "type": "app",     "default-channel": "24/stable" },
    { "name": "mesa-2404",      "type": "app",     "default-channel": "latest/stable" }
  ]
}
  • I’ve included console-conf explicitly with channel 24/stable so that the interactive user/network configuration UI appears at first boot per Core24 requirements (not part of the gadget or base) documentation.ubuntu.com+12documentation.ubuntu.com+12discourse.ubuntu.com+12.
  • This same model was previously used to build a working Core24 image for CM4 (which completes onboarding).
  • But when I build with the same model + gadget snap customized for CM5, it boots to “Installing Ubuntu Core…” and then hangs indefinitely.

What I want to verify or have your insight on

  1. Since console-conf is included in the model, should the first-boot UI appear by default—even over serial/tty?
  2. If the system hangs before launching console-conf, could the issue be related to missing pre-seeded user-data, network-config, or invalid user SSH keys?
  3. Is there a known CM5-specific behavior (e.g. lack of serial console, fallback, or network issue) that prevents console-conf from launching properly?
  4. Are there recommended debug hooks or serial logs I should enable to trace whether console-conf ever starts or if snapd is blocked at install time?
4
  1. Yes, if console-conf is seeded it should also start after the install step finished
  2. None of the bits you listed should ever prevent booting/installing
  3. Not that I know of, but I have personally not touched CM5 devices yet
  4. I fear there isn’t a lot if you already get serial logs, perhaps some extra debugging options for systemd to raise the amount of output to the log, probably some extra debug settings for snapd on the cmdline