On 10/23/2020 10:07 AM, Chris Adams wrote:
> Once upon a time, Simon Matter <simon.matter@xxxxxxxxx> 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?
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
