I am installing openSUSE on an HP Proliant ML350 G5. It has the Compaq E200i disk controller in it. The SATA disks are configured as a RAID 5.
I am installing from the DVD and everything goes as normal (I have two partitions, / & swap) when I get to the part where it installs the boot loader it (GRUB) blows up with error 15 file not found. I have tried the boot loader options of installing to /, /boot or MBR but get the same error every time. I have verified that the / partition is c0d0p1 as it suggests - / is c0d0p1 & swap is c0d0p2. I am stuck, any suggestions?
So apparently the array (I presume this is hardware raid) is being recognized by the installer, it can be partitioned, and the partition can be mounted. So the problem must be in grub seeing the array.
We can try to get this working as you’ve set up, but there may be an easier fix: With this controller, is the array at the disk level or the partitions level? If the latter, can you create a non-raid partition and put /boot only on it?
GRUB can’t support RAID 5, as it needs to use BIOS calls to load the boot loader 2nd stage that reads the filesystem on disk and load kernel and initrd. So creating a small RAID 1 ext2 filesystem is the best way to handle /boot.
Hi, I am a bit out of my depth here but I have an existing Suse 10.0 system installed on a RAID 5 (Megaraid SCSI) array and it works OK. Is this because I have only one partition other than swap?
I ask because I have just resized this partition to make room for a new partition for installation of Opensuse 11.1. Unfortunately I am now stuck because I have no idea how to modify existing Grub so I can install the new system and boot it.
Any light you can shine on this would be much appreciated.
Take a look at /etc/grub.conf. That is the scriptlet that is fed by YaST to the grub shell for installation; it will tell you where stage1 was installed and where its pointer expects to find stage2 (i.e., where /boot is located). You can also take a look at the MBR and root partition boot sectors to see if stage1 is there.
Far be it from me to disagree with @robopensuse, and some time ago I also thought grub could not be used with such a RAID setup as yours. However, now I’m not sure. Grub apparently can be installed using a fakeraid software raid; apparently the kernel can see some of these arrays through the bios firmware extension and will use dmraid and mapper to create a block device that can be used in grub’s device.map and grub can be installed. Perhaps that is because such a grub installation has the kernel to help it; the grub manual in fact discusses that the grub shell (which does the install) will read the hardware differently running under the OS as opposed to running standalone (e.g., from a grub floppy). But at boot time for grub stage1 to find stage2 on a striped array, since stage1 has no OS raid driver to assist it, for that to work grub must have been enhanced to see the array via its bios firmware. With a true hardware array such as yours, I would think the possibility of grub working would be much greater even with a striped array, as the bios sees the array as a single device via the hardware controller. As long as grub sees this device from the bios, it may be able to access it. Clearly I don’t have a definitive answer. Perhaps when you do, you could post back your findings for our edification.
You are correct in your assumptions, the raid array is hardware based. The installer sees the array fine and I create the partitions I want and then the installer proceeds to copy OS files. GRUB install is one of the last steps of the installer. I remember booting to the rescue system from the install disk and used expert tools to try and re-do the GRUB install. I went to edit GRUB and tried to browse to the files in /boot and it showed an empty /boot directory. This would support the theory that GRUB cannot see the array in the same manner as the installer can.
I think I am going to try the theory that GRUB cannot handle the RAID5 by creating a separate partition and see what happens. I will see if I can get this done tonight and then post the results. I would prefer to keep the configuration simple and just partition the RAID5 array. I will post some screen shots too maybe.
I guess I can’t post a screenshot? I broke the RAID 5 array and started a fresh install to a single disk. I did not have enough time to watch the install through to the end to see if the GRUB install worked, but will later today.
The original GRUB error when installing to the RAID5 array is:
setup --stage2=/boot/grub/stage2 --force-lba (hd0,0) (hd0,0)
Checking if “/boot/grub/stage1” exists… no
Checking if “/grub/stage1” exists… no
Not as much help as you suggest. just 2 entries:-
setup --stage2=/boot/grub/stage2 (hd,0) (hd0,1)
setup --stage2=/boot/grub/stage2 (hdo,1) (hd0,1)
No mention of stage 1 which does however appear in /boot/grub along with various variants *stage1.5.
How can I check whether grub is in mbr or not. By the way the drive is hardware RAID so I assume BIOS sees it as single drive with mbr as though it were a single disk.
Au contraire. The grub setup command is actually a macro for the grub install command, and with both the primary file being used is stage1. In the syntax above - which you mis-typed so I can’t be positive exactly what was done - stage1 was installed twice, once to “(hd,0)” which could be the first partition’s boot sector (i.e., (hd0,0)) or the MBR ((hd0)). Secondly installed to “(hdo,1)” which appears to be (hd0,1), i.e., the boot sector of the second partition on the first disk. I would therefore guess that the first setup line was (hd0,0), the matching partition in the array (?). Both stage1’s are pointed to the same location to find the grub stage2 loader, i.e., the /boot directory on (hd0,1).
Stage_1.5 files are typically used when grub is installed to the MBR. Stage1 cannot read a file system, and so will not be able to find stage2 on its designated partition (that partition has its location embedded as a pointer into stage1 at installation, so the partition can be found but not read). The sectors immediately following the MBR are typically vacant; this is where stage_1.5 will be put. So stage1 in the MBR calls stage_1.5 (the shell will have chosen the applicable 1.5 to match stage2’s file system). When grub is installed to a partition boot sector, stage_1.5 is not needed because the location of stage2 is in the sector’s bios partition block enabling stage1 to find it without help.
To look at the contents of the MBR, from the command line as root (being extremely careful, a typo can be disastrous here):
dd if=/dev/<disk> of=mbr bs=512 count=1
xxd mbr
Where <disk> is the name of the disk, e.g., sda (note: not a partition like sda1, but the whole disk, as the MBR is in the first sector of the disk before any partitions, which typically begin at sector 63).
I re-created my RAID 5 array but took the option under “Maximum boot partition” “Enable 8GB Maximum.” Suse installed without issue and sailed through the GRUB portion without hiccup or delay. My RAID 5 array consists of 6 - 500G SATA disks.
Thanks to all that provided feedback. I will definitely use the forums on opensuse again, great place for knowledge sharing. I am going to setup Xen next and build some VMs. Onward and upward!
Fascinating. So the “8GB maximum boot partition” setting was in the utility that creates the array? That would effectively eliminate the need for LBA, i.e., CHS geometries are used. Does this mean that the boot sector and boot files are isolated to one of the disks rather than being striped?