On 26.09.2013 22:51, Chris Murphy wrote: > > On Sep 26, 2013, at 2:22 PM, Lennart Sorensen wrote: > >> On Thu, Sep 26, 2013 at 08:49:52PM +0200, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>> This is interesting testcase which wasn't brought before. This would >>> potentially involve creating several core.img or forcing UUID when using >>> multiple devices. Again, pretty easy in C and hairy in bash due to list >>> handling. >> >> No, one core.img is fine. The boot disk is the boot disk in each case >> (so on x86 device 0x80). The same core.img gets inserted too all the >> devices, so that if it happens to be the boot disk, it works. Since the >> partition is raid1, the same UUID is everywhere. I do not expect >> booting from a raid5 device to be possible as the boot partition (althoug >> hperhaps grub is smart enough to read the kernel from an md raid5 device >> these days). > > It is. Even raid6 is possible. The limitation is the BIOS being able to present all member devices to grub for it to assemble the raid in order to find /boot. But I don't know if it can work on a degraded array by rebuilding parity. If not, I see no point in /boot on raid5/6. > > The case of btrfs raid0/1/10 is interesting. It's possible to boot all of these with GRUB2, I've tried up to 4 disks for those raid levels, and includes support for subvolumes/snapshots. I haven't extensively tried to break it with many snapshots, deletions, etc. So I don't know how resilient it is. The ability to boot raid1/10 with a missing member is useful. And it's actually a more complex setup to incorporate md raid and ext4 on those same disks for a separate /boot; or possibly losing ability to boot if /boot is on a single disk, which also complicates the layout. For such a layout, core.img is needed for each disk. > > Open question is if on BIOS hardware, if a 1MB BIOSBoot is preferred over the 64KB Btrfs bootloader pad? I don't know off hand if each member disk, or subsequently added disks, each have this 64KB pad or just the first member. > This is besides the point. I'm fine to discuss such things but in a separate thread. > > Chris Murphy > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >