Hi Mark!
On 3/25/22 09:51, Mark Cave-Ayland wrote:
However I suspect the reason the NVRAM is changed is for the case of dual-boot
machines where the existing MacOS partition is first shrunk and the Linux partitions
added at the end. In this case without the OF NVRAM boot-device update I'd expect OF
to always locate and boot MacOS first, instead of loading grub to offer a choice of
booting either MacOS or Linux.
Fair enough. But I think users should be able to handle the firmware-based boot manager
themselves to boot Debian if they want to. In the end, it's a matter of weighing the
pros and cons and if we can unbreak the installation on QEMU, I think the change is
worth it.
I should add that my real G4 is set up like this to allow testing various bits of pieces
against QEMU. However for QEMU I don't ever dual boot since I can simply boot either a
MacOS or Linux image directly ;)
Understood. My aim is to maximize compatibility on all possible targets to reduce the
number of possible support requests on the mailing list. And for that, I'm willing to
accept compromises.
We could, alternatively, also run the "nvram" command with "|| true" appended which
would grub-installer ignore the case where setting the boot-device path failed.