grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] grub-install C rewrite


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [RFC] grub-install C rewrite
Date: Fri, 27 Sep 2013 00:15:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8

On 26.09.2013 22:51, Chris Murphy wrote:
> 
> On Sep 26, 2013, at 2:22 PM, Lennart Sorensen <address@hidden> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> 


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]