Why it's so difficult to fix PowerMac booting for good

[John Paul Adrian Glaubitz]

Hello!

Since this topic is coming up from time to time, here a short rundown why
making the bootloader installation on Apple PowerMac systems work properly.

Installing a bootloader on a PowerMac requires an HFS or HFS+ partition where
the initial bootloader must be copied and "blessed" such that the firmware of
a PowerMac finds and loads the bootloader. The detailed process is explained
here [1], for example. In debian-installer, this process is performed by the
grub-installer script [2].

One of the problems here is that the tool for creating HFS/HFS+ filesystems
is covered by a license that Debian considers non-free [3]. This resulted
in the package being moved to the "non-free" section which is currently unsupported
by Debian Ports meaning I always have to inject the hfsprogs package into debian-
installer manually when building an installation image for powerpc or ppc64.

As a result, every installation image that was build without this manual package
injection will not work. There are some ISO images on the cdimage server where
that indeed is the case. If you run into a problem where the bootloader installation
doesn't work, it's therefore advisable to try a different image.

Another problem is that blessing currently only works using the "hattrib" command
from the hfsutils package which supports HFS but no HFS+ filesystems. While GRUB
seems to come with its own blessing utility which supposedly supports HFS+ filesystems,
I never got that to work.

If we could get Apple PowerMac machines to boot from a FAT filesystem, the licensing
issue with hfsprogs would no longer be a headache. According to Apple's documentation,
booting from a FAT boot partition should work [4] but I have never gotten around to
testing that.

So, if anyone has the time and enthusiasm to be able to get an Apple PowerMac to boot
off a FAT partition, please give it a try and let me know. If it works, we can replace
the current bootloader installation in grub-installer [2] and fix the issue for good.

Until then, we will have to resort to manual installation image builds.

Adrian

[1] https://forums.gentoo.org/viewtopic-t-1082746-start-0.html
[2] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L1030
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666707
[4] https://github.com/apple-oss-distributions/bless/blob/main/README.BOOTING

[Frank Scheiner]

Hi Adrian,

Post by John Paul Adrian Glaubitz
[...]
If we could get Apple PowerMac machines to boot from a FAT filesystem, the licensing
issue with hfsprogs would no longer be a headache. According to Apple's documentation,
booting from a FAT boot partition should work [4] but I have never gotten around to
testing that.
So, if anyone has the time and enthusiasm to be able to get an Apple PowerMac to boot
off a FAT partition, please give it a try and let me know. If it works, we can replace
the current bootloader installation in grub-installer [2] and fix the issue for good.

See [5] for an implementation from end of 2018 (worked for me on a 11,2
Power Mac G5 and a Mac mini G4). The discussion that followed might be
also of interest.

[5]: https://lists.debian.org/debian-powerpc/2018/12/msg00054.html

Cheers,
Frank

[John Paul Adrian Glaubitz]

Hello!

Post by Frank Scheiner

Post by John Paul Adrian Glaubitz
[...]
If we could get Apple PowerMac machines to boot from a FAT filesystem, the licensing
issue with hfsprogs would no longer be a headache. According to Apple's documentation,
booting from a FAT boot partition should work [4] but I have never gotten around to
testing that.
So, if anyone has the time and enthusiasm to be able to get an Apple PowerMac to boot
off a FAT partition, please give it a try and let me know. If it works, we can replace
the current bootloader installation in grub-installer [2] and fix the issue for good.

See [5] for an implementation from end of 2018 (worked for me on a 11,2
Power Mac G5 and a Mac mini G4). The discussion that followed might be
also of interest.
[5]: https://lists.debian.org/debian-powerpc/2018/12/msg00054.html

Does your approach include a blessing tool? I want to avoid messing around with the NVRAM
as this approach is very fragile. A blessed bootloader, on the other hand, is automatically
displayed in the boot menu and booted unless any alternatives are present. It's therefore
much more robust.

Adrian

[John Paul Adrian Glaubitz]

Hi!

Post by John Paul Adrian Glaubitz
Does your approach include a blessing tool?

Not that I know of. The grub image (a copy of GRUB's `core.elf`) in the
root of the OF bootstrap partition is configured in the OF environment
var `boot-device`. OF therefore knows what file to boot and from where.

Which works as long no one touches the NVRAM. Also, an unblessed bootloader
does not show in the firmware's boot menu. It's completely hidden to the user.

Post by John Paul Adrian Glaubitz
I want to avoid messing around with the NVRAM
as this approach is very fragile.

Why is that?

Because there is no obvious way for the user to boot installed system once the
NVRAM data has been altered or corrupted.

The huge advantage of using a blessed bootloader is that it will show up in the
firmware's boot menu, no matter what path has been written into NVRAM.

The firmware will always scan all disks for blessed bootloaders and will always
list these in the boot menu, no matter what values have been written to NVRAM.

This is a huge advantage and makes the whole boot process rock solid. The system
will always be bootable unless you corrupt or overwrite the boot filesystem.

Not using a blessed bootloader means that a simple wrong call to the NVRAM tool
or a dead NVRAM battery could render the system unbootable.

Post by John Paul Adrian Glaubitz
A blessed bootloader, on the other hand, is automatically
displayed in the boot menu and booted unless any alternatives are present. It's therefore
much more robust.

I don't know if the described approach is more robust, but I believe you
can't have both FAT as OF bootstrap partition **and** blessing. Reading
```
[...]
Furthermore, the CoreServices folder is
"blessed", which means that it's directory ID (analogous to an inum
in FFS terminology) is recorded, in the HFS+ volume header.
[...]
```
...makes it look like it is specific to HFS(+). I am hence not even sure
if the graphical boot menu will work with FAT as OF bootstrap partition.
I never used it because I booted the machines from OF.

Well, it works with ISO images, that's the point. The installation CDs use iso9660
as their filesystem and they have a blessed bootloader which shows in the firmware's
boot menu.

Thomas Schmitt briefly explained how xorriso does it, but I don't really understand
the underlying concept yet but I would assume you could use it for booting using a
FAT16 partition as well.

Adrian

[Thomas Schmitt]

Hi,

Post by John Paul Adrian Glaubitz

I believe you
can't have both FAT as OF bootstrap partition **and** blessing.

The only way would be that Apple had defined some protocol using the
specified capabilities of FAT, by which blessing and other Apple-specific
file properties can be expressed, and that firmware follows that protocol.

Looking at section "Forks and alternate data streams" of
https://en.wikipedia.org/wiki/File_Allocation_Table
i deem this not impossible:
"Mac OS using PC Exchange stores its various dates, file attributes
and long filenames in a hidden file called "FINDER.DAT", [...]
Finder stores some folder and file metadata in a hidden file called
".DS_Store" [...]"

Post by John Paul Adrian Glaubitz

...makes it look like it is specific to HFS(+).

At least the idea of blessing comes from there.

I understand from libisofs/hfsplus.c that blessings are expressed in HFS+
by fields in the superblock, not by attributes of nodes in the file tree.
Each kind of blessing has one such field with one uint32_t number, which
i guess is the equivalent of an inode number. (0 obviously means that the
blessing is not issued to any file.)
grub-mkrescue lets xorriso issue blessing "intel_bootfile" for its x86
ISOs. I guess that debian-powerpc would need "ppc_bootdir". There are
also "show_folder", "os9_folder", and "osx_folder".

Post by John Paul Adrian Glaubitz
Well, it works with ISO images,

libisofs under xorriso only applies blessings to files in its self-made
HFS+ filesystem tree. It does not produce the Apple SUSP field "AA" in
the ISO 9660 tree and it is not clear whether "AA" can represent blessing
at all.

I am not aware of a producer of ISO 9660 filesystems which would emit
"AA" fields. So i cannot make proposals how owners of Apple hardware could
test whether "AA" can indicate blessings to their machines' firmware.

SUSP (System Use Protocol) is a framework for implementing additional
file properties within ISO 9660. The most popular payload protocol is
Rock Ridge (RRIP) which represents POSIX file attributes when the ISO
is mounted by a Unix-like operating system. SUSP populates the System Use
field which is defined by the ISO 9660 (ECMA-119) specs.
Apple took this opportunity for defining a neighbor of Rock Ridge which
can represent Apple file attributes:
https://web.archive.org/web/20000519225244/http://developer.apple.com/technotes/fl/fl_36.html


Have a nice day :)

Thomas

[Lennart Sorensen]

Post by John Paul Adrian Glaubitz
Well, it works with ISO images, that's the point. The installation CDs use iso9660
as their filesystem and they have a blessed bootloader which shows in the firmware's
boot menu.
Thomas Schmitt briefly explained how xorriso does it, but I don't really understand
the underlying concept yet but I would assume you could use it for booting using a
FAT16 partition as well.

It makes the CD contain both HFS+ and ISO9660 filesystem (sharing the
same data blocks) and of course by having HFS+ it means you can bless
a boot file. So in fact it is not working with iso9660, it is working
with HFS+. Hybrid CDs are interesting.

So it seems the only way to not use nvram settings for booting is with
a blessed boot file, and that requires HFS/HFS+, and the current tools
to manage that are apparently non-free.

[Frank Scheiner]

Hallo,

Post by John Paul Adrian Glaubitz
Does your approach include a blessing tool?

Not that I know of. The grub image (a copy of GRUB's `core.elf`) in the
root of the OF bootstrap partition is configured in the OF environment
var `boot-device`. OF therefore knows what file to boot and from where.

Post by John Paul Adrian Glaubitz
I want to avoid messing around with the NVRAM
as this approach is very fragile.

Why is that?

Post by John Paul Adrian Glaubitz
A blessed bootloader, on the other hand, is automatically
displayed in the boot menu and booted unless any alternatives are present. It's therefore
much more robust.

I don't know if the described approach is more robust, but I believe you
can't have both FAT as OF bootstrap partition **and** blessing. Reading
through [4]:

```
[...]
Furthermore, the CoreServices folder is
"blessed", which means that it's directory ID (analogous to an inum
in FFS terminology) is recorded, in the HFS+ volume header.
[...]
```

...makes it look like it is specific to HFS(+). I am hence not even sure
if the graphical boot menu will work with FAT as OF bootstrap partition.
I never used it because I booted the machines from OF.

Cheers,
Frank

[Martina Hřebcová]

Hi Adrian!


thank you for detailed explanation. I am in situation, when installing
Debian Sid after several years. Previously I have Debian 8 ( with yaboot
) and then Debian 10 with some grub workaround. I simply forgot howto do
it an cannot find the new how-to.

This info is perfect. So I will use latest .iso ( with or without
hfsprogs ), boot in expert mode and install Debian base system only, and
the rest I will do manually.


thanks


Martina

Post by John Paul Adrian Glaubitz
Hello!
Since this topic is coming up from time to time, here a short rundown why
making the bootloader installation on Apple PowerMac systems work properly.
Installing a bootloader on a PowerMac requires an HFS or HFS+ partition where
the initial bootloader must be copied and "blessed" such that the firmware of
a PowerMac finds and loads the bootloader. The detailed process is explained
here [1], for example. In debian-installer, this process is performed by the
grub-installer script [2].
One of the problems here is that the tool for creating HFS/HFS+ filesystems
is covered by a license that Debian considers non-free [3]. This resulted
in the package being moved to the "non-free" section which is currently unsupported
by Debian Ports meaning I always have to inject the hfsprogs package into debian-
installer manually when building an installation image for powerpc or ppc64.
As a result, every installation image that was build without this manual package
injection will not work. There are some ISO images on the cdimage server where
that indeed is the case. If you run into a problem where the bootloader installation
doesn't work, it's therefore advisable to try a different image.
Another problem is that blessing currently only works using the "hattrib" command
from the hfsutils package which supports HFS but no HFS+ filesystems. While GRUB
seems to come with its own blessing utility which supposedly supports HFS+ filesystems,
I never got that to work.
If we could get Apple PowerMac machines to boot from a FAT filesystem, the licensing
issue with hfsprogs would no longer be a headache. According to Apple's documentation,
booting from a FAT boot partition should work [4] but I have never gotten around to
testing that.
So, if anyone has the time and enthusiasm to be able to get an Apple PowerMac to boot
off a FAT partition, please give it a try and let me know. If it works, we can replace
the current bootloader installation in grub-installer [2] and fix the issue for good.
Until then, we will have to resort to manual installation image builds.
Adrian

[1] https://forums.gentoo.org/viewtopic-t-1082746-start-0.html
[2] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L1030
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666707
[4] https://github.com/apple-oss-distributions/bless/blob/main/README.BOOTING

[John Paul Adrian Glaubitz]

Hello!

Post by John Paul Adrian Glaubitz
Installing a bootloader on a PowerMac requires an HFS or HFS+ partition where
the initial bootloader must be copied and "blessed" such that the firmware of
a PowerMac finds and loads the bootloader. The detailed process is explained
here [1], for example. In debian-installer, this process is performed by the
grub-installer script [2].

I made some experiments with GRUB on Apple PowerMac to obtain some more data points
on the boot process. I tested both HFS and HFS+ as well as other filesystems and
I also used GRUBs own bless tool.

Here's what I found out:

GRUB's grub-macbless does not work at all. Neither is it sufficient to bless the
System/Library/CoreServices folder with just grub-macbless to get a bootable
system nor does it help combining it with

"hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX"

Only the combination of both

"hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX"
"hattrib -b System:Library:CoreServices"

makes the system boot.

==================================================================================

For this reason, I couldn't test HFS+ since hfsutils from where hattrib comes from
does not support HFS+.

Also, I ran into a strange problem with HFS+ where I couldn't list the files in a
mounted HFS+ filesystem. I got the error "Value too large for defined data type"
in this case. This could be worked around after creating an empty file in the root
of the HFS+ filesystem using

"touch /path/to/hfs/plus/folder".

==================================================================================

Installing on a FAT filesystem does not work at all. grub-install actually refuses
the installation if the target directory for --macppc-directory is not an HFS/HFS+
filesystem.

==================================================================================

To conclude, there is currently no better way in getting an Apple PowerMac to boot.

Also, I have reached to Apple Legal and asked them to change the license for the
»hfs« [1] package to a more permissive license which is compatible with Debian's
DFSG.

Adrian

Post by John Paul Adrian Glaubitz
[1] https://github.com/apple-opensource/hfs

[Frank Scheiner]

Hi Adrian,

Post by John Paul Adrian Glaubitz
==================================================================================
Installing on a FAT filesystem does not work at all. grub-install actually refuses
the installation if the target directory for --macppc-directory is not an HFS/HFS+
filesystem.

Oh it works - or let's say it worked for me back when I tested it in
2018 on a Mac mini G4 and a 11,2 Power Mac G5.

According to the relevant line in my PR ([1]) you have to omit
`--macppc-directory` from the `grub-install` command.

[1]:
https://salsa.debian.org/frank-scheiner-guest/grub-installer/-/commit/cfe145228adaa34aae780cbb527dce5408107083#ae6e84c2dbfeefe14b039001e1b64254dada292b_895_899

Cheers,
Frank

[John Paul Adrian Glaubitz]

Hello!

Post by Frank Scheiner

Post by John Paul Adrian Glaubitz
==================================================================================
Installing on a FAT filesystem does not work at all. grub-install actually refuses
the installation if the target directory for --macppc-directory is not an HFS/HFS+
filesystem.

Oh it works - or let's say it worked for me back when I tested it in
2018 on a Mac mini G4 and a 11,2 Power Mac G5.
According to the relevant line in my PR ([1]) you have to omit
`--macppc-directory` from the `grub-install` command.
https://salsa.debian.org/frank-scheiner-guest/grub-installer/-/commit/cfe145228adaa34aae780cbb527dce5408107083#ae6e84c2dbfeefe14b039001e1b64254dada292b_895_899

That makes no sense as this parameter just provides the path to the HFS
filesystem. If you don't provide this paramemter, how is grub-install
supposed to know where to install the files?

However, the problem is that GRUB has only a bless command but no command
to set the tbxi attribute on the BootX bootloader file as explained here [1].

Adrian

Post by Frank Scheiner
[1] https://github.com/apple-oss-distributions/bless/blob/main/README.BOOTING

[Frank Scheiner]

Hello again,

Post by John Paul Adrian Glaubitz
Hello!

Post by Frank Scheiner

Post by John Paul Adrian Glaubitz
==================================================================================
Installing on a FAT filesystem does not work at all. grub-install actually refuses
the installation if the target directory for --macppc-directory is not an HFS/HFS+
filesystem.

Oh it works - or let's say it worked for me back when I tested it in
2018 on a Mac mini G4 and a 11,2 Power Mac G5.
According to the relevant line in my PR ([1]) you have to omit
`--macppc-directory` from the `grub-install` command.
https://salsa.debian.org/frank-scheiner-guest/grub-installer/-/commit/cfe145228adaa34aae780cbb527dce5408107083#ae6e84c2dbfeefe14b039001e1b64254dada292b_895_899

That makes no sense as this parameter just provides the path to the HFS
filesystem. If you don't provide this paramemter, how is grub-install
supposed to know where to install the files?

As per `grub-install(8)`:

```
grub-install copies GRUB images into boot/grub.
```

As the call to `grub-install` is performed by `chroot` inside the root
FS of the new installation, I assume the FAT bootstrap partition is
already mounted as `/boot` at this time of the installation. I think
this happens after all data partitions were formatted earlier during the
Debian installation but before any files are installed. Thus making the
call succeed w/o an explicit boot device or target directory argument.

Cheers,
Frank

[Lennart Sorensen]

Post by Frank Scheiner
```
grub-install copies GRUB images into boot/grub.
```
As the call to `grub-install` is performed by `chroot` inside the root
FS of the new installation, I assume the FAT bootstrap partition is
already mounted as `/boot` at this time of the installation. I think
this happens after all data partitions were formatted earlier during the
Debian installation but before any files are installed. Thus making the
call succeed w/o an explicit boot device or target directory argument.

I am pretty sure /boot can NOT be fat since it has to store files from
packages (like the kernel). /boot/grub on the other hand might be able
to be fat. Similar to how you can have /boot/efi be fat on x86 but not
/boot itself.

[Frank Scheiner]

Post by Lennart Sorensen

Post by Frank Scheiner
```
grub-install copies GRUB images into boot/grub.
```
As the call to `grub-install` is performed by `chroot` inside the root
FS of the new installation, I assume the FAT bootstrap partition is
already mounted as `/boot` at this time of the installation. I think
this happens after all data partitions were formatted earlier during the
Debian installation but before any files are installed. Thus making the
call succeed w/o an explicit boot device or target directory argument.

I am pretty sure /boot can NOT be fat since it has to store files from
packages (like the kernel). /boot/grub on the other hand might be able
to be fat. Similar to how you can have /boot/efi be fat on x86 but not
/boot itself.

Right, that makes more sense. When the OF bootstrap partition is a HFS
partition, it's mounted on `/boot/grub`, too. Thanks for pointing that out.

Cheers,
Frank

[Linux User #330250]

Okay, so this whole issue got me thinking...

I couldn't find a way to boot from FAT because it doesn't support
blessing a file. I also couldn't find a default boot file, e.g. some
bootinfo.txt or similar (boot.b, boot.bootinfo, boot.xcoff, ??) that
Open Firmware would default to and use in case of FAT (with no chance to
bless a file). Such filename would have to be hard-coded in OF.

It seems, the only real convenient way to go remains HFS or HFS+. Which
got me thinking...

We could make a /binary image/ of a pre-configured HFS partition with a
version of GRUB installed and configured to search for the real
configfile to use for booting on any supported filesystem (not only
ext2/3/4; only limited by available GRUB file system support modules).
This image could be dd'ed to a target "NewWorld Bootblock" partition,
and OF would find and load the blessed GRUB on it (as pre-configured in
the HFS image). This GRUB would then search for a pre-defined UUID
filesystem with the real grub.cfg on it.

The only thing that would have to be done during installation is to make
/boot the right pre-configured UUID, so grub from the HFS binary image
will load grub.cfg from it.


OF3+
--> HFS NewWorld Bootblock: blessed bootinfo-style GRUB, hardcoded UUID
--> finds grub.cfg on [ext2/3/4, xfs, btfs, etc. /boot] and loads it
--> boot selected OS


Installation steps:
1. create NewWorld Bootblock anywhere on fresh or existing HDD
2. copy binary image of pre-configured image HFS+GRUB
3. create /boot of supported fs, with UUID used in image from step 2
4. Linux only ever needs to manage grub.cfg on /boot


This would transfer the need to non-free HFS utilities to be used by the
package maintainer only, who has to create the NewWorld Bootblock HFS
image and bless the bootinfo/GRUB2 bootloader file. The target system
installing the prepared image then doesn't need to use any HFS tools...

If GRUB would support something else instead of a filesystem UUID, we
could also use a partition type or something similar in the
pre-configured binary image for the NewWorld Bootblock HFS image...

BTW, apparently this guide uses such a way also, not blessing anything
on ext2, as previously (wrongly) suggested in this discussion:
https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC)

IMHO for the OS Picker to work intuitively, an icon via a blessed
bootinfo file is key... (to be included in the NewWorld Bootblock HFS
image by the maintainer...)

Any thoughts?
Greetings, Linux User #330250


Some useful links:
https://flylib.com/books/en/2.316.1.51/1/ -- The Hardware Boot Process
https://flylib.com/books/en/3.126.1.47/1/ -- BootX
https://lowendmac.com/2018/installing-linux-on-powerpc-macs/

[John Paul Adrian Glaubitz]

Hello!

Perhaps GRUB could use whatever yaboot uses to create the
Apple_Bootstrap partition and bless it with ybin, or was yaboot
violating Debian license rules with its ybin and use of HFS? Similarly,
perhaps GRUB could be enabled to boot Mac OS X or Mac OS 9 volumes in
the same way that yaboot already does.
https://github.com/arnew/yaboot/blob/master/ybin/ybin#L909
https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer#L1035

I could switch debian-installer completely to using hfsutils but that
would be rather hacky since then the partitioner wouldn't know about HFS
and would have to format the partition with FAT first, then have grub-installer
reformat the partition with hfsutils.

It would be easier if hfsutils provided standard filesystem commands such
as mkfs.hfs and fsck.hfs as this is what debian-installer expects.

Either way (GRUB or yaboot), I will continue to have only a very basic
configuration, with one entry per partition, with the kernel always
vmlinux (or vmlinuz) and the initrd always initrd.img, with symbolic
links in /boot on the relevant partitions pointing to the real kernel
and initrd.img that I want to use. I don't need GRUB to maintain a list
of all the kernels that I keep in /boot, and this way I have a
consistent way to use GRUB (and make it work like yaboot) on all
architectures that support GRUB.

That's fine but the idea of using GRUB is to make the PowerPC port more
aligned with standard Debian so that users don't have to mess with another
bootloader. Also, Yaboot is unmaintained and doesn't work with modern versions
of ext4 and so on.

Adrian

[Linux User #330250]

Post by Linux User #330250
Any thoughts?
...

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).
I'm not planning to use GRUB as long as I can't use it to pick Mac OS X
and Mac OS 9 volumes from the menu like I can with yaboot.

The NewWorld Bootblock would not ever be mounted on Linux. It wouldn't
contain anything useful for Linux anyway, as the sole purpose of it
would be to load the configfile from the real /boot partition, which
would be ext2/3/4 or anything else usable by Linux, containing not only
grub.cfg, but also the Linux kernels (the usual /boot).

In that accessible grub.cfg one would be able to include Mac OS X...

Perhaps GRUB could use whatever yaboot uses to create the
Apple_Bootstrap partition and bless it with ybin, or was yaboot
violating Debian license rules with its ybin and use of HFS? Similarly,
perhaps GRUB could be enabled to boot Mac OS X or Mac OS 9 volumes in
the same way that yaboot already does.

As I understood it, the problem is that the parts required to do that
are non-free...

Either way (GRUB or yaboot), I will continue to have only a very basic
configuration, with one entry per partition, with the kernel always
vmlinux (or vmlinuz) and the initrd always initrd.img, with symbolic
links in /boot on the relevant partitions pointing to the real kernel
and initrd.img that I want to use. I don't need GRUB to maintain a list
of all the kernels that I keep in /boot, and this way I have a
consistent way to use GRUB (and make it work like yaboot) on all
architectures that support GRUB.

GRUB has a lot of advantages over yaboot. Not only does it allow many
more boot options, it also allows to edit the kernel commandline, which
is great to test various options without making them permanent in the
boot configuration files.

Linux User #330250

[John Paul Adrian Glaubitz]

Hi!

Post by Linux User #330250

Perhaps GRUB could use whatever yaboot uses to create the
Apple_Bootstrap partition and bless it with ybin, or was yaboot
violating Debian license rules with its ybin and use of HFS? Similarly,
perhaps GRUB could be enabled to boot Mac OS X or Mac OS 9 volumes in
the same way that yaboot already does.

As I understood it, the problem is that the parts required to do that
are non-free...

Yes, that is the main problem. FWIW, I have reached out to Apple's Legal
Department and asked them whether it would be possible to relicense the
»hfs« package under a more permissive license such as MIT or any of the
BSD licenses.

The source code for the HFS(+) filesystem utilities used to be part of the
»diskdev_cmds« [1] package but was later split into its own package called
»hfs« [2].

I argued that the »hfs« package is required for interoperability and it would
make it for distributions much easier to ship the »hfs« package if its covered
by a truly free license.

I guess that the fact that the HFS code got split out of »diskdev_cmds« could
make it easier for Apple to change the license.

Adrian

Post by Linux User #330250
[1] https://github.com/apple-opensource/diskdev_cmds
[2] https://github.com/apple-opensource/hfs

[John Paul Adrian Glaubitz]

Hi!

Post by John Paul Adrian Glaubitz
Yes, that is the main problem. FWIW, I have reached out to Apple's Legal
Department and asked them whether it would be possible to relicense the
»hfs« package under a more permissive license such as MIT or any of the
BSD licenses.
The source code for the HFS(+) filesystem utilities used to be part of the
»diskdev_cmds« [1] package but was later split into its own package called
»hfs« [2].
I argued that the »hfs« package is required for interoperability and it would
make it for distributions much easier to ship the »hfs« package if its covered
by a truly free license.
I guess that the fact that the HFS code got split out of »diskdev_cmds« could
make it easier for Apple to change the license.

Alternatively, it would also help if Paragon released their HFS+ code [1] under a
free license. They have done that for their NTFS code already [2], so chances are
they would do it for the HFS+ stuff as well.

I have reached out to the Paragon developer who got the NTFS merged into the upstream
Linux kernel. Maybe they're willing to do that with the HFS+ code as well.

Adrian

Post by John Paul Adrian Glaubitz
[1] https://www.paragon-software.com/home/ntfs-linux-professional
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7464060f7ab9a2424428008f0ee9f1e267e410f

[Linux User #330250]

One more (quite long) follow-up: (sorry for the length!)

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

[John Paul Adrian Glaubitz]

Hello!

Post by Linux User #330250
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.

You're underestimating the number of times the GRUB package gets updated,
that happens a lot [1] which is why I don't think your suggestion to use a
static GRUB image is ever going to fly.

What we need is a free implementation of the HFS(+) utilities which is what
I am trying to achieve now. This is the only proper solution as it integrates
with the design of debian-installer.

Any other approaches like this hack to supply a static image would make things
much more complicated. In particular, I don't think the other maintainers within
debian-installer would be amused if I placed a static HFS image several hundred
megabytes inside into a udeb package that has currently an unpacked size of 168
kilobytes [2].

Adrian

Post by Linux User #330250
[1] https://buildd.debian.org/status/logs.php?pkg=grub2&arch=powerpc
[2] http://ftp.ports.debian.org/debian-ports/pool-powerpc/main/g/grub-installer/

[Linux User #330250]

Post by John Paul Adrian Glaubitz
You're underestimating the number of times the GRUB package gets updated,
that happens a lot [1] which is why I don't think your suggestion to use a
static GRUB image is ever going to fly.

I don't see that many GRUB version updates on Gentoo (on amd64). Maybe
from twice to three times a year, but not more. For this purpose a
version bump is from 2.04 to 2.06, but not from 2.06-12 to 2.06-13 if
the specific binaries aren't any different (it's still version 2.06)
Looking at https://ftp.gnu.org/gnu/grub/ version bumps are even rarer...

Post by John Paul Adrian Glaubitz
What we need is a free implementation of the HFS(+) utilities which is what
I am trying to achieve now. This is the only proper solution as it integrates
with the design of debian-installer.

Why are the respective packages maked "GPL-2" on Gentoo Linux then?

* sys-fs/hfsplusutils
Latest version available: 1.0.4-r3
Latest version installed: 1.0.4-r3
Size of files: 182 KiB
Homepage: http://penguinppc.org/historical/hfsplus/
Description: HFS+ Filesystem Access Utilities (a PPC filesystem)
License: GPL-2

* sys-fs/hfsutils
Latest version available: 3.2.6_p15
Latest version installed: 3.2.6_p15
Size of files: 210 KiB
Homepage: https://www.mars.org/home/rob/proj/hfs/
Description: HFS FS Access utils
License: GPL-2

Only diskdev_cmds is APSL-2 licensed (which to my knowledge is
considered a free license as well,
https://www.gnu.org/philosophy/apsl.html):

* sys-fs/diskdev_cmds
Latest version available: 332.14_p1-r4
Latest version installed: 332.14_p1-r4
Size of files: 719 KiB
Homepage: http://opendarwin.org
Description: HFS and HFS+ utils ported from OSX, supplies mkfs
and fsck
License: APSL-2


Utilities included in hfsutils are:
hattrib
hcd
hcopy
hdel
hdir
hformat
hfsck
hls
hmkdir
hmount
hpwd
hrename
hrmdir
humount
hvol

So, hformat to create the HFS volume, hcopy and hattrib to populate it
with the required boot files. And all is GPL-2 licensed...
https://www.mars.org/home/rob/proj/hfs/

Post by John Paul Adrian Glaubitz
Any other approaches like this hack to supply a static image would make things
much more complicated. In particular, I don't think the other maintainers within
debian-installer would be amused if I placed a static HFS image several hundred
megabytes inside into a udeb package that has currently an unpacked size of 168
kilobytes [2].

Understood. Yes, having the hfs utilities available will definitely help
a lot.

Linux User #330250

[John Paul Adrian Glaubitz]

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
You're underestimating the number of times the GRUB package gets updated,
that happens a lot [1] which is why I don't think your suggestion to use a
static GRUB image is ever going to fly.

I don't see that many GRUB version updates on Gentoo (on amd64). Maybe
from twice to three times a year, but not more. For this purpose a
version bump is from 2.04 to 2.06, but not from 2.06-12 to 2.06-13 if
the specific binaries aren't any different (it's still version 2.06)
Looking at https://ftp.gnu.org/gnu/grub/ version bumps are even rarer...

For one, Gentoo is not Debian. And secondly, you cannot just look at the
upstream sources since there are also many downstream changes in the Debian
package in the form of patches to fix compatibility issues, CVEs and so on.

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
What we need is a free implementation of the HFS(+) utilities which is what
I am trying to achieve now. This is the only proper solution as it integrates
with the design of debian-installer.

Why are the respective packages maked "GPL-2" on Gentoo Linux then?
* sys-fs/hfsplusutils
Latest version available: 1.0.4-r3
Latest version installed: 1.0.4-r3
Size of files: 182 KiB
Homepage: http://penguinppc.org/historical/hfsplus/
Description: HFS+ Filesystem Access Utilities (a PPC filesystem)
License: GPL-2
* sys-fs/hfsutils
Latest version available: 3.2.6_p15
Latest version installed: 3.2.6_p15
Size of files: 210 KiB
Homepage: https://www.mars.org/home/rob/proj/hfs/
Description: HFS FS Access utils
License: GPL-2

Because I am talking about Apple's »diskdev_cmds« and »hfs« packages, not the ones
you mentioned above which are both dead upstream, by the way. Apple's packages are
APSL which Debian considers non-free, unfortunately [1].

Post by Linux User #330250
Only diskdev_cmds is APSL-2 licensed (which to my knowledge is
considered a free license as well,
* sys-fs/diskdev_cmds
Latest version available: 332.14_p1-r4
Latest version installed: 332.14_p1-r4
Size of files: 719 KiB
Homepage: http://opendarwin.org
Description: HFS and HFS+ utils ported from OSX, supplies mkfs
and fsck
License: APSL-2

Not by Debian, see [1]. If you feel like convincing the Debian Legal team that
APSL is DFSG-compatible, please go ahead. I have given up on this.

Post by Linux User #330250
hattrib
hcd
hcopy
hdel
hdir
hformat
hfsck
hls
hmkdir
hmount
hpwd
hrename
hrmdir
humount
hvol
So, hformat to create the HFS volume, hcopy and hattrib to populate it
with the required boot files. And all is GPL-2 licensed...
https://www.mars.org/home/rob/proj/hfs/

hfsutils works like mtools, it doesn't use the kernel's VFS layer. Tools like "fsck"
and "mkfs" are still on the TODO list as you can see in the TODO file [2], quote:

»* write Linux utilities mkfs.hfs, fsck.hfs«.

This is also the reason why the yaboot-installer in Debian used a workaround to format
the boot partition with HFS. Normally that would happen in the installer's partitioning
tool and not in grub-installer (or yaboot-installer).

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
Any other approaches like this hack to supply a static image would make things
much more complicated. In particular, I don't think the other maintainers within
debian-installer would be amused if I placed a static HFS image several hundred
megabytes inside into a udeb package that has currently an unpacked size of 168
kilobytes [2].

Understood. Yes, having the hfs utilities available will definitely help
a lot.

Just having a fully working »hfsprogs« under a DFSG-compatible license available would
solve all the problems with the bootloader installation on Apple PowerMac, including
making the whole process much more robust and also compliant with the remaining archi-
tectures.

Adrian

Post by Linux User #330250
[1] https://wiki.debian.org/DFSGLicenses#Apple_Public_Source_License_.28APSL.29
[2] https://github.com/Distrotech/hfsutils/blob/master/TODO#L43

[Linux User #330250]

Post by John Paul Adrian Glaubitz
For one, Gentoo is not Debian. And secondly, you cannot just look at the
upstream sources since there are also many downstream changes in the Debian
package in the form of patches to fix compatibility issues, CVEs and so on.

Makes sense, but then if the minimal PowerPC-specific binary doesn't
change between package updates, a new image wouldn't be necessary.

I get the other issue though (additional big package and additional work
required by maintainer), which is unnecessary if the mkfs tool for hfs
was available...


BTW, a workaround similar to the one yaboot may use would be to only
have an image of an empty HFS volume (of fixed size) as a package, and
use the free (now unmaintained, but who cares?) hfsutils hcopy and
hattrib for the rest. Re-initializing the image would only make it
necessary to recopy the boot files. All that's missing is mkfs and fsck,
both are not required if we were to use an image of an empty HFS filesystem.

Post by John Paul Adrian Glaubitz
Because I am talking about Apple's »diskdev_cmds« and »hfs« packages, not the ones
you mentioned above which are both dead upstream, by the way. Apple's packages are
APSL which Debian considers non-free, unfortunately [1].

Thanks. I knew Debian is very restrictive, especially between free and
non-free, which is why I'm very much in favour of Debian in the first
place. The PITA on x86 always was the non-free firmware. Seeing how
Debian moved to include those non-free firmware blobs not very long ago
makes me wonder if such an exception wouldn't also be possible for
diskdev_cmds, since this seems quite essential on PowerPCs (just like
firmware blobs on x86).

How did Debian include the non-free firmware? Would there be a similar
way to get diskdev_cmds into the powerpc port?

Post by John Paul Adrian Glaubitz
Not by Debian, see [1]. If you feel like convincing the Debian Legal team that
APSL is DFSG-compatible, please go ahead. I have given up on this.

Well, reading the discussion about the license makes me be on their
side. But then, it's like the firmware blobs: in theory we don't want
them in a free operating system, but in reality we have not much of a
choice if we want to actually use the hardware...

Post by John Paul Adrian Glaubitz
hfsutils works like mtools, it doesn't use the kernel's VFS layer. Tools like "fsck"
and "mkfs" are still on the TODO list as you can see in the TODO file [2] ...

Thanks, I missed this important detail. hformat is just a stub, it
doesn't really do anything...

Post by John Paul Adrian Glaubitz
Just having a fully working »hfsprogs« under a DFSG-compatible license available would
solve all the problems with the bootloader installation on Apple PowerMac, including
making the whole process much more robust and also compliant with the remaining archi-
tectures.

Yes.

If I find the time, I'll play a bit with FAT formatted bootstrap
partitions. Maybe something undocumented actually works. I hate the idea
though that a NVRAM bootdevice setting would be necessary, I very much
prefer an out-of-the-box OS Picker compatible way. But since :tbxi is a
no-go with FAT, I honestly doubt that there is...


Linux User #330250

[John Paul Adrian Glaubitz]

Post by Linux User #330250
BTW, a workaround similar to the one yaboot may use would be to only
have an image of an empty HFS volume (of fixed size) as a package, and
use the free (now unmaintained, but who cares?) hfsutils hcopy and
hattrib for the rest. Re-initializing the image would only make it
necessary to recopy the boot files. All that's missing is mkfs and fsck,
both are not required if we were to use an image of an empty HFS filesystem.

If I am going this way, I can also just use hformat. But again, this does not integrate well with the partitioning tool in debian-installer and will confuse users.

Any code design that does not build on mkfs.hfs or mkfs.hfsplus will be opaque to users.

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
Because I am talking about Apple's »diskdev_cmds« and »hfs« packages, not the ones
you mentioned above which are both dead upstream, by the way. Apple's packages are
APSL which Debian considers non-free, unfortunately [1].

Thanks. I knew Debian is very restrictive, especially between free and
non-free, which is why I'm very much in favour of Debian in the first
place. The PITA on x86 always was the non-free firmware. Seeing how
Debian moved to include those non-free firmware blobs not very long ago
makes me wonder if such an exception wouldn't also be possible for
diskdev_cmds, since this seems quite essential on PowerPCs (just like
firmware blobs on x86).
How did Debian include the non-free firmware? Would there be a similar
way to get diskdev_cmds into the powerpc port?

The problem is that the Debian Ports infrastructure currently does not support non-free. Plus, debian-installer expects all of its components to be part of the “main” section.

»hfsprogs-udeb« is the only udeb, i.e. d-i package in non-free and no one had ever move a udeb to non-free.

If it was that easy, I would have resolved that issue long ago. Unfortunately, it’s a hard problem.

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
Not by Debian, see [1]. If you feel like convincing the Debian Legal team that
APSL is DFSG-compatible, please go ahead. I have given up on this.

Well, reading the discussion about the license makes me be on their
side. But then, it's like the firmware blobs: in theory we don't want
them in a free operating system, but in reality we have not much of a
choice if we want to actually use the hardware...

Well, Apple could just relicense the split-out »hfs« package to MIT or any BSD license. They have the power to do so.

I could then switch the »hfsprogs« package from the »diskdev_cmds« to the split-out »hfs« package.

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
hfsutils works like mtools, it doesn't use the kernel's VFS layer. Tools like "fsck"
and "mkfs" are still on the TODO list as you can see in the TODO file [2] ...

Thanks, I missed this important detail. hformat is just a stub, it
doesn't really do anything...

Oh, I wasn’t aware of that.

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
Just having a fully working »hfsprogs« under a DFSG-compatible license available would
solve all the problems with the bootloader installation on Apple PowerMac, including
making the whole process much more robust and also compliant with the remaining archi-
tectures.

Yes.
If I find the time, I'll play a bit with FAT formatted bootstrap
partitions. Maybe something undocumented actually works. I hate the idea
though that a NVRAM bootdevice setting would be necessary, I very much
prefer an out-of-the-box OS Picker compatible way. But since :tbxi is a
no-go with FAT, I honestly doubt that there is…

Setting the firmware path in NVRAM works but is very fragile. We used it in the past until I actually learned how the NewWorld firmware finds the bootloader on disk.

Adrian

[Johannes Brakensiek]

Hi Adrian,

just wanted to thank you for your ongoing perservering and
knowledgeable effort to keep supporting PowerPCs!

I think you're on the right track! Even though I don't find time to
boot my PowerPCs often these days, each time I do I'm happy they `apt
upgrade` and still work.

So your work is highly appreciated! I think it's part of what makes
Debian great. Even though I understand the structures of Debian are not
always easy ones to work within.

Best
Johannes

[Linux User #330250]

Post by Frank Scheiner
Hi Adrian,
just wanted to thank you for your ongoing perservering and
knowledgeable effort to keep supporting PowerPCs!
I think you're on the right track! Even though I don't find time to
boot my PowerPCs often these days, each time I do I'm happy they `apt
upgrade` and still work.
So your work is highly appreciated! I think it's part of what makes
Debian great. Even though I understand the structures of Debian are not
always easy ones to work within.
Best
Johannes

I would like to second that: Adrian, thanks for the hard work to keep
Debian powerpc alive!

I also don't turn my PowerMacs on that often these days. Non-the-less,
and even more so when I do, Adrian, your work is very much appreciated.

Linux User #330250

[Karl]

I would second that also. Unfortunately, PowerPC support is dwindling from year to year. There are only a handful of distributions left that support big-endian. I’m using ppc64le myself.

Thank you!

Post by Linux User #330250

Post by Frank Scheiner
Hi Adrian,
just wanted to thank you for your ongoing perservering and
knowledgeable effort to keep supporting PowerPCs!
I think you're on the right track! Even though I don't find time to
boot my PowerPCs often these days, each time I do I'm happy they `apt
upgrade` and still work.
So your work is highly appreciated! I think it's part of what makes
Debian great. Even though I understand the structures of Debian are not
always easy ones to work within.
Best
Johannes

I would like to second that: Adrian, thanks for the hard work to keep
Debian powerpc alive!
I also don't turn my PowerMacs on that often these days. Non-the-less,
and even more so when I do, Adrian, your work is very much appreciated.
Linux User #330250

[John Paul Adrian Glaubitz]

Hello Karl!

Post by Karl
I would second that also. Unfortunately, PowerPC support is dwindling
from year to year. There are only a handful of distributions left that
support big-endian. I’m using ppc64le myself.

IBM is actually still maintaining support for both endianesses upstream
in the kernel, the toolchain and so on. Their own Unix, AIX, continues
to be big-endian by default, so they actually have a reason to keep
big-endian PowerPC supported.

Adrian

[John Paul Adrian Glaubitz]

Post by Linux User #330250
I would like to second that: Adrian, thanks for the hard work to keep
Debian powerpc alive!
I also don't turn my PowerMacs on that often these days. Non-the-less,
and even more so when I do, Adrian, your work is very much appreciated.

Thanks. And I also appreciate your input, too. Discussion helps finding
the best solution.

Adrian

[John Paul Adrian Glaubitz]

Hi Johannes!

Post by Johannes Brakensiek
just wanted to thank you for your ongoing perservering and
knowledgeable effort to keep supporting PowerPCs!
I think you're on the right track! Even though I don't find time to
boot my PowerPCs often these days, each time I do I'm happy they `apt
upgrade` and still work.
So your work is highly appreciated! I think it's part of what makes
Debian great. Even though I understand the structures of Debian are not
always easy ones to work within.

Thanks for the kind words, I appreciate the praise.

I don't use old PowerMacs as my daily drivers either. However, I enjoy
working on the code and keeping these machines alive. I have learned a
lot along the way which is also one of my main motivations.

I understand very much when users are frustrating that the installer has
still rough edges, I'm frustrated by this as well. But as you can see,
the whole situation around HFS(+) is complicated, both considering the
code as well as the licenses.

I have actually looked into Apple's latest version of »hfs« [1] now and I'm
trying to port it to Linux using the patches from Matthew Garret for the
diskdev_cmds package (version 540.11).

If Apple decides to change the license for »hfs«, we will be able to switch
to that codebase immediately.

Adrian

Post by Johannes Brakensiek
[1] https://github.com/apple-opensource/hfs

[Linux User #330250]

Post by John Paul Adrian Glaubitz

Post by Linux User #330250

Post by John Paul Adrian Glaubitz
hfsutils works like mtools, it doesn't use the kernel's VFS layer. Tools like "fsck"
and "mkfs" are still on the TODO list as you can see in the TODO file [2] ...

Thanks, I missed this important detail. hformat is just a stub, it
doesn't really do anything...

Oh, I wasn’t aware of that.

Sorry, I was wrong. I missed it in the source code. Actually, the format
function hfs_format can be found in libhfs/hfs.c from the hfsutils
sources. But it looks ugly, because it includes partition management
(like selecting the number of APM partition to format on a block device).

We could make a wrapper script mkfs.hfs that utilizes hformat and
normalizes its usage though...

Linux User #330250

[Linux User #330250]

I don't know anything about Apple_Boot, but you are likely right that it
is also hidden from Mac OS 9 and Mac OS X. It appears Apple_Bootstrap is
used only by NewWorld PowerPC Macs. It's just an HFS-formatted partition
that is type Apple_Bootstrap instead of Apple_HFS, so while it can be
mounted manually by Mac OS X, it isn't accessible by default. And I
don't think it shows up in the boot selector menu (option key at boot).

Apple_Boot, Apple_Bootstrap, Apple_HFS, Apple_HFSX... doesn't matter for
the OS Picker to list it. Only the filesystem is important (HFS and HFS+
support blessing), and if there's a blessed CHRP boot script or not.

All you need to add is a CHRP boot script to make it appear on the OS
Picker screen.

That's actually easy: no matter what your boot file is, it's probably
blessed. So, find which file that is. As an example, this might be grub.bin.

So, now simply create a text file of any filename (it really doesn't
matter!) with the following content:

<CHRP-BOOT>
<COMPATIBLE>
MacRISC MacRISC3 MacRISC4
</COMPATIBLE>
<OS-NAME>
Debian GNU/Linux
</OS-NAME>
<BOOT-SCRIPT>
" screen" output
load-base release-load-area
boot &device;,grub.bin
</BOOT-SCRIPT>
</CHRP-BOOT>

Now, simply bless the CHRP boot script filename instead of the original
one (grub.bin in the example). The CHRP script loads whatever you
specify, so in the example the original grub.bin...

Next time you boot, hold the option key and you should now see "Debian
GNU/Linux" (or whatever you wrote in the <OS-NAME> field) as one option
(with no icon). The important part really is that the <COMPATIBLE> field
matches the actual hardware -- if it doesn't, it won't be shown by the
OS Picker.

Look at https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC) for
an example with the GNU icon, and also how to bless the CHRP boot script.

The last time I installed Debian SID with GRUB on a PowerBook Pismo, the
Apple_Bootstrap partition was mounted as /boot/grub (it might have been
/boot, I don't remember now). But it was a persistent mount. Everything
worked, except Mac OS and Mac OS X volumes could not be boot from the
menu (booting Mac OS X also doesn't work on an Intel Core 2 Duo system).

Actually, I was able to boot Mac OS X from GRUB. But if I remember
correctly, I had to play with it a bit as it isn't intuitive...
os-prober might be helpful as a starting point.

Unfortunately, I don't have the programming skills to fix it. If anyone
has found or developed working grub.cfg entries that allow booting of
Mac OS X and Mac OS 9, please let me know, as I would prefer to use GRUB
if I can. Also, if anyone has GRUB working on a PowerBook Lombard,
please let me know (AFAIK, that's the only NewWorld PowerMac that
doesn't work at all with GRUB; its Firmware version may be too old for
something that GRUB is doing.)

The oldest hardware I own is a Clamshell, original 1999 edition without
firewire. I have getting Debian installed on it on my "hobby to-do
list", but haven't found the time yet.

Linux User #330250

[Linux User #330250]

The GRUB Manual [1] says that the PPC port of GRUB only supports booting Linux at the moment. AFAIK booting macOS with GRUB on x86 machines works by just chainloading macOS' UEFI bootloader. I assume this is what yaboot does as well, telling Open Firmware to load OS X's blessed binary instead of the second stage of yaboot and Linux from there. All we need to do is find a way to support Open Firmware chainloading from within GRUB.

Yes, I had it working on an Intel Mac.

Thanks for the information. GRUB chainloading support works for x86 (to
boot Windows and NetBSD). Despite considerable effort, I've never been
able to get chainloading to work on New World PowerMacs (consistent with
the link you sent). Surprisingly, I also couldn't get Mac OS X booting
to work on x86_64 (e.g. Intel Core 2 Duo MacBook) systems. To undo the
automatic updating of GRUB during Debian "apt-upgrade" and "apt
dist-upgrade", I have a working grub.cfg files on x86 (e.g. i686) and
x86_64 systems that don't need to run Mac OS X -- for such systems, I
can simply copy my known-good grub.cfg.save to grub.cfg and re-run "grub
install /dev/sda" (for x86) or just "grub-install" for EFI-based x86_64
systems that don't need to run Mac OS X. Even if holding the option key
at boot works on all Macs, I consider that a fallback and don't
necessarily want to be at the system console to pick an OS. An expert
knowledgeable in both GRUB and yaboot could probably figure out how to
get GRUB to do what yaboot has done for decades.

You can always put in some "static" configuration under
/etc/grub.d/99something.

I have some scripts of my own there, with my static configuration preset
before the automatic grub-install generated stuff. This way, my primary
options on x86/amd64 are at the top, a) Windows and b) Linux.

I don't know about Debian at this point (my Debian Laptop is in the
other room), but on Gentoo I have the following files in /etc/grub.d:
00_header -- basically all the main configuration (like the colors)
01_pager -- (only includes "set pager=1")
05_separator -- (I'll explain it later)
05_static -- my static Linux configuration
09_separator
10_linux -- the pre-installed grub-mkconfig part
20_linux_xen -- the same for Xen
29_separator
30_os-prober -- the same for os-prober
30_uefi-firmware -- UEFI firmware settings, i.e. boot into BIOS setup
40_custom -- just empty stubs
41_custom -- " "
99_separator

Only executable files will be included (so it's relatively easy to
disable one script from /etc/grub.d -- e.g simply run chmod a-x
05_static to disable it...)

So, what grub-install normally does, is run 10_linux, which will get all
the installed Linux kernels and initrds from /boot, make a list and put
them into your grub.cfg, with the default options found in
/etc/default/grub. BUT, before that I have 05_static, which is my own
personal Linux config.

All the nn_separator files (like 05_separator) are symlinks to
.separator, which is a file in the same directory and has this content:

#!/bin/sh
exec tail -n +6 $0
# This file provides an easy way to add custom menu entries. Simply
type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry " ----------------------------------------" --class separator {
echo ' Please select a bootable entry. Return...'
}

So, what this does, is: it makes nice & clean --------- line entries to
separate all the different sections in the GRUB menu. Should you select
it and press Enter/Return, it will just display "Please select a
bootable entry." (The .separator file is executable, so every
nn_separator symlink is always included by grub-mkconfig...)

And here's what my 05_static looks like:

#! /bin/sh
set -e

# /etc/grub.d/05_static
# Revision: 2023-03-29

prefix="/usr"
exec_prefix="/usr"
datarootdir="/usr/share"

export TEXTDOMAIN=grub
export TEXTDOMAINDIR="${datarootdir}/locale"

. "$pkgdatadir/grub-mkconfig_lib"

gettext_printf "Adding static boot menu entries ...\n" >&2

GENTOO_STATIC_INITSYS="/usr/lib/systemd/systemd"

#GENTOO_STATIC_BOOTDEV="crypt_root=UUID=aaaaaaaa-bbbb-cccc-9999-000000000000
root_trim=yes dolvm dobtrfs root=UUID=11111111-2222-4444-aaaa-ffffffffffff"
####
#### UUIDs
####
GENTOO_STATIC_EFI_UUID="1234-A1B2" # /boot/efi
GENTOO_STATIC_BOOT_UUID="fedcba09876543211234567890abcdef" # /boot
GENTOO_STATIC_CRYPT_UUID="aaaaaaaa-bbbb-cccc-9999-000000000000" # LUKS
GENTOO_STATIC_ROOT_UUID="11111111-2222-4444-aaaa-ffffffffffff" # /

GENTOO_STATIC_CRYPT_ROOT="UUID=$GENTOO_STATIC_CRYPT_UUID" # LUKS partition
GENTOO_STATIC_REAL_ROOT="UUID=$GENTOO_STATIC_ROOT_UUID" # /
GENTOO_STATIC_BOOTDEV="crypt_root=$GENTOO_STATIC_CRYPT_ROOT
root_trim=yes dolvm dobtrfs root=$GENTOO_STATIC_REAL_ROOT"


GENTOO_STATIC_DEFAULT_NOMITIGATIONS="mitigations=off vsyscall=none
init_on_alloc=0 init_on_free=0 page_table_check=off hardened_usercopy=off"
GENTOO_STATIC_DEFAULT_MITIGATIONS="mitigations=auto,nosmt l1tf=full
vsyscall=none init_on_alloc=1 init_on_free=1 page_table_check=on
hardened_usercopy=on"
GENTOO_STATIC_FEATURES="psi=1 mem_encrypt=on efi=noruntime"
#GENTOO_TEMP_FEATURES="i8042.notimeout i8042.nomux"
#GENTOO_TEMP_FEATURES="pci=realloc=on
efi=noruntime,disable_early_pci_dma efi_pstore.pstore_disable=1"
GENTOO_TEMP_FEATURES="amd_pstate=active"
GENTOO_STATIC_DEFAULT="$GENTOO_STATIC_DEFAULT_MITIGATIONS
$GENTOO_STATIC_FEATURES $GENTOO_TEMP_FEATURES"
GENTOO_EXPERIMENTAL_FEATURES=""

GENTOO_STATIC_CMDLINE="init=$GENTOO_STATIC_INITSYS ro
$GENTOO_STATIC_BOOTDEV $GENTOO_STATIC_DEFAULT"

GENTOO_STATIC_ADDITIONAL_INITRD=""

LABEL="[W]indows 11"
HOTKEY="w"
cat << EOF
menuentry '$LABEL' --hotkey=$HOTKEY --class windows --class os
\$menuentry_id_option 'gentoo-static-efibootmgr-$GENTOO_STATIC_EFI_UUID' {
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root $GENTOO_STATIC_EFI_UUID
chainloader /efi/Microsoft/Boot/bootmgfw.efi
savedefault
}
EOF

LABEL="[G]entoo"
HOTKEY="g"
cat << EOF
menuentry '$LABEL' --hotkey=$HOTKEY --class gentoo --class gnu-linux
--class gnu --class os \$menuentry_id_option
'gentoo-static-current-$GENTOO_STATIC_ROOT_UUID' {
load_video
insmod gzio
insmod part_gpt
insmod ext2
search --no-floppy --fs-uuid --set=root $GENTOO_STATIC_BOOT_UUID
echo 'Loading Gentoo GNU/Linux...'
linux /gentoo-kernel $GENTOO_STATIC_CMDLINE
echo 'Loading Initial Ramdisk...'
initrd $GENTOO_STATIC_ADDITIONAL_INITRD /gentoo-initramfs
savedefault
}
EOF

...

As you can see I set my options in this file by variable, like in
$GENTOO_STATIC_FEATURES and $GENTOO_TEMP_FEATURES

Of course, the settings from /etc/default/grub will be used by 10_linux
and 20_linux_xen, and I keep them almost the same, but to experiment
with options (like lately the new amd_pstate driver) I use 05_static. I
not only have "[G]entoo" in it but also "Gentoo [e]xperimental" (the
letter in brackets is the assigned hotkey), so I can quickly get what I
want. On an older system I also have various unsafe menu entries, that
turn off all meltdown and spectre mitigations ("... [u]nsafe") to gain
more speed (while not online, and only when running trusted programs).

This may seem like a lot of work, but in your case all you needed to do
would be to make your OS X GRUB entries static into a file similar to
mine (05_static, likely with less configuration variables; e.g.
04_macos) and you'd be all set. No longer any need to copy a
grub.cfg.save...

I only bring these points up whenever anyone goes on about how easy it
is to get GRUB working on New World PowerMacs. GRUB will never be an
acceptable replacement for some yaboot users as long as booting Mac OS
isn't supported (os-picker via holding the option key at boot isn't
sufficient). If you don't need to boot Mac OS and GRUB already does
everything you need, you should of course choose GRUB for a new
installation instead of the no-longer-maintained yaboot.

AFAIR yaboot does its magic within the CHRP boot script. It would be
relatively easy to add an option to load GRUB, I guess. The "chain"
would then start by choosing Mac OS (Classic), Mac OS X, or GRUB, via
the yaboot CHRP script. But then, GRUB would be only managing Linux.

So, that's probably not what you were suggesting...

I'll test a new installation of the latest Debian SID (with GRUB) on a
PowerBook Pismo with an unformatted disk and send an update in a
different thread (I specifically want to test whether the partition that
holds the real grub.cfg is normally hidden).

I hope I finally find the time to do the same on my Clamshell. Only, my
disk isn't empty, I already installed Mac OS X on it, which I want to keep.

Linux User #330250

[Linux User #330250]

Post by Linux User #330250
AFAIR yaboot does its magic within the CHRP boot script. It would be
relatively easy to add an option to load GRUB, I guess. The "chain"
would then start by choosing Mac OS (Classic), Mac OS X, or GRUB, via
the yaboot CHRP script. But then, GRUB would be only managing Linux.

That makes a lot more sense now. The "first stage" of yaboot where you
select Linux, OS X, or CD Boot is actually a script run by Open
Firmware, > and that's how it can so easily chainload, since it's just
a script
selecting which binary for Open Firmware to load.
In that case, instead of trying to integrate chainloading functionality
into GRUB itself, we could just set a similar script to run before GRUB
that allows you to make that selection.

I have just tested this concept. I wiped my iMac G3, installed OS X and
Debian, and put a modified version of yaboot's stage 1 script in the
bootstrap partition and blessed it. Now I am greeted with a screen that
asks me if I'd like to boot into Linux, OS X, or whatever's in the CD
drive, and all of the options work, the Linux one loading right into
GRUB. If I don't select an option after a bit it defaults to GRUB.
This combines the convenience of yaboot with the versatility of GRUB,
and only requires a single (relatively) human readable and editable
file. The script is attached; the only change you should have to make is
of the partition numbers, as it currently assumes /boot/grub is on
partition 2 and OS X is on partition 3.
--
Ben Westover

Nice work!

The only thing that I can think of that might make the script slightly
better was if you used &device; for \grub, because this should default
to the current partition (where stage1 is on), and this is presumably
where GRUB is as well...

I.e., the line stating with ": bootgrub" would look like this:
: bootgrub " Loading GRUB..." .printf 100 ms load-base release-load-area
" &device;,\grub" $boot ;

I'll definitely use this when I get around to installing Linux on my
Clamshell...

Thanks!
Linux User #330250

[Linux User #330250]

It turns out that adding &device; alone is not enough since it refers to
only the drive and not the partition along with it. &device;:&partition;
is what was actually needed. Fixed script is attached.

Wow. Thanks. On my Power Mac G5, &device; alone always worked. Strange.

One thing that concerns me a bit is putting Linux's CHRP boot script
into /System/Library/CoreServices/BootX, which is specific to Mac OS X.
Why is this necessary?

On my Macs, with my personal installations, I tend to install more than
one Mac OS (X). Each OS version has its own partition (including
"Classic"), and its own blessed files/folders. Mac OS X uses
/System/Library/CoreServices/BootX while Mac OS (up to 9.2.2) uses
"System Folder".

To me it makes sense to not copy what other OSes do. So, for Linux I use
more than one partition as it has always been the way, even on x86.
That's why, for my installations, I create an Apple_Boot (or
Apple_Bootstrap) partition just for Linux. It has my "stage1", my CHRP
boot script (along with a shiny icon) and my GRUB along with my initial
1st stage GRUB configuration. Why do I prefer this? Because now, the
CHRP script will be able to rely on &device; (and &partition;) to
identify itself, while I use GRUB on this partition to find my actual
Linux boot partition (which may or may not be the same as the root
partition). This is possible because GRUB supports finding partitions
and (Linux) filesystems based on their UUIDs rather than specifying
fixed disk/partition numbers. AFAIK GRUB supports a wide range of
filesystems, including ext2/3/4, HFS, HFS+, VFAT, exFAT, btrfs, ZFS, and
XFS. So my Linux root / and my Linux boot /boot can be on a partition of
any of those filesystems and GRUB will find it based on the UUID I have
it look for.

Now I can change the partition table without causing any damage to the
boot process, because a) my Linux HFS Apple_Boot partition contains a
blessed CHRP boot script, making it visible to the OS Picker, and b) the
included GRUB will look for the boot partition (and its 2nd-stage i.e.
real grub.cfg) UUID-based.

Apple_Boot --> CHRP boot script --> GRUB --> initial grub.cfg -->
/boot (found based on UUID) --> loads /grub/grub.cfg from it

So my real grub.cfg is on my /boot partition, which isn't the HFS
Apple_Boot partition, and which has a filesystem that suits Linux much
more than HFS, in my case ext4. My /boot contains grub.cfg, all the
different Linux kernels and the initramfs files. Naturally, this
grub.cfg now also supports booting anything else, should that work on
PowerPC, like booting *BSD (NetBSD?) and XNU (Mac OS X, but as stated
here before, PowerPC XNU booting isn't really working).

The desired result: whatever I do, I can always rely on the OS Picker to
get me a working installation of either Mac OS (both X and Classic) as
well as Linux (more than one distribution/installation, if need be),
even after removing a (i.e. Mac OS X) partition in front of the
Apple_Boot and /boot partitions...

The real reason for requiring the separate Apple_Boot(strap) HFS
partition for Linux is that OF doesn't support the filesystem Linux uses
for /boot, as well as the other way around: the filesystem wouldn't
support blessing.

So, yes, we could also use /System/Library/CoreServices/BootX as the
CHRP boot script path + filename, but why should we? For Open Firmware
this doesn't do anything at all, because OF only cares if a folder/file
is blessed or not...

Anyway, thanks for your work!

[Ben Westover]

Hello,

Post by Linux User #330250
One thing that concerns me a bit is putting Linux's CHRP boot script
into /System/Library/CoreServices/BootX, which is specific to Mac OS X.
Why is this necessary?

It's not necessary, it's just that the existing script placed by GRUB to
load itself is already in that location, so putting the new one there a)
removes the existing entry for GRUB and b) saves you a blessing step.
The only special thing I found about that particular spot is that none
of the PowerMacs I've used will display a blessed script on a USB drive
unless it's in that specific location. Another bonus is if the script is
in that directory along with a 'Volume Name Icon' file it will have a
nice label of your choosing under the icon like OS X does.

[Linux User #330250]

Post by Ben Westover
Hello,

Post by Linux User #330250
One thing that concerns me a bit is putting Linux's CHRP boot script
into /System/Library/CoreServices/BootX, which is specific to Mac OS X.
Why is this necessary?

It's not necessary, it's just that the existing script placed by GRUB to
load itself is already in that location, so putting the new one there a)
removes the existing entry for GRUB and b) saves you a blessing step.
The only special thing I found about that particular spot is that none
of the PowerMacs I've used will display a blessed script on a USB drive
unless it's in that specific location. Another bonus is if the script is
in that directory along with a 'Volume Name Icon' file it will have a
nice label of your choosing under the icon like OS X does.

Wow, thanks, I didn't know that. None of my PowerMacs support USB
booting (over the OS Picker). Well, the Late-2005 Power Mac G5 might,
but I think this is the only one. (The manual way over the OF command
line has always been possible...)[1]

In this case I take back what I previously wrote and state the opposite. ;-)

Given the possibility to put an internal disk into an external FireWire
or USB enclosure, it would make sense to keep it as compatible to the
supported boot process as possible. I know that Mac OS X is
hyper-compatible in this sense, it can boot from each and every internal
and external boot path. Very impressive. Considering how easy it is for
Mac OS X to boot from everywhere, Linux should be configured like this
as well...

So, if /System/Library/CoreServices/BootX is the way to make it
compatible on USB media, and additionally with the "Volume Name Icon"
file as means to labeling it for the OS Picker, I now think we should
definitely do that for Linux as well!

I think, Debian (and Gentoo; Linux on the PowerMac in general) should
make it's own Apple_Bootstrap (would Apple_Boot also work?) partition
with the mentioned files in order to be bootable no matter what.

I'm still in favor of UUIDs though. And I'm still in favor of
dynamically configuring the boot process to the actual UUIDs. Like Mac
OS X, Linux booting should still work if partition numbers and
identifiers change, like external HDD instead of internal, or like
inserting or deleting partitions in front of the Linux partitions...

Linux User #330250


[1] https://forums.macrumors.com/threads/the-open-firmware-wiki.2225024/

[Ed Robbins]

Hi Ben,

Post by Ben Westover
Hello,
It turns out that adding &device; alone is not enough since it refers to
only the drive and not the partition along with it. &device;:&partition;
is what was actually needed. Fixed script is attached.

I just tried this, and blessed the file with:

hmount /dev/sda2
hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX
humount

But I see no difference upon rebooting the machine. Am I missing something?

Thanks,
Ed

Post by Ben Westover
--
Ben Westover

[Ed Robbins]

Post by Ed Robbins
Hi Ben,

Post by Ben Westover
Hello,
It turns out that adding &device; alone is not enough since it refers to
only the drive and not the partition along with it. &device;:&partition;
is what was actually needed. Fixed script is attached.

hmount /dev/sda2
hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX
humount
But I see no difference upon rebooting the machine. Am I missing something?

I played a bit more (without changing anything). The behaviour I get now is:

If I just turn on the machine, it goes to the grub menu.
If I hold down alt, I can choose between debian (with a nice logo but
called "untitled"), Leopard and Tiger
-> OS X options both work
-> If I choose debian, I get a menu the same as the old yaboot
first menu: Press l for Linux, x for mac os, c for cdrom
-> x does boot mac os
-> l takes me to the grub menu

Thanks,
Ed

Post by Ed Robbins
Thanks,
Ed

Post by Ben Westover
--
Ben Westover

[John Paul Adrian Glaubitz]

Post by Ed Robbins
hmount /dev/sda2
hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX
humount
But I see no difference upon rebooting the machine. Am I missing something?

You actually did not bless the bootloader folder. From the grub-installer script [1]:

# hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX
# hattrib -b :System:Library:CoreServices

Adrian

Post by Ed Robbins
[1] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer?ref_type=heads#L1061

[Ed Robbins]

Hi Adrian,

On Wed, 2 Oct 2024 at 09:52, John Paul Adrian Glaubitz

Post by John Paul Adrian Glaubitz

Post by Ed Robbins
hmount /dev/sda2
hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX
humount
But I see no difference upon rebooting the machine. Am I missing something?

# hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX
# hattrib -b :System:Library:CoreServices

Thanks. Just gave this a try (running both those commands) and I'm
afraid the behaviour is still identical to what I described
previously.

I mean, holding down alt is not so bad honestly, and that seems to
"just work" with the standard grub install as far as I am aware.

Post by John Paul Adrian Glaubitz
Adrian

Post by Ed Robbins
[1] https://salsa.debian.org/installer-team/grub-installer/-/blob/master/grub-installer?ref_type=heads#L1061

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

[John Paul Adrian Glaubitz]

Hi Ed,

Post by Ed Robbins

Post by John Paul Adrian Glaubitz

Post by Ed Robbins
But I see no difference upon rebooting the machine. Am I missing something?

# hattrib -c UNIX -t tbxi :System:Library:CoreServices:BootX
# hattrib -b :System:Library:CoreServices

Thanks. Just gave this a try (running both those commands) and I'm
afraid the behaviour is still identical to what I described
previously.
I mean, holding down alt is not so bad honestly, and that seems to
"just work" with the standard grub install as far as I am aware.

I'm not 100% sure I understand what your problem is, can you elaborate this
again? I think you should also better create a new mailing list thread for
that since this seems to be a different problem.

Normally the firmware should detect and show all blessed bootloaders both in
the startup boot menu in the firmware and the startup selection of OSX.

The current default bootloader selection is stored in NVRAM separately.

In the past, we hard-wired the Open-Firmware path into NVRAM before I understood
what is actually necessary for a bootloader to be displayed and selectable in the
startup menu which are the two hattrib changes to bless a folder.

Every bootloader that has been blessed will automatically show up in the startup
screen and will be selectable.

But, again, please create a new thread for this and describe your problem in detail,
hijacking other threads often just results in such discussions being buried.

Adrian

[Paul Wise]

As for how this script could be integrated into Debian, it should
definitely not be put into the GRUB package. As Glaubitz has said,
the goal is for as little PowerPC-specific patches to be put into
these core packages as possible. GRUB's also not really the right
place for a script that runs before it to enable booting other OSes
more easily. It also wouldn't make sense to create a whole separate
package just for one script file. Since the script is unnecessary for
those who don't want to dual-boot, I don't know if it should really
be included in Debian at all.

What about including it in os-prober?

[Ben Westover]

Hello,

Post by Paul Wise

As for how this script could be integrated into Debian, it should
definitely not be put into the GRUB package. As Glaubitz has said,
the goal is for as little PowerPC-specific patches to be put into
these core packages as possible. GRUB's also not really the right
place for a script that runs before it to enable booting other OSes
more easily. It also wouldn't make sense to create a whole separate
package just for one script file. Since the script is unnecessary for
those who don't want to dual-boot, I don't know if it should really
be included in Debian at all.

What about including it in os-prober?

That's on the right track, but not quite. os-prober is just a program
that detects other OSes and reports where they are, it doesn't actually
install any files AFAIK. What we could actually do is put a hook in
debian-installer that runs os-prober and installs the script if it finds
any OS X or OS 9 installations. It could even use os-prober to find out
which partition(s) the OS(es) are on and modify the script accordingly.