installer allows /boot to be on a raid or LV volume, which grub doesn't support

the preseed file used with this kernel line:

label ubuntu-testing-hands-off
# ubuntu instaler
        kernel ubuntu/dapper/install/netboot/ubuntu-installer/i386/linux
        append initrd=sc/bzy/initrd.gz ramdisk_size=16098 root=/dev/rd/0 rw debian-installer/locale=en_US kconsole-keymaps-at/keymap=us kbd-chooser/method=us netcfg/wireless_wep= netcfg/get_hostname= preseed/url=http://shaz/preseed-testing.cfg DEBCONF_DEBUG=5 --

tail -n 500 /var/log/syslog > nogrub.syslog.tail

It couldn't figure out how to boot /dev/discs/disc1/part1 (it identified /dev/sda1 as the corresponding /boot partition, but then couldn't mount it), and so asked grub-installer/bootdev; you'll need to preseed that (to e.g. "(hd0)" for the MBR on the first disk) to make this install proceed noninteractively.

If /dev/sda1 is trashed (e.g. by the current install), then we're done with this bug. If the installer *should* still have been able to mount it, then there's still a bug somewhere, and I'd like to know more about your partition layout.

I tried a few times to repoduce this and couldn't.

repo, but not using the preseed file. I did the partition by hand in what I consider a resonable setup: swap and raid for /

> If /dev/sda1 is trashed (e.g. by the current install), then we're done with this bug.

Wondering about that - /boot was part of /dev/md0
which is currently mounted:

# mount

/dev/md/0 on /target type ext3 (rw,data=ordered)

# cat /target/etc/fstab

# <file system> <mount point> <type> <options> <dump> <pass>

proc /proc proc defaults 0 0

/dev/md0 / ext3 defaults,errors=remount-ro 0 1

/dev/sda1 none swap sw 0 0

# fdisk -l

/dev/sda1 1 62 497983+ 82 Linux swap / Solaris

/dev/sda2 63 1169 8891977+ fd Linux raid autodetect

/dev/sdb1 1 8678 8886256 fd Linux raid autodetect

whoops, never finished my question: why does anything need to mount sda1 if grub is being installed on sda ?

fdisk -l

fstab

partman

syslog

This is a separate bug - it looks like it just can't handle GRUB being installed with /boot on RAID, which I think we've known about for a while.

To see what can/cant be done, I am trying to run grub from the installer's VT2 shell, but the only copy of grub I could find:

/target/sbin/grub: error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory

Seems like being able to run grub would be a good idea.

I looked over /usr/bin/grub-installer and couldn't figure out how it actually installed grub.

Is there something I can anna-install to get me good ol' gurb?

No, there's no need for a grub udeb. 'chroot /target' and then you can run grub all you like ...

I think the bug here is that the installer allows /boot to be on a raid or LV volume, which grub doesn't support (based on: http://grub.enbug.org/TodoList Add support for software RAID. Add support for LVM)

I think the installer should reject or at least warn against it.

There are some exceptions:
2 partitions (example: hda1 and hdb1) raid1 (mirror) – grub can use one copy of the mirror (hda1) to boot from, and then the kernel will mount /boot on md0. This 'works' but isn't really 'working' because if hda1 fails, the box won't boot because grub isn't making use of the redundant copy. OTOH, the hdb1 copy would still be intact and could be used to manually rebuild hda1. No clue if the installer could create this setup. I think if someone wants it, they should use the installer to create /boot on hda1, nothing on hdb1 and create the raid post install.

looking over the "some exceptions" - It is kinda nice that it will help setup / on md0, even if /boot and grub arn't doing raid yet. also, I saw that grub was patched with something relating to raid. It may be that grub will do raid1 after all. I could not figure out what the patch was.

This looks related to bug 32775.

I've checked the GRUB to-do list and RAID and LVM still are listed there.

Please, could you confirm that this is still happening with latest Dapper
updates? Tried on Edgy, maybe?

> I've checked the GRUB to-do list and RAID and LVM still are listed there.

but there is also a patch applied against the grub Ubuntu uses - which seems related to raid, but I couldn't figure out how.

I'll do an edgy test in a few days.

Carl, did you test this issue on Edgy?

Thanks!

Carl, a couple of months ago you said you were going to test this issue in Edgy. Did you had the chance?

It works booting on a raid /boot partition, but only RAID1. (tested on edgy)

Recently, I installed a couple of servers with /boot on raid1; one runs Feisty server and the other one LTS server. Both installations worked fine.

The only problem I found was that I had to redo the "mount /dev/md0 in /boot as ext3" steps every time I finished a change on the LVM setup over the other /dev/md1 and /dev/md2 raids (however, this could be another bug or a documented feature I didn't notice on the LVM dialogs.) I tried several times before I came up with this "problem" and one of those times, the installer ended up installing LILO in /boot instead of GRUB.

Just double-check your partition layout if you setup LVM after assigning RAID devices a mount point and filesystem type.

HTH

[Expired for debian-installer (Ubuntu) because there has been no activity for 60 days.]

The /boot on RAID aspect of this bug has been fixed in Ubuntu Intrepid. I have tested and verified this extensively.

:-Dustin

I also tested /boot on an LVM logical volume in Ubuntu Intrepid, and it worked fine as well, although the LiLo bootloader needed to be used.

Perhaps another bug exists (or should be opened) specifically requesting grub support for /boot-on-LVM.

I'm going to close this one as 'Fix Released' for now. Please re-open if you still experience this problem in Intrepid.

:-Dustin