В Tue, 21 Jan 2014 09:03:52 +0100 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> пишет:
> On 13.01.2014 07:12, Andrey Borzenkov wrote: > > On Mon, Jan 13, 2014 at 9:53 AM, Chris Murphy <li...@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.
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel