I'm trying to mount the libreelec storage partition of an SD card built with a fresh dual boot install of raspbian + libreelec on a 128GB Sandisk CD card built with NOOBS. I'm using a Raspberry Pi 3 Model B.

Both OSs work fine on the pi so it looks like the install was successful. The only issue is that when I put the CD card into a laptop running Ubuntu 16.04, Gparted is unable to mount the Libreelec partitions.

This is an issue as I would like to load it with some videos for local viewing from the SD. That's why I used such a large card. When Libreelec is running I can sftp into it and load the files that way but its very slow.

As soon as I start Gparted it reports the error that the partitions have been written but the kernel can't be informed "probably because it/they are in use".

The SD card partitions look as though they are created correctly and both OSs work on the pi but for some reason partition 8 & 9 don't mount.

Here's the gparted window: gparted window

You see the errors for partitions 8 & 9. When I click on partition 8, this is the error: Gparted partition 8 error

And partition 9 says similar but for the e2fsprogs package but dosfstools, mtools and e2fsprogs are all installed.

Parition 8 will be the libreelec boot partition and partition 9 the storage partition ie the one I'm looking to mount.

I guess its something to do with the large number of extended/logical partitions or maybe something to do with shrinkfs.

Do you have any ideas how I can mount Libreelec's storage partition?

1 Answer 1


I found a work around for this mounting the sector directly bypassing the partition table. It's not ideal but it works.

Thanks @procount over at the raspberrypi.org forum for pointing me to the MBR/ADFS issue. The issue seems to be NOOBs puts the boot record for RISC OS on the SD card whether you install Risc OS or not and this appears to confuse the linux kernal used in Ubuntu/Debian since the end of 2015 at least. NOOBs sees it as a kernel issue so won't fix it. I used a solution of modifying the riscos-boot.bin file in the NOOBS directory on the SD card before the first time its booted on the Pi with this:

cd NOOBS_v2_0_0     # this moves to the extracted NOOBS folder
mv "riscos-boot.bin" "riscos-boot.bin.original" # save the original file in case you need to install Risc OS later
dd if=/dev/zero of="riscos-boot.bin" bs=512 count=19 # create the modified file to work around the partition problem in ubuntu`

This replaces the Risc OS boot sector with zeros so the kernel should no longer get confused. gparted now no longer reports an error when the card is put in but the partitions still won't mount through the GUI.

I did some tests. [b]sudo partprobe /dev/mmcblk0[/b] results in:

Error: Partition(s) 8 on /dev/mmcblk0 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.[/quote]

Which suggests the kernel still isn't happy with the resultant SD card or perhaps something is wrong with the partition table. I tried recreating it in gparted with the same result.

Looking at the SD card using sudo fdisk -l /dev/mmcblk0 gives:

Disk /dev/mmcblk0: 119.1 GiB, 127865454592 bytes, 249737216 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: 0x5d3458e6

Device         Boot    Start       End   Sectors   Size Id Type
/dev/mmcblk0p1          2048   2474609   2472562   1.2G  e W95 FAT16 (LBA)
/dev/mmcblk0p2       2474610 249737215 247262606 117.9G  5 Extended
/dev/mmcblk0p5       2482176   2547709     65534    32M 83 Linux
/dev/mmcblk0p6       2547712   2682879    135168    66M  c W95 FAT32 (LBA)
/dev/mmcblk0p7       2686976  43646973  40959998  19.5G 83 Linux 
/dev/mmcblk0p8      43646976  44695549   1048574   512M  c W95 FAT32 (LBA)
/dev/mmcblk0p9      44695552 249737215 205041664  97.8G 83 Linux

and with sudo blkid:

/dev/mmcblk0p1: LABEL="RECOVERY" UUID="55E5-68DB" TYPE="vfat" PARTUUID="5d3458e6-01"
/dev/mmcblk0p5: LABEL="SETTINGS" UUID="b7695dd5-a218-410f-bc1e-2b69bb370e55" TYPE="ext4" PARTUUID="5d3458e6-05"
/dev/mmcblk0p6: SEC_TYPE="msdos" LABEL="boot" UUID="6D9B-18FD" TYPE="vfat" PARTUUID="5d3458e6-06"
/dev/mmcblk0p7: LABEL="root" UUID="294e63b6-0052-432e-8dfa-878df194322d" TYPE="ext4" PARTUUID="5d3458e6-07" 
/dev/mmcblk0: PTUUID="5d3458e6" PTTYPE="dos"

which all looks ok.

Using the fdisk output I can see the offset to the start of the partition so can mount it with:

sudo mount /dev/mmcblk0 /media/ian/libreelecboot -o offset=$((44695552*512))

Which mount it as root! That means I can copy the files at least with a root launched nautilus. Not great (and not "just works") but I'll use that for now.

Incidentally sudo umount /media/ian/libreelecboot doesn't work - it's always busy even if I've closed down all processes that can access it. Again, not great but there we are.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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