partition table conflicts when plugging SD card to newer ubuntu 15.04/14.04.2 kernel

[beta-tester]

according problems
https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=111131
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=105437

with plugging a NOOBS sd card to a newer ubuntu (debian) desktop PC/Laptop
i reported an issue report to ubuntu team
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1457526

and the problem seems to be the combination of existence of MSDOS partitiontable and RISCOS (partitiontable?) at the same time on the SD card.

i was looking into the code of NOOBS 1.4 and the RsicOS blob (the content of the file "riscos-boot.bin") will always be written to the SD card, even if it is not needed, because there is no RiscOS in the list of installed OS'es...
the newer kernel of ubuntu will catch that RiscOS blob/partitiontable first and mess up the detection of msdos partition tables...

do you see any chance to change that partition 'casino'?
is the RiscOS blob used for something else than a RISC OS, when it is installed?
maybe then only write the RiscOS blob to the SD card, if somebody installs a RISC OS, and elsewise fill the region with zeros.

what i was testing was,
i filled up the "riscos-boot.bin" file with zeros and forced with 'runinstaller' in cmdline recreation of partitions,
so the function InitDriveThread::writeRiscOSblob() will write only zeros to the SD card...
and that solved the problem of detecting the msdos partition table under newer ubuntu.
but it was only to be sure, that it is really the RiscOS blob.

with zeroing out riscos-boot.bin

dmesg:
[ 4119.677383] usb 6-1.7: new high-speed USB device number 8 using ehci-pci
[ 4119.771922] usb 6-1.7: New USB device found, idVendor=058f, idProduct=6335
[ 4119.771927] usb 6-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4119.771930] usb 6-1.7: Product: Mass Storage Device
[ 4119.771932] usb 6-1.7: Manufacturer: Generic
[ 4119.771934] usb 6-1.7: SerialNumber: 058F011111B1
[ 4119.772463] usb-storage 6-1.7:1.0: USB Mass Storage device detected
[ 4119.772776] scsi host9: usb-storage 6-1.7:1.0
[ 4120.768974] scsi 9:0:0:0: Direct-Access     SD/MMC   Card  Reader     1.00 PQ: 0 ANSI: 0
[ 4120.769419] sd 9:0:0:0: Attached scsi generic sg3 type 0
[ 4121.004748] sd 9:0:0:0: [sdc] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
[ 4121.006953] sd 9:0:0:0: [sdc] Write Protect is off
[ 4121.006959] sd 9:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 4121.009098] sd 9:0:0:0: [sdc] No Caching mode page found
[ 4121.009104] sd 9:0:0:0: [sdc] Assuming drive cache: write through
[ 4121.033350]  sdc: sdc1 sdc2 < > sdc3
[ 4121.044793] sd 9:0:0:0: [sdc] Attached SCSI removable disk
[ 4121.640241] EXT4-fs (sdc3): mounted filesystem with ordered data mode. Opts: (null)

with normal riscos-boot.bin

dmesg:
[ 8519.331121] usb 6-1.7: new high-speed USB device number 13 using ehci-pci
[ 8519.425537] usb 6-1.7: New USB device found, idVendor=058f, idProduct=6335
[ 8519.425541] usb 6-1.7: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 8519.425544] usb 6-1.7: Product: Mass Storage Device
[ 8519.425546] usb 6-1.7: Manufacturer: Generic
[ 8519.425548] usb 6-1.7: SerialNumber: 058F011111B1
[ 8519.426076] usb-storage 6-1.7:1.0: USB Mass Storage device detected
[ 8519.426268] scsi host10: usb-storage 6-1.7:1.0
[ 8520.422700] scsi 10:0:0:0: Direct-Access     SD/MMC   Card  Reader     1.00 PQ: 0 ANSI: 0
[ 8520.423117] sd 10:0:0:0: Attached scsi generic sg3 type 0
[ 8520.658325] sd 10:0:0:0: [sdc] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
[ 8520.660444] sd 10:0:0:0: [sdc] Write Protect is off
[ 8520.660449] sd 10:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 8520.662539] sd 10:0:0:0: [sdc] No Caching mode page found
[ 8520.662542] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[ 8520.684070]  sdc: [CUMANA/ADFS] sdc1 [ADFS] sdc1
[ 8520.695176] sd 10:0:0:0: [sdc] Attached SCSI removable disk

