Hello!

I have been working on getting the GRUB installation on PowerMacs fixed the past days which turned out to be far more tricky than I expected. As can be seen from the number of test images I have created so far [1], I have already been through quite a number of image rebuilds to get the grub-installer work correctly on PowerMac (ignore the timestamps in the folder names, the correct timestamps of the images can be seen from the creation date in the folder view).

The latest image is in the folder "hfstest-20210411-8" which I created this morning. This image is not tested yet, but it should actually work when looking at the script code itself [2] but it doesn't which is most likely attributed to a
race condition.

The problem is that setting the correct file properties with the hattrib tool fails at the first attempt of installing the bootloader but succeeds when just reattempting to install the bootloader from the installer menu. So far, I have not been able to find out why, that will require more debugging.

If anyone wants to give it a try themselves, please fetch the image from [1] (so far I created a 32-bit image only) and see if it works for you.

Note: After selecting the partition layout, the partioning tool will present
an empty question dialog which should be answered with <NO>. It's a known issue I will fix later, so just ignore it for now.

FWIW, I also found a number of bugs in GRUB on PowerMac itself while working
on the problem. It turns out that GRUB does not set the proper openfirmware path in NVRAM pointing to the BootX script that it just installed. The script gets installed into :System:Library:CoreServices:BootX but grub-install (the upstream GRUB installation tool) just sets the path to :BootX.

Also, while GRUB's grub-install blesses the "CoreServices" folder, it does
not set the "tbxi" attribute which means it's not possible to boot the disk with "boot hd:N,:\\tbxi" (N being the partition).

And, finally, GRUB's grub-install never substitutes the variable names "device" and "partition" in the boot script [3] it installs. They just remain as is on the disk which naturally means that grub-install currently cannot itself properly
install GRUB on a PowerMac which is obviously a bug.

Adrian

[1] https://cdimage.debian.org/cdimage/ports/tests/
[2] https://people.debian.org/~glaubitz/grub-installer.20210414
[3] http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boot/powerpc/grub.chrp.in

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello!

On 4/14/21 9:54 AM, John Paul Adrian Glaubitz wrote:

The latest image is in the folder "hfstest-20210411-8" which I created this morning. This image is not tested yet, but it should actually work when looking
at the script code itself [2] but it doesn't which is most likely attributed to a
race condition.

The problem is that setting the correct file properties with the hattrib tool fails at the first attempt of installing the bootloader but succeeds when just
reattempting to install the bootloader from the installer menu. So far, I have
not been able to find out why, that will require more debugging.

The problem is most likely related to hattrib being run with the chroot command which probably messes around the weird virtual mounting mechanism that the tool uses.

The easiest fix would probably be to build a hfsutils-udeb package and run the necessary HFS commands outside the chroot. I will try that later today.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Mark!

On 4/14/21 1:45 PM, Mark Cave-Ayland wrote:

On 14/04/2021 08:54, John Paul Adrian Glaubitz wrote:

Hello!

I have been working on getting the GRUB installation on PowerMacs fixed the >> past days which turned out to be far more tricky than I expected. As can be >> seen from the number of test images I have created so far [1], I have already
been through quite a number of image rebuilds to get the grub-installer work >> correctly on PowerMac (ignore the timestamps in the folder names, the correct
timestamps of the images can be seen from the creation date in the folder view).

Great work Adrian!

Thanks!

The latest image is in the folder "hfstest-20210411-8" which I created this >> morning. This image is not tested yet, but it should actually work when looking
at the script code itself [2] but it doesn't which is most likely attributed to a
race condition.

The problem is that setting the correct file properties with the hattrib tool
fails at the first attempt of installing the bootloader but succeeds when just
reattempting to install the bootloader from the installer menu. So far, I have
not been able to find out why, that will require more debugging.

If anyone wants to give it a try themselves, please fetch the image from [1] >> (so far I created a 32-bit image only) and see if it works for you.

Note: After selecting the partition layout, the partioning tool will present >> an empty question dialog which should be answered with <NO>. It's a known issue
I will fix later, so just ignore it for now.

FWIW, I also found a number of bugs in GRUB on PowerMac itself while working >> on the problem. It turns out that GRUB does not set the proper openfirmware >> path in NVRAM pointing to the BootX script that it just installed. The script
gets installed into :System:Library:CoreServices:BootX but grub-install (the >> upstream GRUB installation tool) just sets the path to :BootX.

I would expect this to work since BootX is simply the filename and so it is a relative path reference, presumably to the blessed CoreServices directory. Otherwise you'd end up using an absolute path in the form \path\to\BootX.

The problem was simply that the HFS filesystem had to be unmounted before accessing
with hfsutils. It works now. Currently performing the final test.

Also, while GRUB's grub-install blesses the "CoreServices" folder, it does >> not set the "tbxi" attribute which means it's not possible to boot the disk >> with "boot hd:N,:\\tbxi" (N being the partition).

