I'm trying to partition the eMMC on a Beaglebone Black. Here is how I have /dev/mmcblk1 partitioned:

root@beaglebone:~# fdisk -l /dev/mmcblk1
Disk /dev/mmcblk1: 3.6 GiB, 3825205248 bytes, 7471104 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x9ccd5613

Device          Boot   Start     End Sectors  Size Id Type
/dev/mmcblk1p1  *       2048  206847  204800  100M  c W95 FAT32 (LBA)
/dev/mmcblk1p2        206848 7112703 6905856  3.3G  5 Extended
/dev/mmcblk1p5        208896  823295  614400  300M 83 Linux
/dev/mmcblk1p6        825344 1849343 1024000  500M 83 Linux
/dev/mmcblk1p7       1851392 2875391 1024000  500M 83 Linux
/dev/mmcblk1p8       2877440 3901439 1024000  500M 83 Linux
/dev/mmcblk1p9       3903488 4927487 1024000  500M 83 Linux
/dev/mmcblk1p10      4929536 7026687 2097152    1G 83 Linux

That's exactly how it should look. Partition 1 is a primary, partition 2 is extended, and the rest are logical. However, when I list devices, I only see partitions 1, 2, 5, 6, and 7.

root@beaglebone:~# ls -l /dev/mmcblk1p*
brw-rw---- 1 root disk 179,  9 Mar  2 23:53 /dev/mmcblk1p1
brw-rw---- 1 root disk 179, 10 Mar  2 23:53 /dev/mmcblk1p2
brw-rw---- 1 root disk 179, 13 Mar  2 23:53 /dev/mmcblk1p5
brw-rw---- 1 root disk 179, 14 Mar  2 23:53 /dev/mmcblk1p6
brw-rw---- 1 root disk 179, 15 Mar  2 23:53 /dev/mmcblk1p7

lsblk shows the same:

root@beaglebone:~# lsblk
mmcblk0      179:0    0  7.2G  0 disk
└─mmcblk0p1  179:1    0  3.3G  0 part /
mmcblk1      179:8    0  3.6G  0 disk
├─mmcblk1p1  179:9    0  100M  0 part
├─mmcblk1p2  179:10   0    1K  0 part
├─mmcblk1p5  179:13   0  300M  0 part
├─mmcblk1p6  179:14   0  500M  0 part
└─mmcblk1p7  179:15   0  500M  0 part
mmcblk1boot0 179:16   0    4M  1 disk
mmcblk1boot1 179:24   0    4M  1 disk

This is true even after a reboot. I'm trying to do this booted from the SD card running debian 9 (Linux beaglebone 4.4.84-ti-r120).

Does anybody know what might be going on here? Have I hit some sort of limit?


At least on Kernel developer seems to assume a fixed limit of four partitions for MMC. https://elixir.bootlin.com/linux/v3.3/source/drivers/mmc/card/block.c#L1587


The question was asked already over at superuser and answered with help of the Beaglebone Black kernel maintainer Robert C Nelson. The answer is basically the same as Ignacio Vazquez-Abrams already posted but it's missing info about the boot argument.

Reading the source it looks like the kernel should print mmcblk: using 16 minors per device if the mmcblk.perdev_minors=16 boot argument is working correctly. https://elixir.bootlin.com/linux/v4.4.84/source/drivers/mmc/card/block.c#L2694

  • Well certainly 4 primaries are the max, but it's more complicated than that. I've now combined 4 of my partitions in to two, which will work but isn't ideal. That leaves me with 4 primary (with one being an extended container), and 2 logical partitions, and that seems to be working. – Dave Mar 3 '18 at 18:34
  • 1
    It looks like the question already showed up on superuser and Ignacio Vazquez-Abrams is right with his answer. superuser.com/questions/899138 – thomas Mar 4 '18 at 0:27
  • 1
    There is a way to verify if your boot argument had an effect. The kernel should post a info about perdev_minor being different than CONFIG_MMC_BLOCK_MINORS. See elixir.bootlin.com/linux/v4.4.84/source/drivers/mmc/card/… – thomas Mar 4 '18 at 0:30
  • Interesting. I have no such message, so it's not taking effect. – Dave Mar 5 '18 at 14:44

The start of next SD/MMC card can be configured with CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe time using the mmcblk.perdev_minors option. That would bump the offset between each card to be the configured value instead of the default 8.


So, pass mmcblk.perdev_minors=16 on the kernel boot line.

  • I added that to the cmdline. /proc/cmdline shows: console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet mmcblk.perdev_minors=16 But nothing has changed. I still see just up to /dev/mmcblk1p7. – Dave Mar 3 '18 at 0:32

Just like Dave it did not help for me to pass the kernel parameter mmcblk.perdev_minors=16 (yes, my kernel was configured with CONFIG_MMC_BLOCK=y). Using the script extract-vmlinux and searching the uncompressed binary for strings it turned out that my kernel instead wanted the following parameter:


Replacing mmcblk with mmc_block allowed me to see all my partitions. I am using kernel 4.4.75, the documentation still says mmcblk instead of mmc_block in that source tree.

I found this question with its answers very useful to start debugging my problem and hope that my answer will help others with newer kernels.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.