[lurch]

This is obviously a bug that I ought to (attempt to) fix, but how critical is it?
Is it only low-priority "this ought to work but it shouldn't", or is it high-priority "this prevents me from doing something that I really need to" ?
(it obviously only affects the NOOBS SD card when inserted into an Ubuntu PC, and has no affect on the Raspberry Pi itself)

[Rafiot]

In my case, it is a very annoying bug: I always setup my Raspberry Pi "offline" because I use them headless and I never have a screen with me.

Last time, I messed up the watchdog config over SSH (the rpi was basically always rebooting). The same kind of problem happened before with the network config. It is usually not a problem because I was expecting to be able to just change the config file from my linux box.

So for now, I don't use NOOBS because being able to just mount the key on linux is a requirement. But I agree that it is a quite specific case and I can simply use dd.

[beta-tester]

ah, it is a bug...
i was already wondering about the position where the RiscOS blob is written. to me it looks it is somewhere inside first partition (without corrupting the filesystem?)

i wouldn't say, it is a critical bug (in case, it will not corrupt the filesystem),
but it would be definitivly above normal.
i do a lot plugging the SD card to a PC to tweak some things, and i always have to remember and use the workaround woth fdisk to see the start of the partitions i want to mount and then mount the partitions with an offset...
indeed that is very annoying.

[maxnet]

i was already wondering about the position where the RiscOS blob is written. to me it looks it is somewhere inside first partition (without corrupting the filesystem?)

It is written right after the MBR in the spare space between the MBR and the first partition.
The proximity to the MBR was the reason the blob is written on initial NOOBS installation only, as a design choice at the time.

The way most flash storage works is that you cannot modify individual bytes.
If you want to write anything to the SD card, it has to read, erase and reprogram a larger block size area.
Wanted to keep writes to the area where the MBR lives to a minimum, to minimize the risk of the MBR getting corrupted, if a write goes wrong.

[lurch]

Thanks to the quirks of the MBR partitioning scheme, after NOOBS has done it's initial first-boot resizing, the MBR itself and the first partition never get modified. It's only files on the SETTINGS partition (mmcblk0p3) and all the logical partitions within the extended partition (mmcblk0p2) that get written to.
So even if a 'bad write' wiped out the entirety of mmcblk0p2 and mmcblk0p3, then NOOBS itself (stored on the mmcblk0p1 RECOVERY partition and never written to) would still be bootable, and allow you to install a fresh OS.

I've not looked into this problem in detail yet, but I wonder if it could be considered a bug that (the kernel used by) Ubuntu is looking for an ADFS partition-table first, and ignoring the completely valid MBR at the start of the disk? I believe if the MBR was read first, it would/should simply skip over the location of the ADFS partition table (aka "RiscOS blob").
...which I guess also explains why fdisk does work - because it looks for the MBR first.

[beta-tester]

yes, i made a mistake by resolving the definition of RISCOS_BLOB_SECTOR_OFFSET
it is indeed not inside in the first partition. it is in the not allocated region between the primary msdos partitiontable and the first partition...

my mistake was taking

#define RISCOS_OFFSET (1760)
#define RISCOS_SECTOR_OFFSET (RISCOS_OFFSET * 2048)

but it is

#define RISCOS_BLOB_SECTOR_OFFSET  (1)

so it will not corrupt the filesystem.

[lurch]

...okay, I think I've managed to track down the 'culprit' ;-)

As already (partially) mentioned, on a post-initial-boot NOOBS card, there's both an MBR partition table at bytes 1-512 inclusive, and an ADFS partition table at bytes 513-10240 inclusive (the 9728 bytes of riscos-boot.bin). Both partition tables are equally valid, with the MBR table describing the 'regular' linux partitions (Raspbian, OSMC, etc. as well as RECOVERY and SETTINGS), and the ADFS table describing the RISCOS partition (regardless of whether it's been installed yet or not). RISCOS doesn't understand MBR partitions, and so it always installs to a fixed location on the SD card.

In older versions of Ubuntu, running

grep ACORN_PARTITION /boot/config-`uname -r`

shows:

# CONFIG_ACORN_PARTITION_CUMANA is not set
# CONFIG_ACORN_PARTITION_ADFS is not set

And therefore the linux kernel ignores the ADFS table, and simply uses the MBR table (and all the regular partitions on your NOOBS card can be seen / mounted).

However in newer versions of Ubuntu, the same grep command shows:

CONFIG_ACORN_PARTITION_CUMANA=y
CONFIG_ACORN_PARTITION_ADFS=y

And as the comment at https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/block/partitions/check.c#n56 explains, the kernel partition-checking code looks for the Acorn partition table before looking for the msdos (MBR) partition table. Hence the cause of the problem as initially reported :-S

As both partition tables are equally valid, and RISCOS is unable to boot without the ADFS partition table, there's nothing that can be done from within NOOBS to fix this. So closing this for now as "wontfix".

However as a workaround you could either recompile your Ubuntu kernel to not include the ADFS / CUMANA options, or you could 'manually zero' the ADFS partition table with:
sudo dd if=/dev/zero of=/dev/sdd bs=512 conv=fsync seek=1 count=19
(replacing /dev/sdd with whatever device your SD card appears as). If you then remove and re-insert the SD card, Ubuntu should display all the regular partitions. Doing this will make RISCOS unbootable on that SD card though, unless you write riscos-boot.bin back to the card with:
sudo dd if=/path/to/riscos-boot.bin of=/dev/sdd bs=512 conv=fsync seek=1
(again replacing /dev/sdd as necessary).

As always, you need to be very careful what you're typing when using dd!

To check what's currently in the "ADFS area" of your SD card, run:
sudo dd if=/dev/sdd bs=512 skip=1 count=19 | md5sum
If it returns a162f87d777e2631927c2ead8ba75cf1 then the area is all-zeroes, if it returns 82a2ce581329b3eec1ba1afab1e11959 then it's a riscos-boot.bin from NOOBS v1.3.4 or earlier, and if it returns 6912dab36d2306dce07fa110fd077ea6 then it's a riscos-boot.bin from NOOBS v1.3.5 or later.

Even though I'm closing this bug, feel free to add additional comments or questions. And if you feel like pointing your forum threads and launchpad bug-report back to here, that'd be great :)

[beta-tester]

ok, no, i understand... then let it be like it is.

i read also that it seems, that adfs/cumana is also in newer updated Debian 8 kernels enabled...
is there an easy way to disable the adfs/cumana module without compiling a new kernel
(e.g. by using a blacklist)?
but unfortunately i did not found the names of these modules, what i have to put to a blacklist.

i know, it is a debian/ubuntu question - but hopefully you can help as well.

... thank you anyhow, for taking time to looking at.

[Rafiot]

CONFIG_ACORN_PARTITION_CUMANA=y
CONFIG_ACORN_PARTITION_ADFS=y

means is is compiled in the kernel, and not as a module, so there is no way you can blacklist it...

Anyway, good to know and to keep this bug as reference as it will avoid some headache to ubuntu/debian users.

[lurch]

Yup, and those config options are both boolean (yes/no) and not tristate (yes/no/module) http://cateee.net/lkddb/web-lkddb/ACORN_PARTITION_CUMANA.html
So a kernel (re)compilation is unfortunately the only way to turn them on or off.

And I also just found this bug-report which has the same symptom, but a different cause.
Heh, even 9 years ago this option was considered 'obsolete' http://debian-arm.debian.narkive.com/VkVbqy8f/disable-config-acorn-partition-cumana-in-debian-kernels
And see also http://lkml.iu.edu/hypermail/linux/kernel/0501.2/0543.html

So goodness knows why Ubuntu has now decided to enable this kernel option by default... :-(

[druvisc]

I wanted to thank you, lurch, for the throughout explanation and workaround. Also, for finding the time to write about it.

But if I may, I would strongly suggest looking into this and perhaps finding a solution to the problem without the use of command line partition byte jumping and partition zeroing which goes way beyond the regular or novice RPi user which NOOBS is aimed for (not even talking about kernel re-compiling). As this seems to me as a very, very common error and I'm sure a lot more people don't even write about it.

I basically tried everything I got my hands on over the night to get it working / figure out the problem, but only this worked (perfectly even). I was now dressed up to go and return the MicroSD card as I came to the conclusion that it's malfunctioned (so I didn't even think to try a different image).

Perhaps the RiscOS partition table is not necessary if it's not chosen to be installed?

[druvisc]

