Some Linux Users Are Reporting Software RAID Issues With ASRock Motherboards

[phoronix]

Phoronix: Some Linux Users Are Reporting Software RAID Issues With ASRock Motherboards

Making the rounds this morning is an ASRock forum post about a motherboard accidentally and repeatedly wiping out Linux Software RAID meta-data. A few Phoronix readers have also reported similar issues such as in the forums and Twitter. This appears to stem from an UEFI issue...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Software-RAID-ASRock

[jpg44]

Perhaps a work around for this to be safe might be to simply place the software RAID data inside a GPT partition therefore it wont try to "correct" anything since there will be a valid GPT there?

This is also another problem with the complex with UEFI is that because of all of the additional code they can throw in their its compulsive to put all of this "intelligence" into it to make it "user friendly" to "i'll just fix this for you", its the same ilk as other stupid "user friendly" things like autorun DVDs and embedded scripts in Word documents, that actually creates problems by doing unexpected things behind peoples backs. A simple traditional BIOS would probably not try to fix a "broken" partition table but would throw an error. The designers of the UEFI assume everyone is going to use Windows with a regular partition, "linux, why should you want to use that, your supposed to be using Windows anyway".

[starshipeleven]

A simple traditional BIOS would probably not try to fix a "broken" partition table but would throw an error.

Pfft, a "simple traditional BIOS".

BIOS was full of crap and "smart" functionality too in its later days. UEFI is bad but BIOS was well into the same way, just more fragmented and NIH as each vendor had its own implementation.

[andreano]

UEFI issue

Lol, to anyone who have seen a talk by Matthew Garrett, there is zero entropy in that conclusion!

[patrakov]

A simple traditional BIOS would probably not try to fix a "broken" partition table but would throw an error.

Let me correct you. A simple traditional BIOS does not understand and does not care about partition tables. So it won't notice anything wrong.

[numacross]

Let me correct you. A simple traditional BIOS does not understand and does not care about partition tables. So it won't notice anything wrong.

Sure they do. Many motherboards featured anti-virus features

I found some random Pentium II ASUS motherboard's manual:

Boot Virus Detection (Enabled)
This field allows you to set boot virus detection, ensuring a virus-free boot sector.This new antivirus solution is unlike native BIOS tools, which offer limited virusprotection typically by write-protecting the partition table. With this new solution,your computer is protected against boot virus threats earlier in the boot cycle, that is,before they have a chance to load into your system. This ensures your computerboots to a clean operating system. The system halts and displays a warning messagewhen it detects a virus. If this occurs, you can either allow the operation to continueor use a virus-free bootable floppy disk to restart and investigate your system. Be-cause of conflicts with new operating systems, for example, during installation ofnew software, you may have to set this to Disabled to prevent write errors.

Edit: Oh and BIOSes even could self-update from a floppy (and USB later on) without the need of running a DOS utility. So they understood filesystems as well

[jabl]

Richard Jones posted on another forum the following:

I suspect what's actually happening here is there was an old GPT partition table on the disk which was not wiped before mdadm -C was run. This means it has a correct primary partition table (with correct CRC etc), and MD RAID has overwritten the secondary PT at the end of the disk.
Unfortunately (and I genuinely hate to be "language lawyering" when someone has lost all their data), the ASRock firmware is doing the right thing according to the letter of the UEFI spec -- see section 5.3.2 of http://www.uefi.org/sites/default/files/resources/UEFI%20Spe... :

> If the primary GPT is invalid, the backup GPT is used instead and it is located on the last logical block on the disk. If the backup GPT is valid it must be used to restore the primary GPT. If the primary GPT is valid and the backup GPT is invalid software must restore the backup GPT.

Good time to promote my videos visualizing how GPT and Linux RAID work :-) I did some cool live visualizations of mdadm, mkfs.ext4, gdisk, injecting errors etc. https://rwmj.wordpress.com/2018/11/26/nbdkit-fosdem-test-pre... https://rwmj.wordpress.com/2018/11/06/nbd-graphical-viewer-r...

So the simple solution is to just create a single partition spanning the entire disk, then use that for mdadm, rather than using the raw device directly.

[starshipeleven]

Let me correct you. A simple traditional BIOS does not understand and does not care about partition tables. So it won't notice anything wrong.

As I said above, "simple traditional BIOS" weren't all that common well before UEFI was on the horizon.

And there is nothing anywhere in UEFI spec that says the board firmware has to go and try to fix anything either, this is entirely within the OEM's decisional power.

[starshipeleven]

Richard Jones posted on another forum the following:
So the simple solution is to just create a single partition spanning the entire disk, then use that for mdadm, rather than using the raw device directly.

Is using a partition instead of raw device worse in any way (apart from losing a handfew of MB due to partition table and stuff)?

I never really understood why you would want to use a raw device in real hardware (It's useful if you are doing this inside a file mounted as a loop device or something).

[jabl]

Is using a partition instead of raw device worse in any way (apart from losing a handfew of MB due to partition table and stuff)?

AFAICT no. Or, of course you could always cook up some hypothetical scenario where some buggy tool tries to read the partition information and instead scribbles junk all over you disk.

But realistically, overwhelmingly more likely is that you mistakenly destroy your data because some tool you used didn't find a valid partition table and thus you assumed the disk to be empty. Or as in this case, the firmware thinks that you have a broken partition and fixes it for you (if Richard Jones's explanation is correct).

I never really understood why you would want to use a raw device in real hardware (It's useful if you are doing this inside a file mounted as a loop device or something).

Well, if you're, say, some enterprise vendor producing some storage appliance and you only use disks with your own firmware, then I guess you could as well use raw disks. But even so, it's not like there's any harm if you have a partition table anyway.

But for end users, IMHO if I have a choice between using a raw disk or partitioning it, I'd choose partitioning every time, just to reduce the risk of accidentally destroying my data. But yes, files mounted via loopback etc. can be a valid usecase for a raw "device".