Hi, TL;DR: anyone against adding --no-nvram to grub-install calls for grub-ieee1275, in postinst for ppc64el? I've been looking at issues with some scripted (not d-i and not preseeded...) installs running grub-install on ppc64el, leading to the nvram variable "boot-device" being mangled by grub-install when it is run with just: grub-install --target=powerpc-ieee1275 The result would generally be of the format: /path/to/device:2,\boot\grub\powerpc-ieee1275\core.elf This is wrong on PowerVM systems. They don't go into the partition to read ext2 and read the bootloader, but instead expect things to be written to a PReP partition, and for that partition to be pointed to by disk path only (the above path, up to the colon). Unfortunately, I don't know enough about all of the ppc64el systems to know if there is some type of firmware that accepts this value as valid to point to the bootloader. Furthermore, grub-install is called as above for every run of the grub-ieee1275 postinst in the configure case, so presumably for every upgrade of grub. This would mean a mangled nvram as soon as you upgrade grub, even if you fixed it manually already. Even if it was set to the correct value, it seems unnecessary to modify nvram only to re-write the same config variable again with the same value. I've discussed this with infinity for Ubuntu and we've come to the conclusion that grub should not change nvram, except in the installation case, where it's already being handled by grub-installer (which runs grub-install on its own, without --no-nvram, and that is fine). The change is already ready in a git branch for grub[1]. Thoughts? [1] http://anonscm.debian.org/cgit/pkg-grub/grub.git/log/?h=people/cyphermox/nvram -- Mathieu Trudel-Lapierre <mathieu.tl@gmail.com> Freenode: cyphermox, Jabber: mathieu.tl@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1
Attachment:
signature.asc
Description: OpenPGP digital signature