Re: [RFC] grub-install C rewrite

[Andrey Borzenkov <arvidjaar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2758 bytes --]

В Thu, 26 Sep 2013 20:49:52 +0200
Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> пишет:

> On 26.09.2013 16:44, Lennart Sorensen wrote:
> >> windows is low priority and more of a bonus. The problems of handling
> >> anything that looks like a list (e.g. list of devices where / resides on
> >> in case of btrfs) and code becoming hairy to handle those cases is
> >> bigger reason.
> > 
> > Sure lists can be a hassle.
> > 
> > I didn't check lately, but does grub-install understand a list of devices
> > to install to yet?
> > 
> > ie:  grub-install /dev/sda /dev/sdb
> > 
> > After all if I have software raid, both those devices contain /boot and
> > are valid to boot from.  And since on things like IBM powerpc,
> > grub-install likes to update the firmware with the list of boot devices,
> > they do all have to be specified at once or you end up with the wrong
> > list (which so far I have worked around by manually fixing the firmware
> > settings after updating grub, which doesn't happen very often lately).
> > 
> > So calling grub-install for each device in turn (as I believe Debian
> > does on x86 if you tell it multiple boot devices), does not actually
> > give the correct result.
> > 

This will break in blocklist install because every time core.img is
recreated, but I do not see why it should not work if embedding is
possible. Challenge is to atomically detect whether this is possible or
not for all devices before you have clobbered half of them.

Although right now we first rewrite /boot/grub and then try to install;
if installation fails, /boot/grub no more matches embedded core.img
anyway.

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

Why it would require separate core.img? core.img needs to know how
access /boot/grub, and /boot/grub remains the same. Same with UUID. Or
do I miss something here?

> 
> It's also possible to have options --dry-run (doesn't really do the
> changes, except, perhaps, "mkdir -p") and --gen-script which would
> generate a list of commands which when executed would do exactly as if
> grub-install was run. So you can do
> grub-install --dry-run --gen-script=/tmp/myinstall ...
> <change /tmp/myinstall to will>
> /tmp/myinstall
> This has additional advantage of see which commands are really executed
> without having to understand the whole command flow.
> 

That would definitely be useful irrespectively of which language is
used to implement. In particular, this would allow to see list of
modules required for a system.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]