I used a minimal set of snaps to build the base image and created a new model assertion. The base model was derived from the sample model: models/ubuntu-core-20-pi-armhf.json at master · canonical/models · GitHub. I replaced the authority-id and brand-id with my Ubuntu developer ID so I can sign it, and added a serial-authority to obtain a serial from the global store for testing remodeling.
Original model used to build the image on armhf Core 20:
After snapd reported that it had set the new model assertion and would restart, my Raspberry Pi got stuck on the Ubuntu boot screen with a spinner indefinitely. I tried:
Letting it run overnight
Rebooting and waiting
Holding down the “1” key during boot to trigger recovery mode
None of these worked. The device always returned to the same boot screen, and recovery mode never activated. I attempted both online and offline remodeling (passing in the new core, kernel, gadget, and application snaps and assertions via the command line) - same result each time. I had to reflash the device after every attempt.
Since the Canonical guide uses arm64 as the example, I’m wondering if armhf behaves differently. Has anyone successfully upgraded from Core 20 to Core 22 on armhf? Any insights or suggestions would be greatly appreciated.
I tried a few more tests including arm64-core20 → arm64-core22 and arm64-core22 → arm64-core24 and still didn’t have any success, so the issue seems to be larger than just going from armhf-core20 to something else.
I don’t know that cross-architecture remodelling is expected to work, but you can try to identify if the remodel actually took in a variety of ways. The first place to start would be by inspecting the task change history; snap changes should show the recent ones (this list can expire sufficiently old items, so it may no longer be on the list…). You can see details on any particular change with snap change <id> to inspect them.
I know that sometimes when remodelling I experience similar situations. There are still some cases where snapd will erroneously report success/invisibly hide failures. I guess not all of them have been found yet
Thanks for the response! Just to clarify - I didn’t attempt to change the architecture in the tests for this post. I’ve tried upgrading on separate images built for either armhf or arm64, but in all cases, the upgrade path stays within the same architecture and just moves to a newer Ubuntu Core version.
The issue I’m running into is that after the upgrade, my raspberry pi gets stuck on the Ubuntu boot screen with the spinner and never fully boots. So I can’t access the system and inspect snap changes.
It sounds like you’ve had success with remodeling - would you mind sharing what platform and configuration you used? (e.g., raspberry pi or pc, 32-bit or 64-bit, arm or amd, etc.) Thanks!
I’ve remodelled from core22->core24 on amd64 and riscv64, so not quite the same.
There have been changes to the pi gadget between core20 and core22, specifically a change from u-boot to piboot. This may be the root cause of your issues (and I think @ogra probably knows far more about that than I do).
It may prove arduous, but you could attempt to fork the pi-gadget and switch from piboot back to u-boot. Otherwise, I’m uncertain if there is a migration path via remodelling from core20->core22.
Thanks for sharing that. It’s good to know that remodeling works on at least some platforms.
Regarding the bootloader differences between core20 and core22, we had the same suspicion as well. That’s why we ran follow-up tests attempting a core 22 → core 24 upgrade on arm64. From what I understand, both 22 and 24 use pi-boot. But unfortunately, that didn’t work either. That makes me wonder if remodeling is simply not supported on raspberry pi’s.
There might also be a size issue of the partitions…
IIRC the original pi gadgets were not really designed with remodeling in mind, so your boot partition might not have enough space to hold the second kernel and you might need to define the sizes all a tad larger …
Thanks for the insight! Are you referring to the ubuntu-boot partition defined in gadget.yaml? From what I can see, both the core20 and core24 channels of the pi-gadget define it as 750MB, so my base image should be consistent with that.
I also ran a df -Th on my base image, and it showed that only a small percentage of the partition was used - most of the space appears to be available
