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.
