A start job is running for dev-mapper-centos\x2droot.device

[rohan7]

So I just restarted my server and it does not boot into CentOS any more. When I press esc I see the below message,


I tried to edit the boot options using

Code: Select all

systemd.unit=rescue.target

during GRUB boot screen but the machine does not boot into rescue mode. I tried other kernel versions from the GRUB boot screen but I get the same error as above. However, I can only get into the emergency mode (not rescue mode) using 6th options from below,



Below is the boot options from GRUB boot screen and I cannot see

Code: Select all

systemd.unit=rescue.target

anymore when reboot (physically) the server.



How do I fix this issue please?

[TrevorH]

So you can boot the rescue kernel ok?

Given the age of the rest of the kernels in your list it is apparent that you do not run yum update often enough. The 3.10.0-514 series of kernels belongs to CentOS 7.3 which came out in Nov 2016 - over 3 years ago.

I would recommend that you boot the rescue kernel and run yum update ASAP to not only get up to date with the missing 3 years of security patches but also to install a new kernel which will in turn build a new initramfs file tailored for the current hardware configuration of your machine. Then you can reboot into the new kernel and have a system that is at least up to date!

[rohan7]

Using the rescue kernel, the system gets booted into emergency mode rather than rescue mode and I cannot run yum update and yum cannot be found.

Please see screenshot below of the emergency mode,

[rohan7]

Is there any hope in getting the server up and running? Anything I can do to fix this please?

[tunk]

Does fdisk -l and blkid show anything?

[rohan7]

Code: Select all

dracut:/# fdisk
sh: fdisk: command not found

Code: Select all

dracut:/# blkid
/dev/sda: TYPE="isw_raid_member"
/dev/sdb: TYPE="isw_raid_member"

[rohan7]

Within the emergency mode, I cannot see fstab within etc. I am not sure but is this normal?

[TrevorH]

/dev/sda: TYPE="isw_raid_member"
/dev/sdb: TYPE="isw_raid_member"

Oh, FakeRAID

[rohan7]

uhm, sorry Trevor, not sure what that means. Is the issue related to RAID?

[TrevorH]

What it means for me is that FakeRAID is rubbish and breaks at random times with exactly this sort of error. Last time I saw something like this, someone had had to rebuild the array and as part of that it helpfully renamed the array name that was buried in /etc/fstab and thus despite it being exactly the same RAID array, only rebuilt by replacing *one* disk, it renamed the entire array and made it look like a completely different one.

Sorry, but I don't know enough about FakeRAID to help you more. If this was my system I would back up all data, disable FakeRAID, remove the FakeRAID metadata from all the disks and then set up the entire system from scratch again using Linux software RAID instead then restore your data.