Iam not sure why this is happening neither the hostnode or VM changed. All I did was reboot the hostnode and startup the Centos VM again, also note it happened with the original kernel on the VM and also the latest 6.9 kernel as of this writing as shown below.
Host Node: Centos 6.9
Same result in any kernel above........
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
But if you do:
it does work, I think hd0/sda had a GPT partition that was not removed properly (what I did was just dd bs=512 count=1 the partition table from another drive since the partition table should be identical).
Checking if "/boot/grub/........
In this example we have 2 drives in a RAID array and /dev/sdb is the one that failed. /dev/sda1 is also the /boot partition which we tell grub to install on /dev/sdb eg install root (hd0,0) /dev/sda1 on the new drive /dev/sdb (hd1)
First copy the partition table from /dev/sda to /dev/sdb
dd if=/dev/sda of=/dev/sdb bs=512 count=1
Run partprobe to detect the new partition table
I dread updating the kernel and rebooting to find the Ubuntu graphics aren't working and you have to manually intervene. This is usually because Ubuntu for whatever reason didn't update the drivers you need (eg. the manually compiled Nvidia Kernel driver that MUST be recompiled for each and every kernel update unfortunately).
The most common reason may be that "linux-source" hasn't been installed automatically on my system. I tried to manually reinstall the........
This doesn't seem to be widely known (maybe it's in some documentation that none of us read though)but there's an easy way to check the integrity of any mdadm array:
sudo echo check > /sys/block/md0/md/sync_action
-bash: /sys/block/md0/md/sync_action: Permission denied
sudo will never work, this only works as root since echo is not actually a binary/command. It is built-into bash.