That should be an easy fix now that you've got hattrib working:

hattrib -t tbxi -c chrp path/to/BootX

Not sure why to pass "-c chrp" here as all the instructions I have seen for PowerMac pass "-c UNIX".

I'm curious as to how grub-install currently handles the blessing of the CoreServices
directory for different filesystems - does it only attempt to bless the folder if it
detects a HFS/HFS+ filesystem?

Seems so. See the grub-install source code.

Finally it may be worth noting that if you omit the partition number then the firmware
will locate the first bootable partition itself which is the default value that OpenBIOS
uses, e.g.

boot hd:,\\:tbxi

I'm just using the path provided by "opathname" as this way we can install onto any type
of media instead of just hard disks.

And, finally, GRUB's grub-install never substitutes the variable names "device"
and "partition" in the boot script [3] it installs. They just remain as is on
the disk which naturally means that grub-install currently cannot itself properly
install GRUB on a PowerMac which is obviously a bug.

This shouldn't be needed. Having a look at grub.chrp.in from your link and ofboot.b

on some old Fedora ISOs I have lying around, these files are all CHRP boot scripts

i.e. XML surrounded by <CHRP-BOOT>...</CHRP-BOOT> tags.

IIRC it is part of the CHRP boot specification that the firmware substitutes the values
for "&device;" and "&partition;" in <BOOT-SCRIPT>...</BOOT-SCRIPT> when reading the CHRP
boot script into memory, and that's certainly what OpenBIOS does.

Ah, I wasn't aware of that.

I guess the real question is does Apple's OF do the right thing here? My feeling is that it
does, since grub.chrp.in uses the hard-coded path \System\Library\CoreServices\grub.elf
which is a directory that only exists if grub is installed on a MacOS computer.

I can try removing the sed command from grub-installer again and see if that still works.

Currently, I have:

sed -i 's!&device;:&partition;!'"$ofpath"'!g' $ROOT/boot/grub/System/Library/CoreServices/BootX

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/04/2021 08:54, John Paul Adrian Glaubitz wrote:

Hello!

I have been working on getting the GRUB installation on PowerMacs fixed the past days which turned out to be far more tricky than I expected. As can be seen from the number of test images I have created so far [1], I have already been through quite a number of image rebuilds to get the grub-installer work correctly on PowerMac (ignore the timestamps in the folder names, the correct timestamps of the images can be seen from the creation date in the folder view).

Great work Adrian!

The latest image is in the folder "hfstest-20210411-8" which I created this morning. This image is not tested yet, but it should actually work when looking
at the script code itself [2] but it doesn't which is most likely attributed to a
race condition.

The problem is that setting the correct file properties with the hattrib tool fails at the first attempt of installing the bootloader but succeeds when just
reattempting to install the bootloader from the installer menu. So far, I have
not been able to find out why, that will require more debugging.

If anyone wants to give it a try themselves, please fetch the image from [1] (so far I created a 32-bit image only) and see if it works for you.

Note: After selecting the partition layout, the partioning tool will present an empty question dialog which should be answered with <NO>. It's a known issue
I will fix later, so just ignore it for now.

FWIW, I also found a number of bugs in GRUB on PowerMac itself while working on the problem. It turns out that GRUB does not set the proper openfirmware path in NVRAM pointing to the BootX script that it just installed. The script gets installed into :System:Library:CoreServices:BootX but grub-install (the upstream GRUB installation tool) just sets the path to :BootX.

I would expect this to work since BootX is simply the filename and so it is a relative path reference, presumably to the blessed CoreServices directory. Otherwise
you'd end up using an absolute path in the form \path\to\BootX.

Also, while GRUB's grub-install blesses the "CoreServices" folder, it does not set the "tbxi" attribute which means it's not possible to boot the disk with "boot hd:N,:\\tbxi" (N being the partition).

That should be an easy fix now that you've got hattrib working:

hattrib -t tbxi -c chrp path/to/BootX

I'm curious as to how grub-install currently handles the blessing of the CoreServices
directory for different filesystems - does it only attempt to bless the folder if it
detects a HFS/HFS+ filesystem?

Finally it may be worth noting that if you omit the partition number then the firmware will locate the first bootable partition itself which is the default value
that OpenBIOS uses, e.g.

boot hd:,\\:tbxi

And, finally, GRUB's grub-install never substitutes the variable names "device"
and "partition" in the boot script [3] it installs. They just remain as is on the disk which naturally means that grub-install currently cannot itself properly
install GRUB on a PowerMac which is obviously a bug.

This shouldn't be needed. Having a look at grub.chrp.in from your link and ofboot.b
on some old Fedora ISOs I have lying around, these files are all CHRP boot scripts
i.e. XML surrounded by <CHRP-BOOT>...</CHRP-BOOT> tags.

