I've just mounted a microSD card which has 17 partitions in my laptop and I'm getting the following error in the YaST partitioner:

Your disk /dev/mmcblk0 contains 17 partitions. The maximum number of partitions that the
kernel driver of the disk can handle is 7. Partitions above 7 cannot be accessed

and indeed - I have only /dev/mmcblkp0...7. Well, actually I have only 3 partitions because an extended partition starts at partition number 5, so it's p0, p5, p6, p7.

I've formatted this card using a card reader in a printer on another PC which was exposing the microSD card as /dev/sdxY and allowed me to create 17 partitions. Now I've put it into a laptop with a built-in card reader and it gives the above error. Why is that?

It's suggesting to use LVM but come on, LVM on microSD is overkill and inconvenient as hell for removable storage.

  • 1
    @frostschutz - i guess that's possibly the case for some old kernel configs, which is probably the source of this problem. But the actual limit is 256.
    – mikeserv
    Jul 22, 2015 at 15:09
  • @frostschutz - yeah, that's true. MMC_BLOCK_MINORS is 8 in my config.gz. Still, LVM is excessive. loopmounts would be easier, and easier to recover to be sure. I guess the system that allowed the creation of the partitions could handle the 18 or whatever, but not the system asker plugged it into.
    – mikeserv
    Jul 22, 2015 at 15:24

1 Answer 1


LVM is not overkill if you have 17 partitions. (IMHO)

As for the partition limit, it just happens to be the default. Probably no one expected that many partitions on a device that used to have only a few megs.


179 block       MMC block devices
                  0 = /dev/mmcblk0      First SD/MMC card
                  1 = /dev/mmcblk0p1    First partition on first MMC card
                  8 = /dev/mmcblk1      Second SD/MMC card

                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 it might work if you recompile your kernel with CONFIG_MMC_BLOCK_MINORS=18 or with the mmcblk.perdev_minors=18 kernel parameter. (Or 32 in case it has to be a power of 2). Doing so will reduce the total number of mmcblkX you may have in your system.

Personally I'd rather lower the number of partitions so it will work everywhere and not just your customized system.

  • I have multiple partitions with multiple various filesystems just in case part of card would got damaged it's a bit like some primitive "mirror raid" on single card. additional LVM just adds more complexity and failure opportunity. Welp, I'll get some adapter then. I've already had failure once, when btrfs on sd card got damaged and I couldn't recover data - it's actually the same card, I've reformatted it after failure.
    – Lapsio
    Jul 22, 2015 at 15:03
  • Other devices have partition limits as well (usually 15 instead of 7). There is 259 block Block Extended Major (not sure why not used by mmc, probably no one expected it) but even that has limits. You can use partx, kpartx, and map additional partitions through device mapper w/o using "LVM" per se. LVM just makes things simpler, if you're going to have to use the device mapper anyway. In an embedded environment that does not have device mapper, losetup with offset/sizelimit might also be an option. Jul 22, 2015 at 15:30
  • But adding a kernel parameter seems the simplest thing all things considered. Jul 22, 2015 at 15:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .