CentOS - Nov 2020 - ThinkStation with BIOS RAID and disk error messages in gparted

Once upon a time, Simon Matter <simon.matter at invoca.ch>
said:
> I'm a bit confused what you have here. Did you mix pseudo hardware RAID
> (BIOS RAID 0) with software RAID here? Because /dev/md126 clearly is part
> of a software RAID.
IIRC the old dmraid support for motherboard RAID has been phased out,
but mdraid has grown support for Intel (and maybe some other?) common
motherboard RAID.  So, /dev/md<foo> doesn't inherently mean
"Linux
software RAID" for a while now.
-- 
Chris Adams <linux at cmadams.net>

On 10/23/2020 10:07 AM, Chris Adams wrote:
> Once upon a time, Simon Matter <simon.matter at invoca.ch> said:
>> I'm a bit confused what you have here. Did you mix pseudo hardware
RAID
>> (BIOS RAID 0) with software RAID here? Because /dev/md126 clearly is
part
>> of a software RAID.
> IIRC the old dmraid support for motherboard RAID has been phased out,
> but mdraid has grown support for Intel (and maybe some other?) common
> motherboard RAID.  So, /dev/md<foo> doesn't inherently mean
"Linux
> software RAID" for a while now.
Today LibreOffice locked my computer solid and I had to cycle power to start up
again. Unfortunately it failed booting and I ended up in the dracut shell with
which I am wholly unfamiliar... Although this could be considered a learning
experience it is one I could have been without since I was also running a long
job that had already run for 10 days and needed another four days to complete...

Anyway, after googling and fiddling around I think I identified the culprit as
the command line in grub menu. I have a ThinkStation where two identical SSDs
are configured as RAID in BIOS (see above) and the grub command line has two
rd.md.uuid= statements with the UUIDs of the two disks, further complicated by
the fact that the disk is encrypted.

After fiddling I discovered that if I removed the rd.md.uuid= statements in the
grub command line and replaced it with one single rd.md.=0, I could boot.
However, it seems that only one of the disks is decrypted and used, not the
second one. I also tried rd.md.auto with the same outcome as with rd.md=0.

I was not able to boot any of the three older kernels, nor the rescue option,
they all failed for the same reason.

Does anyone have a suggestion on how I can modify the grub boot option so that:
(1) the system will boot /and/ (2) use the two identical SSDs as the BIOS RAID
as it did before this happened?