IIRC it is part of the CHRP boot specification that the firmware substitutes the
values for "&device;" and "&partition;" in <BOOT-SCRIPT>...</BOOT-SCRIPT> when reading the CHRP boot script into memory, and that's certainly what OpenBIOS does.

I guess the real question is does Apple's OF do the right thing here? My feeling is
that it does, since grub.chrp.in uses the hard-coded path \System\Library\CoreServices\grub.elf which is a directory that only exists if grub
is installed on a MacOS computer.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 14/04/2021 12:53, John Paul Adrian Glaubitz wrote:

FWIW, I also found a number of bugs in GRUB on PowerMac itself while working
on the problem. It turns out that GRUB does not set the proper openfirmware >>> path in NVRAM pointing to the BootX script that it just installed. The script
gets installed into :System:Library:CoreServices:BootX but grub-install (the
upstream GRUB installation tool) just sets the path to :BootX.

I would expect this to work since BootX is simply the filename and so it is a
relative path reference, presumably to the blessed CoreServices directory. >> Otherwise you'd end up using an absolute path in the form \path\to\BootX.

The problem was simply that the HFS filesystem had to be unmounted before accessing
with hfsutils. It works now. Currently performing the final test.

Excellent!

Also, while GRUB's grub-install blesses the "CoreServices" folder, it does >>> not set the "tbxi" attribute which means it's not possible to boot the disk >>> with "boot hd:N,:\\tbxi" (N being the partition).

That should be an easy fix now that you've got hattrib working:

hattrib -t tbxi -c chrp path/to/BootX

Not sure why to pass "-c chrp" here as all the instructions I have seen for PowerMac pass "-c UNIX".

(goes and looks)

From what I can see there is a mixture of creator types: chrp is mentioned for FreeBSD and BootX, whilst most of the grub references suggest using UNIX. Having a
look around the OpenBIOS code I think the creator type is only used in the absence of
a blessed directory, so either will do fine.

I'm curious as to how grub-install currently handles the blessing of the CoreServices
directory for different filesystems - does it only attempt to bless the folder if it
detects a HFS/HFS+ filesystem?

Seems so. See the grub-install source code.

Finally it may be worth noting that if you omit the partition number then the firmware
will locate the first bootable partition itself which is the default value that OpenBIOS
uses, e.g.

boot hd:,\\:tbxi

I'm just using the path provided by "opathname" as this way we can install onto any type
of media instead of just hard disks.

And, finally, GRUB's grub-install never substitutes the variable names "device"
and "partition" in the boot script [3] it installs. They just remain as is on
the disk which naturally means that grub-install currently cannot itself properly
install GRUB on a PowerMac which is obviously a bug.

This shouldn't be needed. Having a look at grub.chrp.in from your link and ofboot.b

on some old Fedora ISOs I have lying around, these files are all CHRP boot scripts

i.e. XML surrounded by <CHRP-BOOT>...</CHRP-BOOT> tags.

IIRC it is part of the CHRP boot specification that the firmware substitutes the values
for "&device;" and "&partition;" in <BOOT-SCRIPT>...</BOOT-SCRIPT> when reading the CHRP
boot script into memory, and that's certainly what OpenBIOS does.

Ah, I wasn't aware of that.

I guess the real question is does Apple's OF do the right thing here? My feeling is that it
does, since grub.chrp.in uses the hard-coded path \System\Library\CoreServices\grub.elf
which is a directory that only exists if grub is installed on a MacOS computer.

I can try removing the sed command from grub-installer again and see if that still works.

Currently, I have:

sed -i 's!&device;:&partition;!'"$ofpath"'!g' $ROOT/boot/grub/System/Library/CoreServices/BootX

Out of curiosity did it still work when you removed this?


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/15/21 9:11 PM, Mark Cave-Ayland wrote:

Not sure why to pass "-c chrp" here as all the instructions I have seen for >> PowerMac pass "-c UNIX".

(goes and looks)

From what I can see there is a mixture of creator types: chrp is mentioned for
FreeBSD and BootX, whilst most of the grub references suggest using UNIX. Having a look around the OpenBIOS code I think the creator type is only used in the absence of a blessed directory, so either will do fine.

OK, I was already wondering about that. grub-install contains a bless utility and function only, but not something for the UNIX filetype.

Question: If the blessing is sufficient and the setting of the filetype not necessary,
why does grub-install --macppc-directory=/boot/grub (with that being an HFS
filesystem) not create a working boot partition?

There is either a bug in GRUB or I'm using it incorrectly.

If we could use GRUB's own blessing utility and waive for hfsutils altogether, we could
simplify the current code in grub-installer for PowerMacs [1] even further. But at the
moment, the current changes are what I know is working and what's also documented in
the Gentoo wiki [2].

On the other hand, I know that Vladimir from GRUB upstream is an experienced programmer,
so I can't really believe he committed something like PowerMac support in GRUB without
properly testing it.

FWIW, the bootable CD also has the chrp/tbxi type set [3]. So, I'm not sure whether we
need that or not. Either way, I will perform further tests in the future, also with HFS+
instead of HFS and try to reduce the necessary tools to hfsprogs and GRUB.

sed -i 's!&device;:&partition;!'"$ofpath"'!g' $ROOT/boot/grub/System/Library/CoreServices/BootX

Out of curiosity did it still work when you removed this?

Yes.

Adrian

[1] https://salsa.debian.org/installer-team/grub-installer/-/commit/a234f349ef13ddf3d756c4418716f2e6adeba3dc
[2] https://wiki.gentoo.org/wiki/GRUB_on_Open_Firmware_(PowerPC)
[3] https://salsa.debian.org/images-team/debian-cd/-/blob/master/tools/boot/bullseye/boot-powerpc#L23

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 15/04/2021 20:23, John Paul Adrian Glaubitz wrote:

OK, I was already wondering about that. grub-install contains a bless utility and function only, but not something for the UNIX filetype.

Question: If the blessing is sufficient and the setting of the filetype not necessary,
why does grub-install --macppc-directory=/boot/grub (with that being an HFS
filesystem) not create a working boot partition?

Yeah. From what I can see from links [1] and [2] I'd expect this to be working now.
Let me run an install of the latest ISO here, since then I can then use a debugger on
QEMU/OpenBIOS to find out what the problem may be.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/21 1:27 AM, Mark Cave-Ayland wrote:

Yeah. From what I can see from links [1] and [2] I'd expect this to be working now.
Let me run an install of the latest ISO here, since then I can then use a debugger
on QEMU/OpenBIOS to find out what the problem may be.

(...)
The main problem I found was that starting from a blank drive image in QEMU the
/boot/grub HFS partition wasn't being created - see the attached PNGs where part-original.png
is the layout from the default guided installation and part-modified.png is after I had
manually removed the / partition, added the /boot/grub HFS partition (I guess a 32MB size?)
and then assigned the remaining space to the / partition once again.
(...)
# grub-install --macppc-directory=/boot/grub/

(this installed /boot/grub/System/Library/CoreServices/BootX which was missing before?)

Your machine is obviously not detected as a New World PowerMac and thus, none of the mechanisms for
New World PowerMacs are applied. If archdetect doesn't show you're on a "powerpc/powermac_newworld",
neither the automatic partioning nor the installation of GRUB for PowerMacs is triggered correctly.

# umount /boot/grub/
# hmount /dev/sda3
Volume name is "untitled"
Volume was created on Thu Apr 15 20:51:52 2021
Volume was last modified on Thu Apr 15 21:48:40 2021
Volume has 22705664 bytes free
root@debian:/boot# hls
fonts grub.cfg locale powerpc-ieee1275
grub grubenv mach_kernel System
# hattrib -b :System:Library:CoreServices
# hattrib -c chrp -t tbxi :System:Library:CoreServices:BootX

So, I thought setting the filetype isn't necessary?

# hls -l :System:Library:CoreServices:BootX
f tbxi/chrp 0 16632 Apr 15 22:53 :System:Library:CoreServices:BootX
# humount
# shutdown -h now

After that I was able to reboot successfully by switching qemu-system-ppc to boot from the HD using -boot c instead:

./qemu-system-ppc -hda deb10.qcow2 -cdrom debian-10.0.0-powerpc-NETINST-1.iso -boot c -m 512 -nographic

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Le 16/04/2021 à 01:27, Mark Cave-Ayland a écrit :

On 15/04/2021 20:54, Mark Cave-Ayland wrote:

OK, I was already wondering about that. grub-install contains a
bless utility
and function only, but not something for the UNIX filetype.

Question: If the blessing is sufficient and the setting of the
filetype not necessary,
           why does grub-install --macppc-directory=/boot/grub (with
that being an HFS
           filesystem) not create a working boot partition?

Yeah. From what I can see from links [1] and [2] I'd expect this to
be working now. Let me run an install of the latest ISO here, since
then I can then use a debugger on QEMU/OpenBIOS to find out what the
problem may be.

After a bit of fiddling I was eventually able to get a bootable HD
install under qemu-system-ppc using your snapshot image. The command
line I used was:

./qemu-system-ppc -hda deb10.qcow2 -cdrom
debian-10.0.0-powerpc-NETINST-1.iso -boot d -m 512 -nographic

The main problem I found was that starting from a blank drive image in
QEMU the /boot/grub HFS partition wasn't being created - see the
attached PNGs where part-original.png is the layout from the default
guided installation and part-modified.png is after I had manually
removed the / partition, added the /boot/grub HFS partition (I guess a
32MB size?) and then assigned the remaining space to the / partition
once again.

Once this was done, I let the base install run all the way up until
the point where the installer prompted me for the mirror information.
At this point I didn't want to install any extra packages to help save
time, so instead went back to the installer menu and then went
directly to the grub installation step. That appeared to succeed
without any error messages, so then finished the installer and rebooted.

Unfortunately the resulting HD image would not boot. I could see the
contents of the /boot/grub partition in OpenBIOS with "dir hd:,\" and
after a few tests realised I was able to boot the grub ELF directly
using "boot hd:3,\grub".

Once in the installed image I noticed that the /boot/grub/System/Library/CoreServices/ directory didn't exist,
possibly because I skipped the installer between the mirror selection
and the grub installation? However at this point I was able to install hfsutils by hand using "apt-get install hfsutils" which then allowed
me to do the following:

# grub-install --macppc-directory=/boot/grub/

(this installed /boot/grub/System/Library/CoreServices/BootX which was missing before?)

# umount /boot/grub/
# hmount /dev/sda3
Volume name is "untitled"
Volume was created on Thu Apr 15 20:51:52 2021
Volume was last modified on Thu Apr 15 21:48:40 2021
Volume has 22705664 bytes free
root@debian:/boot# hls
fonts             grub.cfg          locale powerpc-ieee1275
grub              grubenv           mach_kernel       System
# hattrib -b :System:Library:CoreServices
# hattrib -c chrp -t tbxi :System:Library:CoreServices:BootX
# hls -l :System:Library:CoreServices:BootX
f  tbxi/chrp         0     16632 Apr 15 22:53 :System:Library:CoreServices:BootX
# humount
# shutdown -h now

After that I was able to reboot successfully by switching
qemu-system-ppc to boot from the HD using -boot c instead:

./qemu-system-ppc -hda deb10.qcow2 -cdrom
debian-10.0.0-powerpc-NETINST-1.iso -boot c -m 512 -nographic

ATB,

Mark.

Inded, I don't have the HFS partition too.

--
Passez à Linux : https://infolib.re

