NVRAM emulation issues in QEMU

[John Paul Adrian Glaubitz]

Hi Mark!

As you may remember, grub-installer has issues on QEMU when emulating a PowerMac.

I have now tried installing the latest ISO [1] myself and I noticed it fails with

"nvram: ERROR: there is no "common" partition!"

when grub-installer invokes the nvram command to set the boot-device [2].

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?

The ISO image works fine on real hardware, i.e. my iBook G4.

Thanks,
Adrian

> [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

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

[John Paul Adrian Glaubitz]

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

[Mark Cave-Ayland]

On 24/03/2022 15:39, John Paul Adrian Glaubitz wrote:

> 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

Hi Adrian,

This is a little bit of a tricky one: QEMU uses a custom format to store its NVRAM
info (which I think is derived from PReP?), so even just adding a backing store would
still cause issues with some utilities such as nvram which are evidently looking for
a specific Apple NVRAM layout which I don't believe is documented.

IIRC from my previous testing the older images used to pop up a dialog box in the
Debian Installer when the nvram command failed giving the option to either Retry or
Ignore, at which point I'd just hit Ignore and carry on anyway. Is it possible to
keep the same behaviour with your latest changes? I think this would certainly be the
simplest solution in the short term as it won't affect real machines, and I can
document the error as a QEMU known issue.


ATB,

Mark.

[John Paul Adrian Glaubitz]

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 ro...@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

[John Paul Adrian Glaubitz]

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

[Mark Cave-Ayland]

Hi Adrian,

Thanks for the links. OpenBIOS should work in the same way here in that it scans each
volume in order until it finds a HFS/HFS+ partition with a blessed file to load and
execute.

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.

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 ;)

ATB,

Mark.

[Mark Cave-Ayland]

On 25/03/2022 08:57, John Paul Adrian Glaubitz wrote:

> 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.


ATB,

Mark.

[John Paul Adrian Glaubitz]

Hi Mark!

On 3/29/22 09:37, Mark Cave-Ayland wrote:
> 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.

Since the firmware on a PowerMac is searching for bootable partitions automatically
according to documentation [1], I don't really see a need for touching the NVRAM
at all.

We did this in the past because Yaboot's installer was tinkering with the NVRAM
setting and we assumed it was necessary.

In the end, I just removed the code to modify the NVRAM contents [2] since that's
the easiest and least error-prone approach. This way we also avoid additional
potential bugs and additional translation work since any dialog would have to
be translated by the l10n team.

> 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.

Once the latest grub-installer has been uploaded to unstable, the installation
images will just work on QEMU without any additional hacks.

FWIW, I gave it a try configuring a Mac99 QEMU VM from virt-manager yesterday
and I couldn't get it to work, OpenBIOS wouldn't let me use the keyboard and
it also wouldn't find the bootable CD.

Using QEMU from the command line works fine though. So it seems that virt-manager
needs to improve its templates for PowerMac emulation.

Adrian

> [1] https://opensource.apple.com/source/bless/bless-37/README.BOOTING
> [2] https://salsa.debian.org/installer-team/grub-installer/-/commit/f7eb12f89844475db8f79bf90546d36e8bb0dfb6