So there you are, helping a customer out with a problem. They’ve just added in a replacement OS disk using your process. At the end of the process is a bit of … well … an insurance procedure. Make sure grub is correctly on each drive in the RAID1.
The grub.conf file has
kernel .... root=/dev/md0 ...
Makes sense, right? Cause hd0 enumerates to the first bios drive used for booting in the boot list.
only … …
… it …
… … doesn’t
You see, Linux casually ignores the BIOS when it wants to. Seriously doesn’t pay attention to silly things like drive order. Man, we are Linux dammit, we don’t need no steen keen guidance on drive ordering. We’ll do it our own damn selves!
In the grub session. Use whats in grub.conf (or menu.lst if you prefer).
Yes, thats right … the grub.conf/menu.lst works fine for boot time … but should you want to make sure you lay down the right data at the right place to, I dunno … boot ? … you might suddenly find … it sort kinda doesn’t work.
Since the drives have been reordered by the OS, well, guess what … they are now something like sde and sdf. Which would be hd4,hd5.
So you run something you know should not work.
and the thing works.
This isn’t a grub issue. Grub’s got issues. This just isn’t one of them.
This is very much a linux drive enumeration issue.
As good as the OS is, sometimes this stuff drives you bonkers. Especially when you have an exasperated customer emailing you in a ticket saying “your instructions don’t work”.
Viewed 43926 times by 4829 viewers