Re: Why it's so difficult to fix PowerMac booting for good
One more (quite long) follow-up: (sorry for the length!)
On 05/27 2023 20:05, Stan Johnson wrote:
The partition should be Apple_Bootstrap, type Apple_Bootstrap. That way
it's HFS but not normally accessed via Mac OS X.
In my experience any partition of type Apple_Boot is also hidden from
Mac OS X, as it is used e.g. for Software RAID setups to boot Mac OS X
(and therefore shouldn't be seen on the desktop either).
I tested with Apple_Boot and a bootinfo file with an icon, and it is
picked up and listed by the OS Picker (holding the option key after the
chime). The same is probably true for Apple_Bootstrap. The key here is
the bootinfo file.
It's not safe for a Linux distribution to mount the Apple_Bootstrap
partition except when it actually needs to write to it. Keeping it
mounted as /boot, or /boot/grub, leaves it vulnerable to corruption if
the system crashes (just like 64-bit Intel systems are vulnerable by
keeping the EFI partition mounted).
And to clarify my previous response: An example partitioning:
/dev/sda1 is the APM
/dev/sda2 is the Apple_Boot with the HFS filesystem, a bootinfo file
with an icon, a GRUB binary and a GRUB configuration file that contains
only a reference to another partition UUID and loads another grub.cfg
from said UUID partition
/dev/sda3 is the actual /boot with the kernels and initrds, and
/boot/grub/grub.cfg, which is loaded by the GRUB image from /dev/sda2
In this scenario /dev/sda2, the HFS boot configuration with a static
GRUB, would never get mounted. There's no need to. All it does is load
/boot/grub/grub.cfg, and this is on /dev/sda3, an ext2/3/4 or any other
suitable filesystem that the static GRUB on the NewWorld Bootblock has
modules for.
Only when GRUB itself gets a version bump would the maintainer of the
NewWorld Bootblock image (on /dev/sda2 in the example) have to update
the package, which would have to be reinstalled = rewritten to the
partition (/dev/sda2 in the example) in order to get the version update
for the included GRUB binary image as well.
Also in NVRAM /dev/sda2 would be set. But this doesn't change the fact
that only /dev/sda3, hence /boot, would ever have to be modified for
GRUBs configuration.
The beauty of it would also be that Debian could/would have its own
Apple_Boot (or Apple_Bootstrap) partition, which could be one of many
more. AFAIK there's no limit to how many there might be. Every version
of Mac OS X, when multiple version of the Apple operating system are
installed on the same disk, has their own Apple_Boot anyway, given the
necessity (like using HFSX, i.e. "case-sensitive HFS+", or Software
RAID). Adding one specifically for Debian doesn't make a difference.
Also, its location doesn't matter. It could be /dev/sda128 for all I
know (the standard partition limit for APM is AFAIK 128 partitions),
with, for example, the Debian system containing /boot being /dev/sda126
and / being /dev/sda127... If accessible by GRUB (i.e. non-encrypted,
file system supported by GRUB) / can be the one partition which has
/boot included, provided there are symlinks of some sorts (because
/grub/grub.cfg has to be accessible -- or we use symlinks on the /boot
partition and always load /boot/grub/grub.cfg, which is probably the
better way).
The only important step with such a static image for the HFS
Apple_Boot(strap) partition and it's included configfile statement would
be the correct UUID for /boot, so if /boot was on /dev/sda3, mke2fs
would have to be called with the specific -U <UUID> format option to
match the one specified in /dev/sda2.
Specifically, the /static/ image for the NewWorld Bootblock would have
to include this:
1. a HFS file system
2. the following files:
a) ofboot.b :tbxi -- loads <BOOT-SCRIPT> boot &device;,\grub\grub.img
b) grub.img -- static GRUB image which includes modules, e.g.
search_fs_uuid.mod search_fs_file.mod search_label.mod search.mod
part_apple.mod fshelp.mod ext2.mod halt.mod reboot.mod echo.mod
c) an initial grub.cfg, with exactly THIS content:
----------
search --no-floppy --fs-uuid --set=root 01234567-89ab-cdef-fedc-ba9876543210
set prefix=($root)/boot/grub
configfile /boot/grub/grub.cfg
----------
So, say the Debian installer would find an empty HDD, it would create a
new NewWorld Bootblock as /dev/sda2, and this would allow the OS Picker
to pick up GRUB (through the blessed bootinfo file "ofboot.b", which
includes a nice icon), which would do only one thing: It would load
grub.img, which would load grub.cfg, which would look for any device
with the filesystem UUID 01234567-89ab-cdef-fedc-ba9876543210 and load
/boot/grub/grub.cfg from it.
So, if now the Debian installer writes this static image to /dev/sda2
(fixed partition size mandatory), it would now only have to create a new
filesystem (ext2 in this case, but additional GRUB modules in the
NewWorld Bootblock would allow it to access more filesystems) as /boot,
containing /boot/grub/grub.cfg. In this example, this /boot partition
would then be /dev/sda3. The Debian installer would have to call mke2fs
-U 01234567-89ab-cdef-fedc-ba9876543210 /dev/sda3, mount it as /boot and
install GRUB to it under /boot/grub. A symlink for /boot referring to
itself "." would make /boot/grub accessible for both cases: /dev/sda3 as
a separate /boot partition, or as the partition containing / (the root
partition). Later, grub-mkconfig would have to create
/boot/grub/grub.cfg. The user or admin can change that config file to
his/her liking (like e.g. include Mac OS X via os-prober or include a
static part from /etc/grub.d/<something>).
The path to boot would be:
OF3+ --> either OS Picker or NVRAM string for bootdevice --> /dev/sda2
"NewWorld Bootblock" static Debian image --> load
ofboot.b->grub.img->(initial)grub.cfg-> find UUID for /boot (in the
example /dev/sda3) and load (/boot)/grub/grub.cfg from there --> boot
whatever is configured there...
TL;DR the HFS partition wouldn't ever be mounted, hence no corruption,
no system crashes.
All GRUB configuration changes would be on /boot/grub/grub.cfg, which
would be a 100 % native Linux partition (/dev/sda3 in the example).
(This is basically what
https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC) describes...)
Linux User #330250
Reply to: