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.