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 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. > So really my main objection is that it is much harder to debug and fix > C code than it is to fix a script calling a bunch of external commands. > > At the very least a C version of grub-install must have an option to > list every command it is attempting to execute externally. Certainly > adding 'set -x' to grub-install has often been helpful.
It's surely sth we can do. grub-install does only following that is affecting system: 1) mkdir -p 2) copy files. We can write exact copy commands 3) grub-mkimage. We can do the same. 4) grub-setup. Ditto 5) Create load.cfg. Ditto. 6) calling external commands. We can have 4 levels of verbosity: 0) quiet, 1) write to stderr the commands 2) like 1 but show grub_util_info 3) additionally show grub_dprintf 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel