No way to keep fall-back kernel option in menu.lst for RAID1

[Timothy Miller]

See this web page for a howto on RAID.

http://www.linuxsa.org.au/mailing-list/2003-07/1270.html

I'm using RAID1, and I'd like to boot from the secondary disk if the first one is dead. To do that, you need to add another entry to the list for the kernel that replaces (hd0,0) with (hd1,0), and put "fallback 1" in /boot/grub/menu.lst.

Unfortunately, one is inclined to place this additional kernel entry into the auto-generated section of menu.lst. Whenever there is a kernel upgrade, that whole section is wiped out, taking the fallback entry along with it. As an alternative, if you put the fallback kernel outside of the auto-generated section, then either it's the first entry (and you have to make 1 the default), or it's the last entry, and the number changes every time you upgrade a kernel. Either way, it gets messy, and it's something that should definitely be automatically handled by the upgrade process. Moreover, there needs to be recovery entries for the secondary drive as well.

This is a serious problem, because it makes it difficult to impossible to maintain a correct RAID1 setup with Ubuntu if the RAID1 is the boot drive(s).

[Leadpumper (jurrie)]

I't been two years and this bug is still marked "new". Is there any progress on this issue?

[zoredache (francyci)]

I don't have a fix, but as a work-around you could prevent the menu.lst from being broken by adjusting the values the post*_hook lines in your /etc/kernel-image.conf which will prevent update-grub from running. You could also put the linux-image packages on hold. Then you only update the kernel manually, and you must remember to fix your menu.lst.

I don't know if it makes sense to try to make update-grub do anything about this. I suspect that most people really needing the high availability have a hardware-based RAID controller.

If you need raid on the boot drive and you don't have hardware RAID, then you may need to accept either holding the kernel, disabling automatic updating of the menu.lst, or simply accepting that you would need to visit the console and manually select something of the grub menu if one of your drive fails. After all, if you don't have a hardware-based raid, and the default drive fails aren't you going to have to go to console anyway to select select the other drive in the cmos settings to boot from?

[Phillip Susi (psusi)]

Grub legacy is no longer being developed, so this new feature will not be added. You should note that grub2 will automatically fall back to the working disk if one fails in a raid1, without the need for a specific menu entry, so you should consider upgrading.