To conclude, this was more than a mouthful as I am trying to make a new kiosk start-up (reinstalled NOOBS 3 times because I wasn't able to fix or uncomment something in the xinitrc file). Right now I'm about to drink some whiskey, because I was up till 6 AM.

[lurch]

Perhaps the RiscOS partition table is not necessary if it's not chosen to be installed?

Technically the RISC OS partition table isn't necessary if RISC OS isn't chosen to be installed; but as @maxnet explained earlier, writing the RISC OS partition table only if the user chooses to install it could risk corrupting the MBR, which is why it's only written to the card once (during the NOOBS first setup), to minimise the risk of "breaking" peoples' NOOBS setups.

I don't want to sound arrogant, but as I explained here IMHO it's a bug that the Linux kernels included by more recent versions of Ubuntu have the Acorn partition-detection options enabled :-/
Which is why I tried to make my explanation and workaround so detailed. I just added a note above, clarifying that writing riscos-boot.bin back to the SD-card is optional if you know you'll never be installing RISC OS.

[lurch]

According to ff40607 NOOBS "now does rewrite the MBR", so presumably SD-corruption concerns are now a thing of the past, and theoretically future versions of NOOBS could be modified to only write the riscos-boot.bin when you choose to install RISC OS?

[maxnet]

theoretically future versions of NOOBS could be modified to only write the riscos-boot.bin when you choose to install RISC OS?

Yes, it would be possible to remove riscos-boot.bin from the NOOBS distribution, and move writing it to the post-installation script instead.

Still not a full solution though, given that this issue would still occur if RiscOS is installed or once was.
Better long term solution would be to teach it to understand normal partitions instead.

[lurch]

Yes, it would be possible to remove riscos-boot.bin from the NOOBS distribution, and move writing it to the post-installation script instead.

It's just occurred to me that that would also allow extra flexibility, and remove the need for code like

noobs/recovery/mainwindow.cpp

Line 365 in bc6dc9e

/* RISC_OS needs a matching riscos_offset */

(becuase the riscos-boot.bin would then be "part of RiscOS" and update-able independently, rather than hard-baked into NOOBS).

Better long term solution would be to teach it to understand normal partitions instead.

I was once told by the RISC OS team that that was indeed on the cards, but I guess that project must have been shelved.

But given what e.g. http://lkml.iu.edu/hypermail/linux/kernel/0501.2/0543.html says, I still find it bonkers that Ubuntu have enabled the CONFIG_ACORN_PARTITION_CUMANA by default.

[maxnet]

It's just occurred to me that that would also allow extra flexibility, and remove the need for code like
https://github.com/raspberrypi/noobs/blob/bc6dc9efe21562deca0de173896aa1abd3194525/recovery/m
ainwindow.cpp#L365 (becuase the riscos-boot.bin would then be "part of RiscOS" and update-able
independently, rather than hard-baked into NOOBS).

Yes.
And can now also specify at which offset a partition should be written in partitions.json.
So should be able to get rid of the Risc OS name checks.

I was once told by the RISC OS team that that was indeed on the cards, but I guess that project must
have been shelved.

There does seems to be a 2.5k bounty for any developer willing to implement it: https://www.riscosopen.org/bounty/polls/10
But apparently so much work, nobody is biting.

[matthuisman]

I think this is causing one of my OS's not to work in NOOBS

NOOBS 1.5
Raspberry Pi 1 B+
Installing RecalBox
Running the below commands on the Pi itself.

uname -r

3.12.26-quick

ls /dev/mmcblk*

/dev/mmcblk0 /dev/mmcblk0p2 /dev/mmcblk0p6
/dev/mmcblk0p1 /dev/mmcblk0p5 /dev/mmcblk0p7

dmesg

[ 1.016044] mmc0: no vqmmc regulator found
[ 1.016062] mmc0: no vmmc regulator found
[ 1.058723] mmc0: SDHCI controller on BCM2708_Arasan [platform] using platform's DMA
[ 1.058929] mmc0: BCM2708 SDHC host at 0x20300000 DMA 2 IRQ 77
[ 1.092762] Waiting for root device /dev/mmcblk0p7...
[ 1.131624] mmc0: read SD Status register (SSR) after 3 attempts
[ 1.139777] mmc0: new high speed SDHC card at address e624
[ 1.140297] mmcblk0: mmc0:e624 SL08G 7.40 GiB
[ 1.143860] mmcblk0: p1 p2 < p5 p6 p7 >
[ 1.199766] EXT4-fs (mmcblk0p7): couldn't mount as ext3 due to feature incompatibilities
[ 1.200565] EXT4-fs (mmcblk0p7): couldn't mount as ext2 due to feature incompatibilities
[ 1.831126] EXT4-fs (mmcblk0p7): recovery complete
[ 1.832975] EXT4-fs (mmcblk0p7): mounted filesystem with ordered data mode. Opts: (null)
[ 1.833073] VFS: Mounted root (ext4 filesystem) on device 179:7.

/etc/fstab

/dev/mmcblk0p7 / ext2 rw,noauto 0 1
/dev/mmcblk0p8 /recalbox/share vfat defaults,rw 0 0
/dev/mmcblk0p6 /boot vfat defaults,rw 0 0

fdisk /dev/mmcblk0 -l

/dev/mmcblk0p1 129 9705 306451 e Win95 FAT16 (LBA)
/dev/mmcblk0p2 9705 242560 7451373 85 Linux extended
/dev/mmcblk0p5 9729 10752 32767 83 Linux
/dev/mmcblk0p6 10753 12672 61439 c Win95 FAT32 (LBA)
/dev/mmcblk0p7 12673 76672 2047999 83 Linux
/dev/mmcblk0p8 76673 242560 5308416 c Win95 FAT32 (LBA)

As you can see, Partion 8 is completely skipped.
This partion is used in the OS (for roms), so the OS doesn't work correctly (no roms)

I need to package it up with NOOBs, so can't ship an image file with the DD "fix" applied.
I tried deleting riscos-boot.bin but still the same problem.

Any ideas on how to fix?

[maxnet]

I think this is causing one of my OS's not to work in NOOBS

Unrelated issue.

uname -r
3.12.26-quick

[ 1.143860] mmcblk0: p1 p2 < p5 p6 p7 >
As you can see, Partion 8 is completely skipped.

Recompile the kernel used by your Linux distribution with a higher CONFIG_MMC_BLOCK_MINORS kernel option to get mmcblk0 devices beyond p7.
Or switch to the standard bcmrpi_defconfig kernel which has 32.

[NicoHood]

Yes I think i have the exact same issue.
It is very annoying since I thought my sd card is broken.

It also came out of nowhere and nobody tells you this. And simple ubuntu users (who decide for the good, not for the worse win10) will have the same problem. And I'd have no idea if lurch did not point me to this issue.

There should be a way to fix this, since even people on the raspi irc did not know about this. And its hard to google such an issue. Since its caused by noobs, but its not obvious.

And for even more confusing I think the other sd card really broke while playing with noobs (too many writes, not caused actually by noobs).

And if you dont fix this, please add a big mark to the readme as "known bug" or so. Please.

[lurch]

Without wanting to get into a 'blame game' IMHO the bug is caused by Ubuntu, not NOOBS.

But yes, as the newer versions of Ubuntu (with their enabled-by-default CONFIG_ACORN_PARTITION_CUMANA kernel option) are clearly only going to get more common, I'll add a note about this to the README at some point.

[lurch]

Re-opening issue to remind myself to update README.md

[NicoHood]

Can't we just blank the risc partition table if it is not used within the installation?
I guess not a lot of people will use risc, so this would at least work around this bug for those who dont use risc.

Edit:
sudo dd if=/dev/zero of=/dev/sdd bs=512 conv=fsync seek=1 count=19 fixed it for me.

[lurch]

Can't we just blank the risc partition table if it is not used within the installation?

Originally we couldn't, because the NOOBS 'prime directive' was to never write to the first partition (or MBR) in order to minimise the risk of data-corruption leading to a non-bootable SD card - see #262 (comment)

But for NOOBS v1.5 this has changed, so it might be possible in future to change this behaviour - see #262 (comment)

[NicoHood]

We should probably also add a bit of offset in the recovery partition (just a few, lets say 16-64mb) to make debugging and further developing easier. A few mb wont hurt anyone.

[lurch]

We should probably also add a bit of offset in the recovery partition (just a few, lets say 16-64mb) to make debugging and further developing easier.

Feel free to do that in your own fork of NOOBS, but that's a feature that won't be added to standard NOOBS. (again, because NOOBS is designed so that nothing ever writes to the first partition)