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
