[1] https://cdimage.debian.org/cdimage/ports/snapshots/2022-03-24/debian-11.0.0-powerpc-NETINST-1.iso
[2] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L968
Are there any plans to improve the NVRAM emulation in QEMU or is there any alternative
command that we should run on QEMU-based systems?
Hi Mark!
On 3/24/22 15:40, John Paul Adrian Glaubitz wrote:
Are there any plans to improve the NVRAM emulation in QEMU or is there any alternative
command that we should run on QEMU-based systems?
OK, the solution is actually as simple as skipping the "nvram" command when running inside
a QEMU guest. However, I have no clue how to detect whether it's running on a QEMU-emulated
PowerMac or a real one.
Any ideas?
Adrian
On 3/24/22 15:40, John Paul Adrian Glaubitz wrote:
Are there any plans to improve the NVRAM emulation in QEMU or is there any alternative
command that we should run on QEMU-based systems?
OK, the solution is actually as simple as skipping the "nvram" command when running inside
a QEMU guest. However, I have no clue how to detect whether it's running on a QEMU-emulated
PowerMac or a real one.
[1] https://opensource.apple.com/source/bless/bless-37/README.BOOTING
[2] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L961
[3] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L968
Hi Mark!
On 3/24/22 16:39, John Paul Adrian Glaubitz wrote:
On 3/24/22 15:40, John Paul Adrian Glaubitz wrote:
Are there any plans to improve the NVRAM emulation in QEMU or is there any alternative
command that we should run on QEMU-based systems?
OK, the solution is actually as simple as skipping the "nvram" command when running inside
a QEMU guest. However, I have no clue how to detect whether it's running on a QEMU-emulated
PowerMac or a real one.
I think the solution is much simpler. We just remove the "nvram" command on Power Macintosh,
it's actually not needed. According to Apple's documentation, OpenFirmware will automatically
search for an operating system on any of the disks in the system, so there is no need to set
the boot-device in NVRAM expliclity [1].
In order to verify that, I just set the "boot-device" on my iBook G4 to NULL and can confirm
that it still boots fine.
root@ibook-g4:~# nvram --print-config=boot-device /pci@f4000000/ata-6@d/@0:2,\\:txbi
root@ibook-g4:~# nvram --update-config boot-device=""
root@ibook-g4:~# nvram --print-config=boot-device
root@ibook-g4:~# reboot
root@ibook-g4:~# Connection to 192.168.178.175 closed by remote host. Connection to 192.168.178.175 closed.
glaubitz@suse-laptop:~> ssh root@192.168.178.175
Linux ibook-g4 5.16.0-5-powerpc #1 Debian 5.16.14-1 (2022-03-15) ppc
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Mar 25 08:29:21 2022 from 192.168.178.81
root@ibook-g4:~#
So, I think it should be safe to just remove these two lines required for setting
the boot-device in NVRAM from the grub-installer script [2][3].
Adrian
[1] https://opensource.apple.com/source/bless/bless-37/README.BOOTING
[2] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L961
[3] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L968
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.
I'd probably lean lightly towards having a separate dialog with an "Ignore" option for the "nvram" update step if it goes wrong, as I have no idea how often this can fail on a real Mac given the age of the hardware.
However I don't mind too much whatever you choose as long as it is clearly documented somewhere so I can answer questions that any QEMU PPC users may have.
[1] https://opensource.apple.com/source/bless/bless-37/README.BOOTING
[2] https://salsa.debian.org/installer-team/grub-installer/-/commit/f7eb12f89844475db8f79bf90546d36e8bb0dfb6
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 57:59:25 |
Calls: | 6,652 |
Calls today: | 4 |
Files: | 12,200 |
Messages: | 5,331,127 |