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. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - [email protected] `. `' Freie Universitaet Berlin - [email protected] `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
