On Wednesday, December 5, 2018 8:07:02 PM PST Gordon Messmer wrote:
I used my test system to test RAID failures. It has a two-disk RAID1 mirror. I pulled one drive, waited for the kernel to acknowledge the missing drive, and then rebooted. The system started up normally with just one disk (which was originally sdb).
my procedure was to shutdown with the system "whole" - both drives working. Then, while dark, removing either disk and then starting up the server. Regardless of which drive I tried to boot on, the failure was consistent.
The thing that stands out as odd, to me, is that your kernel command line includes "root=UUID=1b0d6168-50f1-4ceb-b6ac-85e55206e2d4" but that UUID doesn't appear anywhere in the blkid output. It should, as far as I know.
Except that UUID exists when both drives are present. And this, even though under an earlier CentOS version, it booted fine on either drive singly with the above procedure before doing a yum update. And to clarify my procedure:
1) Set up system with 7.3, RAID1 bare partitions. 2) Wait for mdstat sync to finish. 3) Shutdown system 4) Remove either drive 5) system boots fine 6) Resync drives 7) yum update -y to 7.6 8) shutdown system. 9) remove either drive 10) bad putty tat.
Your root filesystem is in a RAID1 device that includes sda2 as a member. Its UUID is listed as an rd.md.uuid option on the command line so it should be assembled (incomplete) during boot. But I think your kernel command line should include "root=UUID=f127cce4-82f6-fa86-6bc5-2c6b8e3f8e7a" and not "root=UUID=1b0d6168-50f1-4ceb-b6ac-85e55206e2d4"
Unfortunately, I have used this same system for other tests and no longer have these UUIDs to test further. However, I can reproduce the problem to test further as soon as I have something to test.
I'm going to see if using EXT4 as the file system has any effect.