I burnt the image using Rufus on Windows, which IIRC should be fine, though I can do it with dd on a *nix machine later if someone thinks it may make a difference.
For the moment I've managed to 'solve' the problem by using the snapshot from 2019-07-03, which seems to work. If I can help troubleshoot the current snapshot please let me know. Thanks! Sam On Mon, Oct 19, 2020 at 1:15 PM Thomas Schmitt <scdbac...@gmx.net> wrote: > Hi, > > John Paul Adrian Glaubitz wrote: > > Please use the latest image I created yesterday: > > > https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-13/debian-10.0.0-powerpc-NETINST-1.iso > > This contains 1 mountable partition in MBR and 3 partitions in an > Apple Partition Map (APM), of which partition 2 contains a HFS+ filesystem > with bocksize 2048. This blocksize is not supported by Linux, AFAIK. > > > To avoid any ambiguities i would mount /dev/sdb with -t iso9660. > > Wayward idea: Would a CD or DVD with a copy of the ISO work in /dev/sr0 ? > > > ------------------------------------------------------------------- > Theoretical considerations: > > Lennart Sorensen wrote: > > Does using dd work for a powermac like it does on PCs? > > I am not aware of other ways to present the ISO to the machine. > The boot equipment should work on HDD and CD/DVD. > > If i understood the original problem correctly, then the boot process > began to work and failed only when Linux was already up. So it can hardly > be a total failure of the ISO to tell the firmware what's wanted. > > The computer's hardware under firmware control thus works with the USB > stick. Linux sees the CHRP partition. So it, too, was able to read from > the stick. Its reason to refuse mounting /dev/sdb1 must be in a more > subtle shortcomming. > > Since Linux was able to read the partition table, it might be able to > mount /dev/sdb. > > > > Looking at the iso it appears to have a DOS partition table, [...] > > and an apple partition map > > It has a CHRP partition in MBR and an Apple Partition Map partition > pointing to a HFS+ with creator and type > chrp tbxi > attributed to > /System/Library/CoreServices/BootX > and blessing > ppc_bootdir > to > /System/Library/CoreServices > It is supposed to represent the same data directories and files as > the ISO. But as said, Linux will take offense from the block size. > > (Actually that size is a necessity only if GPT is present. Maybe one > should make experiments with xorrisofs option -hfsplus-block-size 512. > But that would be a completely different adventure.) > > > > Certainly the size in /proc/partitions appears to agree with > > the overall size and the dos partition table which should be the entire > > iso file system, so mounting as iso9660 should have worked. > > Yes. It is not the APM partition 1 which has only 915 * 2048 bytes. > The data partition is number 2 and has 158181 * 2048 bytes = 316362 KiB. > This size does not match the display from /proc/partitions either. > > The MBR partition begins at LBA 0. So the block addresses in the ISO 9660 > should work with /dev/sdb and /dev/sdb1 alike. Well, /dev/sdb1 doesn't. > > ----------------------------------------------------------------------- > > Have a nice day :) > > Thomas > > -- Sam
