Re: Updating nvram via grub's postinst breaks some ppc64el systems
Hi Mathieu,
> TL;DR: anyone against adding --no-nvram to grub-install calls for
> grub-ieee1275, in postinst for ppc64el?
No, nothing against that, on the contrary. Also after querying some other people
more knowledgeable , especially Paulo Smorigo (grub contributor), he told : "I
agree with adding no-nvram of postinst for ppc64el. My option is that the
installer should not touch boot-device parameter at all and this is something
that the user or a management system should do.
GRUB overwrites all values in boot-device (previous boot-devices are removed
not appended). I had some issues in the past where a system had a network
installation and after it finished the system starts to boot locally and
this is not what the management system wanted."
> 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.
I did a bit of investigation. Especially, for my information, I read some docs
and share bits of it here.
According to the IEEE1275 Standard for Boot, that specification is valid. The
part "2,\boot\grub\powerpc-ieee1275\core.elf" is called the device-arguments
and "is interpreted by the driver and typically represents additional device
information, such as partition name or protocol. The device arguments field
and its preceding “ : ” may be omitted when specifying a node name, as it does
not serve to identify the device node ; instead, it is passed to that node’s
open method if that driver is opened."
For ppc64el, there is 3 cases :
- PowerVM : boot-device is used by the OF ; GPT is supported but ext2 is not
supported (FAT would work) and that's where we fail to load. An OF developer
confirmed missing extX support.
- PowerNV : petitboot reads directly the partitions and auto-detects grub's
installtion : not used here.
- qemu VM : boot-device is used by SLOF, and SLOF supports ext2 but not ext3/4 yet.
Also, on guests, on Debian/Ubuntu, boot-device is never updated because of a
patch of Colin Watson ; maybe that should be extended to chrp_ibm <-> PowerVM.
So the value you describe is valid, but currently the firmwares don't support
some filesystems that Debian/Ubuntu use.
Note : boot-device can also specify multiple possible values, I tried and it
works if we add a 2nd value as fallback with only the disk node name value.
> 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).
Also according to Paulo : "Now about pointing to a core.elf directly (like,
grub-install without a device), my option is that it's prone to error due to
OpenFirmware (and SLOF) limitations. [...] it's not the safer path and that's
why PReP partition exists (grub-install with a device)."
So to summarize, the advised behaviour at the moment, should be to make use of the
PReP partition and not change boot-device.
F.
Reply to: