Ah! I let it sit for a while and now I have debug info. Doesn’t look like it sees the eMMC on boot.
Gave this one a shot with yesterday’s daily. No luck. Blank screen, no debug info.
When I get home after work, I’ll take this machine off the kvm, remove the second disk (with the Ubuntu Core installation), wipe the partition table from the eMMC, and try again. Might as well knock out as many variables as possible.
Here are the steps I took tonight: wiped the eMMC completely, removed the machine from the kvm, removed the existing SSD, upgraded BIOS, and tried to install from USB (202601080126).
Unfortunately, same result. No luck with the eMMC. Installation completes to mmcblk0 (5 of 5 partitions) but then the installation fails to start (3s version selection menu and then nothing).
Running from usb works. Will pickup a cheap ssd this weekend and shove that in there to make sure it installs fine.
An uneducated observation: after installation, if I leave the USB drive in and select one of the two new EFI entries, I see the 3s version selection menu and then the installer starts again. If I remove the USB drive and select one of the two new EFI entries, I see the 3s version selection menu and then get a black screen. It almost seems like the installation, once on the mmc, doesn’t know it’s an installation, if that makes sense, and additionally depends on the USB drive.
If helpful, I’m happy to provide any other info or even give kvm access if you’re curious!
The debug screen that comes up after the 10min timeout still doesn’t show any mmc devices?
I just checked the content of the initrd for 202601080126 and we have:
"drivers/mmc/host/cqhci.ko",
"drivers/mmc/host/sdhci-pci.ko",
"drivers/mmc/host/sdhci-uhs2.ko",
"drivers/mmc/host/sdhci.ko",
So that looks better than the previous image we had but I see a couple of things missing that may be the problem:
- sdhci_acpi
- mmc_block
I’ll send a PR adding those two as well now.
I was too impatient to see it. Didn’t realize it was 10m—I guess I must have zoned out for a while to have seen it last time. ![]()
In about an hour I’ll reinstall it, let it sit for the timeout, and will get back. Would you like me to try with the tag I used or with latest (or both)?
Thanks for sticking with this one with me!
We’re building a new testing image right now which should include the most recent fix.
It will show up as 202601091704 once it’s done building and gets published (usually within 30-45min following the build completing).
Sounds good. I’ve been tracking the tags rss feed—will grab and install once it goes green (seemingly in a couple of mins).
It worked! Thank you so much! Very excited.
Is there any info you’d like me to pull from this machine now?
Great to hear it’s working now!
I don’t think we need anything from the system at this stage. Just let us know if anything else behaves weirdly.
Will do. Thanks again. Love your (= you + contributors at large) work. Really appreciate all of it!
Discovered another potentially related issue. Figured I’d mention before I dig in a little bit. Happy to break this out into a new thread if you’d prefer.
$ incus admin os system storage edit
WARNING: The IncusOS API and configuration is subject to change
Error: unable to determine device ID for /dev/mmcblk0boot0
Related debug logs:
[2026/01/13 14:11:04 EST] kernel: mmc0: Command Queue Engine enabled
[2026/01/13 14:11:04 EST] kernel: mmc0: new HS400 MMC card at address 0001
[2026/01/13 14:11:04 EST] kernel: mmc1: Failed to initialize a non-removable card
[2026/01/13 14:11:04 EST] kernel: mmcblk0: mmc0:0001 DA4064 58.2 GiB
[2026/01/13 14:11:04 EST] kernel: mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11
[2026/01/13 14:11:04 EST] kernel: mmcblk0boot0: mmc0:0001 DA4064 4.00 MiB
[2026/01/13 14:11:04 EST] kernel: mmcblk0boot1: mmc0:0001 DA4064 4.00 MiB
[2026/01/13 14:11:04 EST] kernel: mmcblk0rpmb: mmc0:0001 DA4064 16.0 MiB, chardev (235:0)
[2026/01/13 14:11:12 EST] 55-scsi-sg3_id.rules: WARNING: SCSI device mmcblk0boot0 has no device ID, consider changing .SCSI_ID_SERIAL_SRC in 00-scsi-sg3_config.rules
Disk info from another distro (IDs munged):
$ ll /dev/mmc*
brw-rw---- 1 root disk 179, 0 Jan 13 19:19 /dev/mmcblk0
brw-rw---- 1 root disk 179, 8 Jan 13 19:19 /dev/mmcblk0boot0
brw-rw---- 1 root disk 179, 16 Jan 13 19:19 /dev/mmcblk0boot1
brw-rw---- 1 root disk 179, 1 Jan 13 19:19 /dev/mmcblk0p1
brw-rw---- 1 root disk 259, 8 Jan 13 19:19 /dev/mmcblk0p10
brw-rw---- 1 root disk 259, 9 Jan 13 19:19 /dev/mmcblk0p11
brw-rw---- 1 root disk 179, 2 Jan 13 19:19 /dev/mmcblk0p2
brw-rw---- 1 root disk 179, 3 Jan 13 19:19 /dev/mmcblk0p3
brw-rw---- 1 root disk 179, 4 Jan 13 19:19 /dev/mmcblk0p4
brw-rw---- 1 root disk 179, 5 Jan 13 19:19 /dev/mmcblk0p5
brw-rw---- 1 root disk 179, 6 Jan 13 19:19 /dev/mmcblk0p6
brw-rw---- 1 root disk 179, 7 Jan 13 19:19 /dev/mmcblk0p7
brw-rw---- 1 root disk 259, 6 Jan 13 19:19 /dev/mmcblk0p8
brw-rw---- 1 root disk 259, 7 Jan 13 19:19 /dev/mmcblk0p9
crw------- 1 root root 239, 0 Jan 13 19:19 /dev/mmcblk0rpmb
$ for i in /dev/mmc*; do echo $i; sudo udevadm info -q symlink $i; done
/dev/mmcblk0
disk/by-id/mmc-DA4064_0xffffffff disk/by-uuid/0000000000000000000 disk/by-label/local
/dev/mmcblk0boot0
/dev/mmcblk0boot1
/dev/mmcblk0p1
disk/by-uuid/0000-0000 disk/by-id/mmc-DA4064_0xffffffff-part1 disk/by-partuuid/00000000-0000-0000-0000-000000000000 disk/by-partlabel/esp disk/by-label/ESP
/dev/mmcblk0p10
disk/by-uuid/00000000-0000-0000-0000-000000000000 disk/by-label/root-x86-64 disk/by-id/mmc-DA4064_0xffffffff-part10 disk/by-partlabel/root-x86-64 disk/by-partuuid/00000000-0000-0000-0000-000000000000
/dev/mmcblk0p11
disk/by-partuuid/00000000-0000-0000-0000-000000000000 disk/by-id/mmc-DA4064_0xffffffff-part11 disk/by-label/local disk/by-partlabel/local-data disk/by-uuid/0000000000000000000
/dev/mmcblk0p2
disk/by-id/mmc-DA4064_0xffffffff-part2 disk/by-partlabel/seed-data disk/by-partuuid/00000000-0000-0000-0000-000000000000
/dev/mmcblk0p3
disk/by-partuuid/00000000-0000-0000-0000-000000000000 disk/by-id/mmc-DA4064_0xffffffff-part3 disk/by-partlabel/IncusOS_202601091704_verity_sig
/dev/mmcblk0p4
disk/by-uuid/00000000-0000-0000-0000-000000000000 disk/by-partlabel/IncusOS_202601091704_verity disk/by-id/mmc-DA4064_0xffffffff-part4 disk/by-partuuid/00000000-0000-0000-0000-000000000000
/dev/mmcblk0p5
disk/by-partlabel/IncusOS_202601091704 disk/by-id/mmc-DA4064_0xffffffff-part5 disk/by-partuuid/00000000-0000-0000-0000-000000000000
/dev/mmcblk0p6
disk/by-partuuid/00000000-0000-0000-0000-000000000000 disk/by-partlabel/IncusOS_202601100100_verity_sig disk/by-id/mmc-DA4064_0xffffffff-part6
/dev/mmcblk0p7
disk/by-uuid/00000000-0000-0000-0000-000000000000 disk/by-partuuid/00000000-0000-0000-0000-000000000000 disk/by-partlabel/IncusOS_202601100100_verity disk/by-id/mmc-DA4064_0xffffffff-part7
/dev/mmcblk0p8
disk/by-partlabel/IncusOS_202601100100 disk/by-partuuid/00000000-0000-0000-0000-000000000000 disk/by-id/mmc-DA4064_0xffffffff-part8
/dev/mmcblk0p9
disk/by-uuid/00000000-0000-0000-0000-000000000000 disk/by-label/swap disk/by-partuuid/00000000-0000-0000-0000-000000000000 disk/by-partlabel/swap disk/by-id/mmc-DA4064_0xffffffff-part9
/dev/mmcblk0rpmb
Hmm, we’ll probably need to special-case the mmc boot partitions…
There’s also that weird rpmb one that I’m not sure what it’s about.
@gibmat any reason we don’t just ignore anything that doesn’t have a device ID?
The error that’s being reported is coming from our logic to determine which device IncusOS is running from, so we can’t just ignore things. But I’m not sure right off hand why it’s looking at mmcblk0boot0, since we don’t touch/create that partition(?).
Those three partitions were news to me. Looks like they’re hardware partitions for eMMC. I had wiped the partition table but I guess these are reserved areas on the chip.
Turns out the very latest QEMU release (10.2.0) can emulate emmc devices. Still can’t boot from the device, but I was able to see the mmcblk0boot{0,1} and mmcblk0rpmb devices and reproduce the most recent error. Hopefully the PR should fix things once merged. ![]()
Thank you so much! You folks are amazing.
Confirmed fixed on testing. Thanks again!