I tried recently with grub2 and also the old grub in lenny (even the lenny installer fails, though it seems to complete fine, it just don't boot afterwards). didn't think I would get an issue trying to get /boot on my lvm2 raid6 volume, as i recalled grub supported mdadm raids and also lvm2. seems it has to be partitioned separately as a partition with mdadm and no lvm2 on top of the boot partition, thats the only thing grub supports, if I am not mistaken? I just made one big volume, then created the logical volume /boot , and neither grub or lilo would touch it (lilo only supports mdadm raid1 volumes) would be cool to be able to boot lvm2 /boot volumes with grub just wanted to give my recent experience with grub+lvm2+mdadm raid6. /Michael Ole Olsen On Wed, 29 Apr 2009, Daniel Reurich wrote: > On Tue, 2009-04-28 at 17:04 -0700, H. Peter Anvin wrote: > > Daniel Reurich wrote: > > > > > >> For this to be reliable, there is only one sensible configuration, which > > >> is for /boot to be a RAID-1, which is better handled by -- guess what -- > > >> partitioning systems; and we already have quite a few of those that work > > >> just fine, thank you. Otherwise there WILL be configurations -- caused > > >> by controller failures if nothing else -- that simply will not boot even > > >> though the system is otherwise functional. Promoting this kind of stuff > > >> is criminally stupid. > > > > > > I disagree. Grub is quite capable of booting from and assembling a > > > raid5 volume and accessing it's partitions contents, even if the array > > > is degraded. All I'm asking for is that the first 64 kbytes of the disk > > > be reserved and some of it possibly (but not necessarily) replicated so > > > that a bootloader capable of assembling a raid array can be installed on > > > the start of each member disk so that whatever disk the bios decides to > > > boot from, it will always boot. > > > > > > > Grub is capable of doing that IF THE FIRMWARE CAN REACH IT. > > Well if the firmware can't find one if the disks, then it doesn't matter > what scheme we have. Even a single disk won't work. > > > > You seem to have the happy notion that this is something typical, which > > frequently isn't the case. > > I'd say it's typical of 100% of pc's, mac's and just about anything else > that boots of a harddisk without a hardware raid controller. > > > > What's worse, you're clearly of the opinion that this is something that > > should be promoted to users, which is the "criminal" part of "criminally > > stupid." > > I'd like it for me, and to prove it can be done and is a cleaner and > less administratively intensive way of doing it then teaching the > OS/user how to partition a disk and add each partition to into their > respective raid array each time they need to replace or add a new disk > to their array(s). > > Whether this proves reliable and stable enough to be promoted to users > can only be seen once it's proven (or not). > > What's your beef. MD already reserve some space for the superblock, and > write-intent bitmap (which I believe is also replicated across the > member disks), so why not add some space to this to make it possible for > a bootloader as well. > > > -- > Daniel Reurich > > Centurion Computer Technology (2005) Ltd > Ph 021 797 722 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html