Re: Changing bootstrap method for NewWorld Power Macs
On 1/7/19 12:15, Mark Cave-Ayland wrote:
On 02/01/2019 16:18, Frank Scheiner wrote:
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?
No, it's just one change at a time. As soon as we have GRUB
installations working properly on NewWorld Power Macs we can think about
how to redo the installer ISOs with GRUB as bootloader.
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).
Aha, we're getting closer to the real issue now: angry emails ;-) Just
kidding... :-D
But Mark, there are two workarounds now that will make it work with QEMU
with my changes applied to the Debian installer:
* Load kernel and initramfs directly with QEMU
* Configure partitioning and file systems manually during the Debian
installation
I'd say QEMU is well prepared for such a change. Don't you think?
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.
Maybe let's start from the current situation for NewWorld Power Macs and
Debian (Ports):
We have some "essential" software that is no longer maintained or
maintained properly (e.g. yaboot) or that does not currently work on
both arches and needs fixing (e.g. hfsprogs). Then, doing things in a
proper way during the installation - i.e. (H)FS related tasks are
handled via partman and not the installer script of the actual
bootloader - requires two new udebs (see [1] for details) which then
again require maintenance. I have prepared code - untested so far - for
a possible partman-hfs (on [2]) though. But how should we get this into
Debian, if Debian already removed support for NewWorld Power Macs the
hard way? And who will take care of the maintenance?
Then we have this alternative bootstrap method (via FAT16 on MBR
partitioned drive) that works with what's already there and what is also
maintained in Debian.
[1]: https://lists.debian.org/debian-powerpc/2018/12/msg00043.html
[2]: https://salsa.debian.org/frank-scheiner-guest/partman-hfs
I mean, it's not that my changes would remove the tools to support the
other bootstrap method, we're just no longer depending on them. It will
require manual work by users to configure bootstrap from HFS after my
changes are applied, but it's still possible AFAICS.
Cheers,
Frank
Reply to: