Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Current status on grub-installer on PowerMac
44 views
Skip to first unread message
John Paul Adrian Glaubitz
Apr 14, 2021, 4:00:02 AM4/14/21
to
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 - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
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 - glau...@debian.org
`. `' Freie Universitaet Berlin - glau...@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
John Paul Adrian Glaubitz
Apr 14, 2021, 6:10:02 AM4/14/21
to
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
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.
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
Mark Cave-Ayland
Apr 14, 2021, 7:50:03 AM4/14/21
to
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!
> 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.
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).
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.
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.
John Paul Adrian Glaubitz
Apr 14, 2021, 8:00:03 AM4/14/21
to
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
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!
>> 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.
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
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?
>
> 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
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.
> 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.
Currently, I have:
sed -i 's!&device;:&partition;!'"$ofpath"'!g' $ROOT/boot/grub/System/Library/CoreServices/BootX
Adrian
Mark Cave-Ayland
Apr 15, 2021, 3:20:03 PM4/15/21
to
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!
>>> 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".
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.
ATB,
Mark.
John Paul Adrian Glaubitz
Apr 15, 2021, 3:30:03 PM4/15/21
to
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
>> 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.
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?
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
Mark Cave-Ayland
Apr 15, 2021, 4:00:02 PM4/15/21
to
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.
> 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?
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.
David VANTYGHEM
Apr 16, 2021, 2:00:03 AM4/16/21
to
Le 16/04/2021 à 01:27, Mark Cave-Ayland
a écrit :
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 (| |) / \_ _/ \ \___)=(___/
John Paul Adrian Glaubitz
Apr 16, 2021, 2:00:03 AM4/16/21
to
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.
> (...)
>> 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.
> (...)
> /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
>
> (this installed /boot/grub/System/Library/CoreServices/BootX which was missing before?)
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
> # 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
John Paul Adrian Glaubitz
Apr 16, 2021, 2:10:02 AM4/16/21
to
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.
> Inded, I don't have the HFS partition too.
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
David VANTYGHEM
Apr 16, 2021, 2:20:02 AM4/16/21
to
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.cAdrian
Under QEMU, my machine is :
https://cryptpad.fr/file/#/2/file/YT77NWCuXe-1Zei6sAam49SS/
(pcmacgeneration : NewWorld)
Mark Cave-Ayland
Apr 16, 2021, 2:40:02 AM4/16/21
to
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
> 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.
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?
that was known to work so I could debug the boot process.
ATB,
Mark.
Mark Cave-Ayland
Apr 16, 2021, 2:40:02 AM4/16/21
to
On 16/04/2021 07:04, John Paul Adrian Glaubitz wrote:
> 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
Here's what I get for the QEMU machines:
> 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
Old World (default or -M g3beige):
root@debian:~# cat /proc/cpuinfo
processor : 0
cpu : 740/750
temperature : 50-126 C (uncalibrated)
clock : 266.000000MHz
revision : 3.1 (pvr 0008 0301)
bogomips : 33.20
timebase : 16604733
platform : PowerMac
model : Power Macintosh
machine : Power Macintosh
motherboard : AAPL,PowerMac G3 MacRISC
detected as : 49 (PowerMac G3 (Silk))
pmac flags : 00000000
pmac-generation : OldWorld
Memory : 512 MB
New World (-M mac99):
root@debian:~# cat /proc/cpuinfo
processor : 0
cpu : 7400, altivec supported
temperature : 50-126 C (uncalibrated)
clock : 900.000000MHz
revision : 2.9 (pvr 000c 0209)
bogomips : 200.00
timebase : 100000000
platform : PowerMac
model : PowerMac3,1
machine : PowerMac3,1
motherboard : PowerMac3,1 MacRISC MacRISC2 Power Macintosh
detected as : 65 (PowerMac G4 AGP Graphics)
pmac flags : 00000004
pmac-generation : NewWorld
Memory : 512 MB
ATB,
Mark.
John Paul Adrian Glaubitz
Apr 16, 2021, 2:50:02 AM4/16/21
to
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
>>> 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:
installer. You can just run it from a second terminal. If it doesn't
detect a newworld machine, GRUB installation won't work.
John Paul Adrian Glaubitz
Apr 16, 2021, 2:50:03 AM4/16/21
to
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
>> 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.
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.
> Are Old World Macs no longer supported?
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.
>> 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.
a completely working bootstrap partition. There is obviously a bug in grub-install.
John Paul Adrian Glaubitz
Apr 16, 2021, 2:50:03 AM4/16/21
to
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
> Under QEMU, my machine is :
>
> https://cryptpad.fr/file/#/2/file/YT77NWCuXe-1Zei6sAam49SS/
>
> (pcmacgeneration : NewWorld)
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).
David VANTYGHEM
Apr 16, 2021, 3:00:02 AM4/16/21
to
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.cHere'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
Mark Cave-Ayland
Apr 16, 2021, 3:00:03 AM4/16/21
to
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:
> 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.
~ # /bin/archdetect
powerpc/powermac_newworld
I guess that should work? If so, I can kick off another installation in the
background later.
ATB,
Mark.
Mark Cave-Ayland
Apr 16, 2021, 3:10:02 AM4/16/21
to
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
> 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.
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.
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.
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.
John Paul Adrian Glaubitz
Apr 16, 2021, 3:20:02 AM4/16/21
to
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
> I don't have arch-detect but a archdetect command :
>
> # archdetect
>
> powerpc/powermac_newworld
problem yourself.
John Paul Adrian Glaubitz
Apr 16, 2021, 3:30:02 AM4/16/21
to
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
>> 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.
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.
Mark Cave-Ayland
Apr 16, 2021, 3:40:02 AM4/16/21
to
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
> 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.
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.
John Paul Adrian Glaubitz
Apr 16, 2021, 3:50:02 AM4/16/21
to
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.
>> 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.
Mark Cave-Ayland
Apr 16, 2021, 4:10:03 AM4/16/21
to
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,
> 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.
and since David reported that his -M mac99 installation failed then I figured the
problem was elsewhere.
ATB,
Mark.
0 new messages