Re: Changing bootstrap method for NewWorld Power Macs
On 02/01/2019 16:18, Frank Scheiner wrote:
> Hi Mark,
>
> On 1/2/19 16:27, Mark Cave-Ayland wrote:
>> On 31/12/2018 13:15, Frank Scheiner wrote:
>>> Sorry to hear that, though I think you need to provide additional details at this
>>> time:
>>>
>>> What do you mean with "Debian images"? Because if you speak of the installer ISOs, my
>>> changes won't change anything with their ability to boot on NewWorld Power Macs or
>>> QEMU (I think).
>>
>> The part I'm worried about is that OpenBIOS searches the Apple Partition Map for an
>> "Apple_Bootstrap" partition on PPC Mac machines, probes the FS, and then tries to
>> boot dev:part:,\\:tbxi, dev:part:,\ppc\bootinfo.txt and dev:part:,%BOOT in that order.
>
> Is that done via the "standard" `boot` command with OpenBIOS?
Yes, that's correct.
>> I believe that yaboot blesses itself on the HFS "Apple_Bootstrap" partition which
>> allows OpenBIOS to locate and run the bootloader. My understanding is that you would
>> like to change to MBR and FAT16 which would then fail in QEMU as OpenBIOS doesn't
>> have a functioning FAT driver - is that correct?
>
> I think so, but you are talking about the installed OS now. Earlier it sounded like
> you were talking about the installer ISOs and my changes don't touch the boot method
> used for these.
Oh so you're proposing a split scheme? Keeping Yaboot for the installation CD but
then using GRUB for the installed OS?
> And still, my remark below should hold true:
>
>>> My changes also do not remove existing code related to HFS as bootstrap. I expect
>>> that you will be able to still create all relevant partitioning and file systems
>>> manually from within the Debian installer, if needed to make it work under QEMU.
>
>
>>> Other point: why can't you directly load kernel and initramfs with QEMU?
>>
>> That is one potential workaround, but for years everyone has booted their PPC VMs
>> under QEMU with "qemu-system-ppc -cdrom path/to/cdrom.iso" and for me that is an
>> extremely high barrier, particularly for novice users, to require them to extract a
>> kernel and initrd from an ISO first.
>
> I don't see a reason for that, because again the boot method for the ISOs isn't
> changed. Sure, in the end the installed OS (via a default installation) is then not
> bootable via OpenBIOS anymore, but users could workaround that by extracting kernel
> and initrd and load them directly with QEMU.
But again this is a large change in behaviour: the general expectation with QEMU has
always been that you can boot from an installation ISO, install to a virtual HD, and
then reboot the virtual HD to run your OS. Changing this so that your newly installed
OS is no longer bootable would be a huge regression (and it would be me that would
end up getting the angry emails).
The other issue, of course is that access to real Mac hardware is quite limited these
days. For example a recent DMA refactoring broke sun4m, but someone helpfully
supplied a QEMU test image that enabled the regression to be fixed quickly. My
concern here is that if you lose this ability, then none of the grub developers will
be able to help in this way which puts much more responsibility on members of this
list to chase down and fix issues if they occur.
> ****
>
> BTW could the "grubfs" stuff ([1]) not be used to access FAT? I mean by just using
> `boot` and `boot-device` set to e.g. `<OF_PATH_TO_1ST_MBR_PART>:,\grub`? So that the
> OpenBIOS defaults don't change, but users could also boot from FAT16 on MBR
> partitioned drives.
The grubfs parts of OpenBIOS aren't really used (other than for early x86
experiments) and the last time I looked at this, I found that the files were
certainly old enough to have endian issues on big endian architectures and there were
problems mixing matching grubfs and non-grubfs drivers. So sadly this approach isn't
as easy as it looks.
ATB,
Mark.
Reply to: