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@xxxxxx> 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.
--
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