.--.
|o_o |
||_/ |
// \\ Envoyé depuis mon Linux
(| |)
/ \_ _/ \
\___)=(___/


<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 16/04/2021 à 01:27, Mark Cave-Ayland
a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:f073549e-735c-14f0-a694-0448b7eb7eb8@ilande.co.uk">On
15/04/2021 20:54, Mark Cave-Ayland wrote:
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">OK, I was already wondering about that.
grub-install contains a bless utility
<br>
and function only, but not something for the UNIX filetype.
<br>
<br>
Question: If the blessing is sufficient and the setting of the
filetype not necessary,
<br>
           why does grub-install --macppc-directory=/boot/grub
(with that being an HFS
<br>
           filesystem) not create a working boot partition?
<br>
</blockquote>
<br>
Yeah. From what I can see from links [1] and [2] I'd expect this
to be working now. Let me run an install of the latest ISO here,
since then I can then use a debugger on QEMU/OpenBIOS to find
out what the problem may be.
<br>
</blockquote>
<br>
After a bit of fiddling I was eventually able to get a bootable HD
install under qemu-system-ppc using your snapshot image. The
command line I used was:
<br>
<br>
./qemu-system-ppc -hda deb10.qcow2 -cdrom
debian-10.0.0-powerpc-NETINST-1.iso -boot d -m 512 -nographic
<br>
<br>
The main problem I found was that starting from a blank drive
image in QEMU the /boot/grub HFS partition wasn't being created -
see the attached PNGs where part-original.png is the layout from
the default guided installation and part-modified.png is after I
had manually removed the / partition, added the /boot/grub HFS
partition (I guess a 32MB size?) and then assigned the remaining
space to the / partition once again.
<br>
<br>
Once this was done, I let the base install run all the way up
until the point where the installer prompted me for the mirror
information. At this point I didn't want to install any extra
packages to help save time, so instead went back to the installer
menu and then went directly to the grub installation step. That
appeared to succeed without any error messages, so then finished
the installer and rebooted.
<br>
<br>
Unfortunately the resulting HD image would not boot. I could see
the contents of the /boot/grub partition in OpenBIOS with "dir
hd:,\" and after a few tests realised I was able to boot the grub
ELF directly using "boot hd:3,\grub".
<br>
<br>
Once in the installed image I noticed that the
/boot/grub/System/Library/CoreServices/ directory didn't exist,
possibly because I skipped the installer between the mirror
selection and the grub installation? However at this point I was
able to install hfsutils by hand using "apt-get install hfsutils"
which then allowed me to do the following:
<br>
<br>
# grub-install --macppc-directory=/boot/grub/
<br>
<br>
(this installed /boot/grub/System/Library/CoreServices/BootX which
was missing before?)
<br>
<br>
# umount /boot/grub/
<br>
# hmount /dev/sda3
<br>
Volume name is "untitled"
<br>
Volume was created on Thu Apr 15 20:51:52 2021
<br>
Volume was last modified on Thu Apr 15 21:48:40 2021
<br>
Volume has 22705664 bytes free
<br>
root@debian:/boot# hls
<br>
fonts             grub.cfg          locale           
powerpc-ieee1275
<br>
grub              grubenv           mach_kernel       System
<br>
# hattrib -b :System:Library:CoreServices
<br>
# hattrib -c chrp -t tbxi :System:Library:CoreServices:BootX
<br>
# hls -l :System:Library:CoreServices:BootX
<br>
f  tbxi/chrp         0     16632 Apr 15 22:53
:System:Library:CoreServices:BootX
<br>
# humount
<br>
# shutdown -h now
<br>
<br>
After that I was able to reboot successfully by switching
qemu-system-ppc to boot from the HD using -boot c instead:
<br>
<br>
./qemu-system-ppc -hda deb10.qcow2 -cdrom
debian-10.0.0-powerpc-NETINST-1.iso -boot c -m 512 -nographic
<br>
<br>
<br>
ATB,
<br>
<br>
Mark.
<br>
</blockquote>
<p>Inded, I don't have the HFS partition too.</p>
<pre class="moz-signature" cols="72">--
Passez à Linux : <a class="moz-txt-link-freetext" href="https://infolib.re">https://infolib.re</a>

.--.
|o_o |
||_/ |
// \\ Envoyé depuis mon Linux
(| |)
/ \_ _/ \
\___)=(___/</pre>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/21 7:56 AM, David VANTYGHEM wrote:

Inded, I don't have the HFS partition too.

Then the emulation is not behaving as a real machine.

QEMU needs display the right information below /proc/cpuinfo:

https://salsa.debian.org/installer-team/libdebian-installer/-/blob/master/src/system/subarch-powerpc-linux.c

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2021 06:50, John Paul Adrian Glaubitz wrote:

On 4/16/21 1:27 AM, Mark Cave-Ayland wrote:

Yeah. From what I can see from links [1] and [2] I'd expect this to be working now.
Let me run an install of the latest ISO here, since then I can then use a debugger
on QEMU/OpenBIOS to find out what the problem may be.

(...)
The main problem I found was that starting from a blank drive image in QEMU the
/boot/grub HFS partition wasn't being created - see the attached PNGs where part-original.png
is the layout from the default guided installation and part-modified.png is after I had
manually removed the / partition, added the /boot/grub HFS partition (I guess a 32MB size?)
and then assigned the remaining space to the / partition once again.
(...)
# grub-install --macppc-directory=/boot/grub/

(this installed /boot/grub/System/Library/CoreServices/BootX which was missing before?)

Your machine is obviously not detected as a New World PowerMac and thus, none of the mechanisms for
New World PowerMacs are applied. If archdetect doesn't show you're on a "powerpc/powermac_newworld",
neither the automatic partioning nor the installation of GRUB for PowerMacs is triggered correctly.

I see, thanks - my confusion was that the old installer used to always set up the
partitioning regardless of the machine type and so it was possible to boot on both an
Old World and a New World machine.

Are Old World Macs no longer supported?

# umount /boot/grub/
# hmount /dev/sda3
Volume name is "untitled"
Volume was created on Thu Apr 15 20:51:52 2021
Volume was last modified on Thu Apr 15 21:48:40 2021
Volume has 22705664 bytes free
root@debian:/boot# hls
fonts grub.cfg locale powerpc-ieee1275
grub grubenv mach_kernel System
# hattrib -b :System:Library:CoreServices
# hattrib -c chrp -t tbxi :System:Library:CoreServices:BootX

So, I thought setting the filetype isn't necessary?

I think it shouldn't be - I can test later but mostly I just wanted to use something
that was known to work so I could debug the boot process.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Le 16/04/2021 à 08:04, John Paul Adrian Glaubitz a écrit :

On 4/16/21 7:56 AM, David VANTYGHEM wrote:

Inded, I don't have the HFS partition too.

Then the emulation is not behaving as a real machine.

QEMU needs display the right information below /proc/cpuinfo:

https://salsa.debian.org/installer-team/libdebian-installer/-/blob/master/src/system/subarch-powerpc-linux.c

Adrian

Under QEMU, my machine is :

https://cryptpad.fr/file/#/2/file/YT77NWCuXe-1Zei6sAam49SS/

(pcmacgeneration : NewWorld)

--
Passez à Linux : https://infolib.re

.--.
|o_o |
||_/ |
// \\ Envoyé depuis mon Linux
(| |)
/ \_ _/ \
\___)=(___/


<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 16/04/2021 à 08:04, John Paul Adrian
Glaubitz a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:3165fb74-b3a8-e6d6-275e-77bc365398fa@physik.fu-berlin.de">
<pre class="moz-quote-pre" wrap="">On 4/16/21 7:56 AM, David VANTYGHEM wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Inded, I don't have the HFS partition too.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Then the emulation is not behaving as a real machine.

QEMU needs display the right information below /proc/cpuinfo:

</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-freetext" href="https://salsa.debian.org/installer-team/libdebian-installer/-/blob/master/src/system/subarch-powerpc-linux.c">https://salsa.debian.org/installer-team/libdebian-installer/-/
blob/master/src/system/subarch-powerpc-linux.c</a>
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Adrian

</pre>
</blockquote>
<p>Under QEMU, my machine is :<br>
</p>
<p><a class="moz-txt-link-freetext" href="https://cryptpad.fr/file/#/2/file/YT77NWCuXe-1Zei6sAam49SS/">https://cryptpad.fr/file/#/2/file/YT77NWCuXe-1Zei6sAam49SS/</a></p>
<p>(pcmacgeneration : NewWorld)<br>
</p>
<pre class="moz-signature" cols="72">--
Passez à Linux : <a class="moz-txt-link-freetext" href="https://infolib.re">https://infolib.re</a>

.--.
|o_o |
||_/ |
// \\ Envoyé depuis mon Linux
(| |)
/ \_ _/ \
\___)=(___/</pre>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/21 8:39 AM, Mark Cave-Ayland wrote:

https://salsa.debian.org/installer-team/libdebian-installer/-/blob/master/src/system/subarch-powerpc-linux.c

Here's what I get for the QEMU machines:

The interesting part will be to see what arch-detect prints out in the installer. You can just run it from a second terminal. If it doesn't
detect a newworld machine, GRUB installation won't work.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/21 8:14 AM, David VANTYGHEM wrote:

Under QEMU, my machine is :

https://cryptpad.fr/file/#/2/file/YT77NWCuXe-1Zei6sAam49SS/

(pcmacgeneration : NewWorld)

The deciding factor is what "arch-detect" shows on your machine and if
the strings aren't shown as "arch-detect" expects them, the installer
is not able to properly detect your platform.

I mean, I tested this whole thing on an actual iBook G4 and it works as expected, so if QEMU's emulation is accurate, the end result must be
the same for the powerpc image (I'm not talking about the ppc64 image
which is broken and untested - but that I am about to fix).

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Le 16/04/2021 à 08:48, John Paul Adrian Glaubitz a écrit :

On 4/16/21 8:39 AM, Mark Cave-Ayland wrote:

https://salsa.debian.org/installer-team/libdebian-installer/-/blob/master/src/system/subarch-powerpc-linux.c

Here's what I get for the QEMU machines:

The interesting part will be to see what arch-detect prints out in the installer. You can just run it from a second terminal. If it doesn't
detect a newworld machine, GRUB installation won't work.

Adrian

I don't have arch-detect but a archdetect command :

# archdetect

powerpc/powermac_newworld

--
Passez à Linux : https://infolib.re

.--.
|o_o |
||_/ |
// \\ Envoyé depuis mon Linux
(| |)
/ \_ _/ \
\___)=(___/


<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 16/04/2021 à 08:48, John Paul Adrian
Glaubitz a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:8695545b-31c2-b6f9-33c6-39852c836ba4@physik.fu-berlin.de">
<pre class="moz-quote-pre" wrap="">On 4/16/21 8:39 AM, Mark Cave-Ayland wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-freetext" href="https://salsa.debian.org/installer-team/libdebian-installer/-/blob/master/src/system/subarch-powerpc-linux.c">https://salsa.debian.org/installer-team/libdebian-
installer/-/blob/master/src/system/subarch-powerpc-linux.c</a>
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Here's what I get for the QEMU machines:
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The interesting part will be to see what arch-detect prints out in the installer. You can just run it from a second terminal. If it doesn't
detect a newworld machine, GRUB installation won't work.

Adrian

</pre>
</blockquote>
<p>I don't have arch-detect but a archdetect command :</p>
<p># archdetect</p>
<p>powerpc/powermac_newworld<br>
</p>
<pre class="moz-signature" cols="72">--
Passez à Linux : <a class="moz-txt-link-freetext" href="https://infolib.re">https://infolib.re</a>

.--.
|o_o |
||_/ |
// \\ Envoyé depuis mon Linux
(| |)
/ \_ _/ \
\___)=(___/</pre>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2021 07:48, John Paul Adrian Glaubitz wrote:

On 4/16/21 8:39 AM, Mark Cave-Ayland wrote:

https://salsa.debian.org/installer-team/libdebian-installer/-/blob/master/src/system/subarch-powerpc-linux.c

Here's what I get for the QEMU machines:

The interesting part will be to see what arch-detect prints out in the installer. You can just run it from a second terminal. If it doesn't
detect a newworld machine, GRUB installation won't work.

Here's what I see with -M mac99:

~ # /bin/archdetect
powerpc/powermac_newworld

I guess that should work? If so, I can kick off another installation in the background later.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2021 07:47, John Paul Adrian Glaubitz wrote:

On 4/16/21 8:36 AM, Mark Cave-Ayland wrote:

Your machine is obviously not detected as a New World PowerMac and thus, none of the mechanisms for
New World PowerMacs are applied. If archdetect doesn't show you're on a "powerpc/powermac_newworld",
neither the automatic partioning nor the installation of GRUB for PowerMacs is triggered correctly.

I see, thanks - my confusion was that the old installer used to always set up the partitioning regardless
of the machine type and so it was possible to boot on both an Old World and a New World machine.

That's not quite true. The installer has always been differentiating the different machine types on
PowerPC. For Yaboot, there was a package called "partman-newworld" before that was only enabled on
machines detected as */powermac_newworld. If your machine did not match that pattern, it would not
have created the HFS bootstrap.

I see. Possibly this is a bit blurred under QEMU since whilst the machine types should be reported correctly, OpenBIOS is able to run a New World bootloader on an
Old World machine.

Are Old World Macs no longer supported?

I am currently concerned with New World Macs only as I haven't had the time yet to dig out an OW
Mac for testing. I have such a machine currently in storage but no plans at the moment to work
on it as kernel support for these old machines as mine (PowerBook 3400) is not working anyway
at the moment.

Ah ok. My guess is that assuming grub is fairly conservative with its CIF usage then
the main change would be to set the tbxi attribute on System/Library/CoreServices/grub.elf instead of System/Library/CoreServices/BootX. My
hunch is that Old World machines can't parse an XML CHRP-BOOT script, but they should
be able to load the ELF directly (which is effectively what I did during my installation test).

So, I thought setting the filetype isn't necessary?

I think it shouldn't be - I can test later but mostly I just wanted to use something that was
known to work so I could debug the boot process.

My question still is: Why does "grub-install --macppc-directory=/boot/grub" not already set up
a completely working bootstrap partition. There is obviously a bug in grub-install.

Yeah. When I did my test the grub-install section of the installer itself didn't
report any errors, but then I didn't go looking at the installer logs directly. Perhaps that's something to do for the next test once I've validated the creation of
the /boot/grub HFS partition on New World machines.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/21 8:53 AM, David VANTYGHEM wrote:

I don't have arch-detect but a archdetect command :

# archdetect

powerpc/powermac_newworld

Then I have no clue what's wrong and you will need to debug the
problem yourself.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/21 8:59 AM, Mark Cave-Ayland wrote:

The interesting part will be to see what arch-detect prints out in the
installer. You can just run it from a second terminal. If it doesn't
detect a newworld machine, GRUB installation won't work.

Here's what I see with -M mac99:

~ # /bin/archdetect
powerpc/powermac_newworld

I guess that should work? If so, I can kick off another installation in the background later.

So, which image did you use and was QEMU already configured like that when
you were trying it in the first place.

Because I am starting to question my sanity. If you're showing me that arch-detect
is detecting the machine correctly and you used the latest image which I tested myself on real hardware, then it's not possible that the partioner will use
the wrong layout.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2021 08:21, John Paul Adrian Glaubitz wrote:

On 4/16/21 8:59 AM, Mark Cave-Ayland wrote:

The interesting part will be to see what arch-detect prints out in the
installer. You can just run it from a second terminal. If it doesn't
detect a newworld machine, GRUB installation won't work.

Here's what I see with -M mac99:

~ # /bin/archdetect
powerpc/powermac_newworld

I guess that should work? If so, I can kick off another installation in the background later.

So, which image did you use and was QEMU already configured like that when you were trying it in the first place.

Because I am starting to question my sanity. If you're showing me that arch-detect
is detecting the machine correctly and you used the latest image which I tested
myself on real hardware, then it's not possible that the partioner will use the wrong layout.

Well bear in mind that last night's install would have been running under an Old
World (-M g3beige) machine as that was before I realised from your comments this
morning that the new functionality was restricted to New World machines.

I've started a new install on a blank disk with -M mac99 and will report back.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 4/16/21 9:29 AM, Mark Cave-Ayland wrote:

Because I am starting to question my sanity. If you're showing me that arch-detect
is detecting the machine correctly and you used the latest image which I tested
myself on real hardware, then it's not possible that the partioner will use >> the wrong layout.

Well bear in mind that last night's install would have been running under an Old World (-M g3beige)
machine as that was before I realised from your comments this morning that the new functionality
was restricted to New World machines.

Well, that was an important missing piece of information.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 16/04/2021 08:41, John Paul Adrian Glaubitz wrote:

On 4/16/21 9:29 AM, Mark Cave-Ayland wrote:

Because I am starting to question my sanity. If you're showing me that arch-detect
is detecting the machine correctly and you used the latest image which I tested
myself on real hardware, then it's not possible that the partioner will use >>> the wrong layout.

Well bear in mind that last night's install would have been running under an Old World (-M g3beige)
machine as that was before I realised from your comments this morning that the new functionality
was restricted to New World machines.

Well, that was an important missing piece of information.

Sorry :( As I mentioned before the old installer worked fine on both QEMU machines,
and since David reported that his -M mac99 installation failed then I figured the
problem was elsewhere.


ATB,

Mark.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)