Ubuntu will install to microSD but not MMC. Windows installs to MMC without issue

Here is what you should see:

$ dmesg | grep mmc
[    2.087537] mmc0: CQHCI version 5.10
[    2.089346] mmc0: SDHCI controller on PCI [0000:00:1c.0] using ADMA 64-bit
[    2.270840] mmc0: Command Queue Engine enabled
[    2.270854] mmc0: new HS400 MMC card at address 0001
[    2.277693] mmcblk0: mmc0:0001 DA4032 29.1 GiB
[    2.280373]  mmcblk0: p1 p2 p3
[    2.280654] mmcblk0boot0: mmc0:0001 DA4032 4.00 MiB
[    2.281288] mmcblk0boot1: mmc0:0001 DA4032 4.00 MiB
[    2.281982] mmcblk0rpmb: mmc0:0001 DA4032 16.0 MiB, chardev (237:0)

mmcblk0rpmb == 16MB Replay Protected Memory Block of mmc device. This memory block is encrypted and not otherwise user usable.

mmcblk0boot0, mmcblk0boot1 == Reserved 4MB read only boot blocks of mmc device.

mmcblk0: p1 p2 p3 == My 3 partitions - EFI, root and user.

My system is an HP Blooguard ChromeBook.

MODEL SERIAL     NAME         TYPE  SIZE LABEL          UUID                                 FSTYPE MOUNTPOINT RM RO
      0xdcfe5719 mmcblk0      disk 29.1G                                                                        0  0
                 |-mmcblk0p1  part  120M EFI            0C41-17CF                            vfat               0  0
                 |-mmcblk0p2  part 14.5G ROOT_Blooguard 3b7f4ac8-db82-4809-b14f-4d2a1089e370 ext4   /           0  0
                 `-mmcblk0p3  part 14.5G USER_Blooguard f3eb04d3-fa56-4029-a326-37a17d984fe1 ext4   /Blooguard  0  0
      0xdcfe5719 mmcblk0boot0 disk    4M                                                                        0  1
      0xdcfe5719 mmcblk0boot1 disk    4M                                                                        0  1

$ cat /sys/devices/virtual/dmi/id/product_family

$ uname -a
Linux Blooguard 6.9.8-djb_24189 #1 SMP PREEMPT_DYNAMIC Sun Jul 7 13:24:21 UTC 2024 x86_64 GNU/Linux

Kernel version 6.9.7 of Arch ISO should work.

It sure looks to the Linux kernel as if the mmc is broken.


Not all Chromebooks are the same. You cannot plainly say “this is what you should see” when every single device will have a different output.

The issue is that it doesn’t work, and sharing what it should look like doesn’t help fix the issue at all in this case

It hangs on booting or hangs on running fdisk?

OP has Lenovo Phaser ChromeBook which is a Google Octopus design.
My HP Blooguard is also a Google Octopus design so hardware will be identical. BIOS is MrChromebox so that is identical as well. MMC design follows a standard with two small boot blocks and an encrypted Replay Protected block. In this case, what I posted for my Google Octopus Chromebook should exactly match OP Lenovo Phaser Chromebook.


While Blooguard and Phaser will be very similar as they are based on the same baseboard (Octopus), that doesn’t mean that they use the same eMMC, or that the tuning is the same. They aren’t the same boards and don’t use the same firmware image.

Are there any differences that the Linux kernel needs to know about?

I have no idea. It’s possible that the stock firmware does some tuning to the eMMC before booting that the UEFI firmware is not, would have to look at the depthcharge source

OP Can you post about 12 lines output of dmesg | grep mmc? I’m curious to see what your mmc device is and if the Linux kernel can locate it at all.

Here’s the dmesg output

I was able to shrink the partition on /dev/sdb slightly and clone to /dev/mmcblk0 using dd in BionicPup, but it seems to not be bootable. gets to grub and i can select ubuntu, but then its reporting Buffer I/O error on dev mmcblk0, and wont load to OS

Thank you. Your MMC is a Kingston chip – I have the programming info data sheet. The Command Queue Host Controller Interface (CQHCI) is not being started by the kernel for your chip. It is likely that the kernel has put the chip in an incompatible mode.

I can debug this if you want to take off list.


Thank you for your help! I’m not sure what you mean by “if you want to take off list”, but please let me know how I can proceed

Save the output of dmesg somewhere so I can see if there are any clues as to why the Linux kernel is disabling the mmc. There are error paths in the Kernel mmc driver that set the bus width to 0 to prevent mmc damage.

@wb4kdi here is the dmesg output. Thanks!

Thank you. Digesting the dmesg. It looks like the card quits responding when HS400 speed is selected. That should select a 200MHz mmc clock. The kernel driver doesn’t generally know what the host device values are for 200MHz it just requests them (efi bios call?). There should be some device recovery ops but I don’t see them in the dmesg.

Interesting. I’ve found that for whatever reason 32 bit bionic pup boots fine from a live USB and has no issues with reading and writing to the eMMC. I’ve been able to rewrite partition tables and clone the OS from the microSD, but then it’s not bootable as the OS can’t read the partitions. Perhaps it comes down to the kernel version

Bionic pup kernel version is? Does the dmesg output look clean without those CQHCI and SDHCI debug outputs? It may be what options are compiled into the kernel – post the config for the live version too.