Re: md extension to support booting from raid whole disks.

[Michal Soltys <soltys@ziu.info>]

> John Robinson wrote:
>> Which still has the same problems as the raid5. How to handle the
>> bootloader. Say I have a raid1 over sda/b with lvm on it. How do I
>> boot that? How do I get the bootloader cloned to a new spare disk when
>> it gets added?
> 

Btw - if you have _only_ raid1 on the drives, then you can also set up
partitionable md raid1 with its superblock at the end of the device. 
Thus -  linux raid will cover _whole_ disk, while remaining capable of 
booting with /boot partition in a typical way if /boot was raid1 over 
sd[abc..]1

As for booting itself - the key thing is to have "tiny" /boot partition
_with_ simple well understood and supported filesystem (such as fat,
ext2) at the beginning - outside of lvm or more complex raids. Such a
partition can have - apart from linux kernel+initramfs - bootable
freedos or linux, and host some good bootloader/manager (such
as syslinux, which is far more powerful and flexible than grub).

If /boot is created inside some container (lvm, raid5) and/or as a part 
of other filesystem - then it only ties hands, imho.

>> On Fri, May 1, 2009 at 2:04 PM, Goswin von Brederlow 
>> <goswin-v-b@web.de> wrote:
> `dd if=/dev/originaldrive of=/dev/newdrive bs=512 count=1` to clone the 
> boot sector from one of the remaining original drives; this clones your 
> partition table too. Once that's done, and you've added the new drive's 
> partition(s) back into the RAID set(s) and it's synced, it will boot.
> 

Assuming you have no extended/logical partitions. In case of
legacy partitions, it's better to use:

sfdisk -d /dev/sda >pt.dump

and later to restore somewhere else

sfdisk /dev/sdb <pt.dump

Also - the 'dd' method would also clone disk signature (4 bytes at
1B8h), which depending on the needs, may not be desirable.