SLES 11 SP3 can't install grub on software raid

Hi,

I am trying to install grub with the following layout but I couldn’t manage to get it working.
/dev/sda
/dev/sda1 RAID partition

/dev/sdb
/dev/sdb1 RAID partition

/dev/md0 (RAID 1 /dev/sda1 /dev/sdb1)
/dev/md0p1 swap
/dev/md0p2 /

It keeps saying:

[CODE]grub> setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,1)

Error 22: No such partition[/CODE]

The /boot/grub/device.map contains only mapping for sda and sdb.

Any idea?

Thanks

Hi ic3cat,

as grub runs pre-boot, it cannot access the md devices, but will always have to deal with the physicals.

The way you set up things makes it difficult to handle the situation pre-boot: You have created a “container partition” (/dev/sd[ab]1) that contains its own sub-partitioning. I had set up software RAID1 some year ago on opensuse and went a different path: You might want to consider to partition /dev/sd[ab] according to your needs and create MDs per partition (i.e. /dev/sd[ab]1 → md0 ("/boot"); /dev/sd[ab]2 → md1 (swap); /dev/sd[ab]3 → md2 ("/")). That way grub can access /dev/sd[ab]1 during boot.

Something I had to set up manually was a boot order that first tried to boot from /dev/sda, then from /dev/sdb. Both disks needed the proper setup so that if the first disk fails, the second is used by the BIOS instead (if you had your boot sector only on /dev/sda, it wouldn’t be of much use if sda fails :D) and grub itself needs to be configured accordingly as well. If I recall correctly, grub’s setup had to be changed to handle both disks when “installing” grub, too.

Regards,
Jens

As you’re running RAID1, this should be no problem though. I had done so once on opensuse, about two years ago, so I cannot tell about current SLES systems. I’ll have to check if I can access that setup on some backup and will let you know. A major point was to manually modify grub’s boot sequence to first try to boot from /dev/sda1 (in your case)

Hi,

Thanks for you answer. This setup is working with debian so I thought to continue with it. I can resize partitions without many troubles.

Would it be an option to create a /dev/sda1 /dev/sdb1 for /boot and /dev/sda2 and /dev/sdb2 for RAID?

Thanks,
Oriol

Hi Oriol,

[QUOTE=ic3cat;17834]Hi,

Thanks for you answer. This setup is working with debian so I thought to continue with it. I can resize partitions without many troubles.[/QUOTE]

strange - I’d have expected any Linux distro to have trouble with that type of nested partitioning. Something new to learn every day :slight_smile:

I don’t see any advantage for that type of setup, especially as you’d have to manually sync the content of /dev/sda1 and /dev/sdb1 (you cannot mount both as /boot at the same time and kernel updates would only apply to the partition mounted as /boot at the time of update - using a RAID1 across these two would take care of that problem). And it the end, the question is how you’d want to use the RAIDed partition.

Ah, maybe I mis-understood: You can have two partitions per disk, RAID each on them and use /dev/md0 (sda1, sda2) as /boot and /dev/md1 (sda2, sdb2) as a disk device that you’ll partition again. In other words, use your original setup, but with a separate (RAIDed) partition for /boot. To make that work, the initrd code will have to be able to see the partitions on /dev/md1 after setting up the RAID - it’s worth a test, though I wouldn’t want to bet on it.

From my point of view I’d try to avoid creating software RAID for anything that is used before initrd has completed and has handed control to the /etc/init.d scripts. In my eyes it makes things confusing and complicates the boot process. Of course, this is only my personal opinion.

Regards,
Jens

jmozdzen wrote:
[color=blue]

From my point of view I’d try to avoid creating software RAID for
anything that is used before initrd has completed and has handed
control to the /etc/init.d scripts.[/color]

To ensure initrd has md support can you not circumvent that issue with:
[/CODE]
mkinitrd -f “md”
[/CODE]

I know this can be done in SLES11-SP3.

Also, one must consider what support is provided in the system BIOS. If
the BIOS only supports booting from drive 0, having a separate copy of
grub on drive 1 doesn’t provide the expected redundancy.

I have configured software RAID-1 using /dev/sd[ab]1–>mdo. I know
SLES11-SP3 allows md devices to be partitioned but I haven’t tried it.


Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Hi Kevin,

[QUOTE=KBOYLE;17840]jmozdzen wrote:
[COLOR=blue]

From my point of view I’d try to avoid creating software RAID for
anything that is used before initrd has completed and has handed
control to the /etc/init.d scripts.[/COLOR]

To ensure initrd has md support can you not circumvent that issue with:
[/CODE]
mkinitrd -f “md”
[/CODE]

I know this can be done in SLES11-SP3.[/QUOTE]

while your suggestion is definitely correct (and will add the md feature to initrd if not handled automatically), I’m unsure if the partitions from the newly created md device will be made available to the system during the initrd phase. Partitions on physical devices have their distinct (and, in terms of initrd /dev entries) pre-allocated device files, while the md sub-partition files are created dynamically. It might be udev that creates those links, and initrd wouldn’t have that running, IMO.

Regards,
Jens

jmozdzen wrote:
[color=blue]

I’m unsure if the partitions from the
newly created md device will be made available to the system during
the initrd phase.[/color]

I see your point.

All features have their limitations. The only way to know for sure may
be to actually test it. :slight_smile:


Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…

Finally I have it working. I created a /dev/md0 with /dev/sda1 and /dev/sdb1 which contains the /boot.

ic3cat wrote:
[color=blue]

Finally I have it working. I created a /dev/md0 with /dev/sda1 and
/dev/sdb1 which contains the /boot.[/color]

I glad you found a workaround but I have a couple of questions to help
me better understand what the issue was.

This was your initial configuration:
[color=blue]

/dev/md0 (RAID 1 /dev/sda1 /dev/sdb1)
/dev/md0p1 swap
/dev/md0p2 /[/color]

How large is…
/dev/sda1:
/dev/md0p2:

When partitioning a large disk it is sometimes necessary to create a
separate /boot partition if the / partition extends beyond 1024
cylinders. I imagine the same restriction applies if you partition
/dev/md0.

Did you, by chance, try to create a separate partition (/dev/md0pX) for
/boot? I’m curious whether the issue was due to the size of your /
partition or if SLES simply cannot boot from a partitioned md0 device.


Kevin Boyle - Knowledge Partner
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…