* Booting from RAID (was: Re: booting btrfs)
@ 2014-01-13 6:12 Andrey Borzenkov
2014-01-21 8:03 ` Vladimir 'φ-coder/phcoder' Serbinenko
0 siblings, 1 reply; 3+ messages in thread
From: Andrey Borzenkov @ 2014-01-13 6:12 UTC (permalink / raw)
To: The development of GNU GRUB
On Mon, Jan 13, 2014 at 9:53 AM, Chris Murphy <lists@colorremedies.com> wrote:
> There are other problems with Fedora that prevent this from being usable now, including grubby which can't update grub.cfg during kernel updates, when /boot is on a Btrfs subvolume. So I have no present implementation, it's a question how to boot from Btrfs raid1 in the future, and have as little duplicative efforts as possible. Also, my argument is that if a GUI installer permits the user to create bootable raid1, that it should also properly configure all drives, and the static ESP grub.cfg, to make the system bootable. Otherwise the user has to do this manually which requires esoteric knowledge beyond most users. If the system really isn't bootable in the face of a disk failure, then I think a GUI installer shouldn't even offer bootable raid1 (Btrfs or otherwise) as an option.
openSUSE supports /boot on RAID1 and will simply run grub-install for
each device (it limits bootloader location to MBR in this case). This
can be optimized of course noticing that you need to create image just
once, but it works. Same can be used in case of btrfs.
I'd like to have some more generic case of having several boot block
locations independently on RAID (effectively grub-install /dev/sda
/dev/sda3 /dev/sdb ...); grub-install part looks more or less
straightforward, but modifying grub-setup part is more challenging.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Booting from RAID (was: Re: booting btrfs)
2014-01-13 6:12 Booting from RAID (was: Re: booting btrfs) Andrey Borzenkov
@ 2014-01-21 8:03 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-26 5:20 ` Andrey Borzenkov
0 siblings, 1 reply; 3+ messages in thread
From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2014-01-21 8:03 UTC (permalink / raw)
To: The development of GNU GRUB
[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]
On 13.01.2014 07:12, Andrey Borzenkov wrote:
> On Mon, Jan 13, 2014 at 9:53 AM, Chris Murphy <lists@colorremedies.com> wrote:
>
>> There are other problems with Fedora that prevent this from being usable now, including grubby which can't update grub.cfg during kernel updates, when /boot is on a Btrfs subvolume. So I have no present implementation, it's a question how to boot from Btrfs raid1 in the future, and have as little duplicative efforts as possible. Also, my argument is that if a GUI installer permits the user to create bootable raid1, that it should also properly configure all drives, and the static ESP grub.cfg, to make the system bootable. Otherwise the user has to do this manually which requires esoteric knowledge beyond most users. If the system really isn't bootable in the face of a disk failure, then I think a GUI installer shouldn't even offer bootable raid1 (Btrfs or otherwise) as an option.
>
> openSUSE supports /boot on RAID1 and will simply run grub-install for
> each device (it limits bootloader location to MBR in this case). This
> can be optimized of course noticing that you need to create image just
> once, but it works. Same can be used in case of btrfs.
>
> I'd like to have some more generic case of having several boot block
> locations independently on RAID (effectively grub-install /dev/sda
> /dev/sda3 /dev/sdb ...); grub-install part looks more or less
> straightforward,
You need to be careful with root_dirve == boot_drive check in this case.
You may have to create 2 images if this supposition is true for some
locations but not all.
> but modifying grub-setup part is more challenging.
>
It should invoke stup part several times.
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 274 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Booting from RAID (was: Re: booting btrfs)
2014-01-21 8:03 ` Vladimir 'φ-coder/phcoder' Serbinenko
@ 2014-01-26 5:20 ` Andrey Borzenkov
0 siblings, 0 replies; 3+ messages in thread
From: Andrey Borzenkov @ 2014-01-26 5:20 UTC (permalink / raw)
To: grub-devel
[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]
В Tue, 21 Jan 2014 09:03:52 +0100
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:
> On 13.01.2014 07:12, Andrey Borzenkov wrote:
> > On Mon, Jan 13, 2014 at 9:53 AM, Chris Murphy <lists@colorremedies.com> wrote:
> >
> >> There are other problems with Fedora that prevent this from being usable now, including grubby which can't update grub.cfg during kernel updates, when /boot is on a Btrfs subvolume. So I have no present implementation, it's a question how to boot from Btrfs raid1 in the future, and have as little duplicative efforts as possible. Also, my argument is that if a GUI installer permits the user to create bootable raid1, that it should also properly configure all drives, and the static ESP grub.cfg, to make the system bootable. Otherwise the user has to do this manually which requires esoteric knowledge beyond most users. If the system really isn't bootable in the face of a disk failure, then I think a GUI installer shouldn't even offer bootable raid1 (Btrfs or otherwise) as an option.
> >
> > openSUSE supports /boot on RAID1 and will simply run grub-install for
> > each device (it limits bootloader location to MBR in this case). This
> > can be optimized of course noticing that you need to create image just
> > once, but it works. Same can be used in case of btrfs.
> >
>
> > I'd like to have some more generic case of having several boot block
> > locations independently on RAID (effectively grub-install /dev/sda
> > /dev/sda3 /dev/sdb ...); grub-install part looks more or less
> > straightforward,
> You need to be careful with root_dirve == boot_drive check in this case.
> You may have to create 2 images if this supposition is true for some
> locations but not all.
> > but modifying grub-setup part is more challenging.
> >
> It should invoke stup part several times.
Sure, but I would rather avoid aborting on the first error and continue
to install to further locations if possible. That was easy with shell
utilities but became less though today.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-01-26 5:20 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-13 6:12 Booting from RAID (was: Re: booting btrfs) Andrey Borzenkov
2014-01-21 8:03 ` Vladimir 'φ-coder/phcoder' Serbinenko
2014-01-26 5:20 ` Andrey Borzenkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).