Re: List of powerpc / pmac specific package for debian-ports
On Tue, Nov 13, 2018 at 8:18 AM Mathieu Malaterre wrote: > > On Tue, Sep 4, 2018 at 10:27 AM John Paul Adrian Glaubitz > wrote: > > > > On 09/04/2018 09:36 AM, Mathieu Malaterre wrote: > > > In that case: > > > > > > - pmac-utils > > > > That's not the whole list. There were other packages like partman-newworld > > that got recently removed which are far more important as they are required > > for debian-installer. > > > > See: https://lists.debian.org/debian-boot/2018/09/msg7.html > > Updated list: > > - ps3-utils > - pmac-utils > - partman-newworld > - spu-tools > - pbbuttonsd - b43-fwcutter (contrib)
Re: Problems with hfsprogs on G5 Power Macs
On 1/7/19 10:09 PM, Frank Scheiner wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd3a8, > fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883 > 883 hfs_endian.c: No such file or directory. I think the debugging process would be more verbose if the debugging was done in-tree of the hfsprogress source code. > (gdb) p src > $1 = (BlockDescriptor *) 0x7fffd3a8 > (gdb) p srcDesc > $2 = (BTNodeDescriptor *) 0x75c91200 > (gdb) p srcOffs > $3 = (uint16_t *) 0x75c913fe > (gdb) p sizeof(UInt16) > No symbol "UInt16" in current context. > [...] > (gdb) p sizeof(uint16_t) > $4 = 2 > ``` What was the problem again? hfsprogs crashing on 64-bit systems? My wild guess would be that the code uses C types which have different lengths on 32- and 64-bit systems where it should really use type with defined lengths, i.e. "uint32" instead of "int". Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Problems with hfsprogs on G5 Power Macs
On 1/7/19 21:57, Mark Cave-Ayland wrote: On 07/01/2019 19:57, Frank Scheiner wrote: root@powermac-g5:~# gdb --args /sbin/fsck.hfs -d /dev/sda2 GNU gdb (Debian 8.2-1) 8.2 [...] Reading symbols from /sbin/fsck.hfs...done. (gdb) run Starting program: /sbin/fsck.hfs -d /dev/sda2 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1". ** /dev/sda2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. Program received signal SIGSEGV, Segmentation fault. 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd378, fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883 883 hfs_endian.c: No such file or directory. (gdb) bt [...] Interesting. So line 883 appears to be: nextRecord = (char *)src->buffer + srcOffs[i-1]; Certainly there is some interesting pointer arithmetic going on there (and if i == 0 then you're reading something before src->buffer). Can you try the following commands in gdb: p src p srcDesc p srcOffs p sizeof(UInt16) Here you go: ``` [...] (gdb) run Starting program: /sbin/fsck.hfs -d /dev/sda2 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1". ** /dev/sda2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. Program received signal SIGSEGV, Segmentation fault. 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd3a8, fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883 883 hfs_endian.c: No such file or directory. (gdb) p src $1 = (BlockDescriptor *) 0x7fffd3a8 (gdb) p srcDesc $2 = (BTNodeDescriptor *) 0x75c91200 (gdb) p srcOffs $3 = (uint16_t *) 0x75c913fe (gdb) p sizeof(UInt16) No symbol "UInt16" in current context. [...] (gdb) p sizeof(uint16_t) $4 = 2 ``` Cheers, Frank
Re: Problems with hfsprogs on G5 Power Macs
On 07/01/2019 19:57, Frank Scheiner wrote: > On 1/7/19 13:10, John Paul Adrian Glaubitz wrote: >> On 1/7/19 1:09 PM, Frank Scheiner wrote: $ gdb --args /path/to/hfsprogs --param1 --param2 The "--args" argument to gdb is necessary so that gdb calls the binary with "--param1 --param2". >>> >>> Thanks, I'll give that a try and report the results. >> >> Oh, and once it crashes, type "bt" to get a backtrace. > > Ok, this is the complete output: > > ``` > root@powermac-g5:~# file /sbin/fsck.hfs > /sbin/fsck.hfs: symbolic link to fsck.hfsplus > > root@powermac-g5:~# file /sbin/fsck.hfsplus > /sbin/fsck.hfsplus: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco > 7500, > version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for > GNU/Linux > 3.2.0, BuildID[sha1]=a41108e28eba5c98a491785bf86e7e8ecf2c6691, with > debug_info, not > stripped > > root@powermac-g5:~# gdb --args /sbin/fsck.hfs -d /dev/sda2 > GNU gdb (Debian 8.2-1) 8.2 > [...] > Reading symbols from /sbin/fsck.hfs...done. > (gdb) run > Starting program: /sbin/fsck.hfs -d /dev/sda2 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1". > ** /dev/sda2 > Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. > ** Checking HFS volume. > > Program received signal SIGSEGV, Segmentation fault. > 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd378, > fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883 > 883 hfs_endian.c: No such file or directory. > (gdb) bt > #0 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd378, > fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883 > #1 0x000100032f1c in hfs_swap_BTNode (src=0x7fffd378, > fcb=0x100081898, > direction=kSwapBTNodeBigToHost) at hfs_endian.c:307 > #2 0x00010003a478 in GetNode (btreePtr=0x100081bc8, nodeNum=1, > nodePtr=0x7fffd378) at BTreeNodeOps.c:147 > #3 0x00010003beb8 in SearchTree (btreePtr=0x100081bc8, > searchKey=0x7fffd62c, > treePathTable=0x7fffd4a8, nodeNum=0x7fffd45c, nodePtr=0x7fffd488, > returnIndex=0x7fffd458) at BTreeTreeOps.c:231 > #4 0x000100036e20 in BTSearchRecord (filePtr=0x100081898, > searchIterator=0x7fffd610, heuristicHint=4294967295, > record=0x7fffd5f8, > recordLen=0x7fffd8e6, resultIterator=0x100081c80) at BTree.c:761 > #5 0x000100043214 in SearchBTreeRecord (fcb=0x100081898, > key=0x7fffd900, > hint=0, foundKey=0x7fffd90c, data=0x7fffd918, dataSize=0x7fffd8e6, > newHint=0x7fffd8ec) at SBTree.c:93 > #6 0x000100013320 in CheckFileExtents (GPtr=0x7fffe020, fileNumber=4, > forkType=0 '\000', attrname=0x0, extents=0x100081938, > blocksUsed=0x7fffda00) > at SVerify1.c:3103 > #7 0x0001f07c in CreateCatalogBTreeControlBlock > (GPtr=0x7fffe020) at > SVerify1.c:1095 > #8 0x0001b98c in ScavCtrl (GPtr=0x7fffe020, ScavOp=2, > ScavRes=0x7fffe00c) at SControl.c:395 > #9 0x0001b228 in CheckHFS (fsReadRef=3, fsWriteRef=4, checkLevel=2, > repairLevel=2, logLevel=3, guiControl=0, lostAndFoundMode=0, canWrite=1, > modified=0x100072384 ) at SControl.c:145 > #10 0x00017b78 in checkfilesys (filesys=0x7e2c "/dev/sda2") at > fsck_hfs.c:323 > #11 0x0001787c in main (argc=0, argv=0x7b10) at fsck_hfs.c:217 Interesting. So line 883 appears to be: nextRecord = (char *)src->buffer + srcOffs[i-1]; Certainly there is some interesting pointer arithmetic going on there (and if i == 0 then you're reading something before src->buffer). Can you try the following commands in gdb: p src p srcDesc p srcOffs p sizeof(UInt16) ATB, Mark.
Re: iBook G4 - Wireless
Sent from ProtonMail Mobile On Mon, Jan 7, 2019 at 2:09 PM, Riccardo Mottola wrote: > Hi, > > Brock suggested me to look here: > > https://wiki.debian.org/PowerPC/FAQ#How_do_I_get_wireless_working.3F > > there is a typo for sure, lscpi is probably lspci,. > > In any case it suggests firmware-b43-installer, however that one and > firmware-b43legacy-installer require the package > > b43-fwcutter > > which is unavailable. > > Anyone of you having their Airport working? > > Riccardo You can use Jessie’s fwcutter. This is what I did when I discovered that it hadn’t been updated for sid. Brian
Re: Problems with hfsprogs on G5 Power Macs
On 1/7/19 13:10, John Paul Adrian Glaubitz wrote: On 1/7/19 1:09 PM, Frank Scheiner wrote: $ gdb --args /path/to/hfsprogs --param1 --param2 The "--args" argument to gdb is necessary so that gdb calls the binary with "--param1 --param2". Thanks, I'll give that a try and report the results. Oh, and once it crashes, type "bt" to get a backtrace. Ok, this is the complete output: ``` root@powermac-g5:~# file /sbin/fsck.hfs /sbin/fsck.hfs: symbolic link to fsck.hfsplus root@powermac-g5:~# file /sbin/fsck.hfsplus /sbin/fsck.hfsplus: ELF 64-bit MSB pie executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=a41108e28eba5c98a491785bf86e7e8ecf2c6691, with debug_info, not stripped root@powermac-g5:~# gdb --args /sbin/fsck.hfs -d /dev/sda2 GNU gdb (Debian 8.2-1) 8.2 [...] Reading symbols from /sbin/fsck.hfs...done. (gdb) run Starting program: /sbin/fsck.hfs -d /dev/sda2 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1". ** /dev/sda2 Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. ** Checking HFS volume. Program received signal SIGSEGV, Segmentation fault. 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd378, fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883 883 hfs_endian.c: No such file or directory. (gdb) bt #0 0x000100034be4 in hfs_swap_HFSBTInternalNode (src=0x7fffd378, fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:883 #1 0x000100032f1c in hfs_swap_BTNode (src=0x7fffd378, fcb=0x100081898, direction=kSwapBTNodeBigToHost) at hfs_endian.c:307 #2 0x00010003a478 in GetNode (btreePtr=0x100081bc8, nodeNum=1, nodePtr=0x7fffd378) at BTreeNodeOps.c:147 #3 0x00010003beb8 in SearchTree (btreePtr=0x100081bc8, searchKey=0x7fffd62c, treePathTable=0x7fffd4a8, nodeNum=0x7fffd45c, nodePtr=0x7fffd488, returnIndex=0x7fffd458) at BTreeTreeOps.c:231 #4 0x000100036e20 in BTSearchRecord (filePtr=0x100081898, searchIterator=0x7fffd610, heuristicHint=4294967295, record=0x7fffd5f8, recordLen=0x7fffd8e6, resultIterator=0x100081c80) at BTree.c:761 #5 0x000100043214 in SearchBTreeRecord (fcb=0x100081898, key=0x7fffd900, hint=0, foundKey=0x7fffd90c, data=0x7fffd918, dataSize=0x7fffd8e6, newHint=0x7fffd8ec) at SBTree.c:93 #6 0x000100013320 in CheckFileExtents (GPtr=0x7fffe020, fileNumber=4, forkType=0 '\000', attrname=0x0, extents=0x100081938, blocksUsed=0x7fffda00) at SVerify1.c:3103 #7 0x0001f07c in CreateCatalogBTreeControlBlock (GPtr=0x7fffe020) at SVerify1.c:1095 #8 0x0001b98c in ScavCtrl (GPtr=0x7fffe020, ScavOp=2, ScavRes=0x7fffe00c) at SControl.c:395 #9 0x0001b228 in CheckHFS (fsReadRef=3, fsWriteRef=4, checkLevel=2, repairLevel=2, logLevel=3, guiControl=0, lostAndFoundMode=0, canWrite=1, modified=0x100072384 ) at SControl.c:145 #10 0x00017b78 in checkfilesys (filesys=0x7e2c "/dev/sda2") at fsck_hfs.c:323 #11 0x0001787c in main (argc=0, argv=0x7b10) at fsck_hfs.c:217 ``` Any idea? Cheers, Frank
Re: iBook G4 - Wireless
Hi, Brock suggested me to look here: https://wiki.debian.org/PowerPC/FAQ#How_do_I_get_wireless_working.3F there is a typo for sure, lscpi is probably lspci,. In any case it suggests firmware-b43-installer, however that one and firmware-b43legacy-installer require the package b43-fwcutter which is unavailable. Anyone of you having their Airport working? Riccardo
Re: Problems with hfsprogs on G5 Power Macs
On 1/7/19 1:09 PM, Frank Scheiner wrote: >> $ gdb --args /path/to/hfsprogs --param1 --param2 >> >> The "--args" argument to gdb is necessary so that gdb calls the binary with >> "--param1 --param2". > > Thanks, I'll give that a try and report the results. Oh, and once it crashes, type "bt" to get a backtrace. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Problems with hfsprogs on G5 Power Macs
On 1/7/19 13:01, John Paul Adrian Glaubitz wrote: Hi Frank! On 1/7/19 12:57 PM, Frank Scheiner wrote: Can you post a backtrace from a package build with debug symbols? I suspect this will be something quite obvious, i.e. using pointers to int/long rather than specific 32-bit types in the HFS code. Sure, if you can provide me with instructions on how and what to do. It should be enough to builds hfsprogs from directly source, then run the binary through gdb, e.g.: $ gdb --args /path/to/hfsprogs --param1 --param2 The "--args" argument to gdb is necessary so that gdb calls the binary with "--param1 --param2". Thanks, I'll give that a try and report the results. Cheers, Frank
Re: Problems with hfsprogs on G5 Power Macs
Hi Frank! On 1/7/19 12:57 PM, Frank Scheiner wrote: >> Can you post a backtrace from a package build with debug symbols? I suspect >> this will >> be something quite obvious, i.e. using pointers to int/long rather than >> specific >> 32-bit types in the HFS code. > > Sure, if you can provide me with instructions on how and what to do. It should be enough to builds hfsprogs from directly source, then run the binary through gdb, e.g.: $ gdb --args /path/to/hfsprogs --param1 --param2 The "--args" argument to gdb is necessary so that gdb calls the binary with "--param1 --param2". Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Problems with hfsprogs on G5 Power Macs
On 1/7/19 12:37, Mark Cave-Ayland wrote: So how do we proceed from here? Can you post a backtrace from a package build with debug symbols? I suspect this will be something quite obvious, i.e. using pointers to int/long rather than specific 32-bit types in the HFS code. Sure, if you can provide me with instructions on how and what to do. Cheers, Frank
Re: Problems with hfsprogs on G5 Power Macs
On 06/01/2019 20:48, Frank Scheiner wrote: > Hi Mathieu, > > On 1/4/19 08:51, Mathieu Malaterre wrote: >> On Thu, Jan 3, 2019 at 5:54 PM Frank Scheiner wrote: >>> On 1/3/19 12:10, Mathieu Malaterre wrote: The way you describe this bug makes me think of a 64bits vs 32bits issue. Next time this happen to you, use a foreign powerpc installation to run ppc32 binary on your G5. >>> >>> That's a good idea and I think we don't even have to wait for the next >>> time this issue hits me, as even for a clean HFS the `fsck.hfs` >>> segfaults. The significance of the result of such a test will not be the >>> same as for checking a borked HFS, but could show a tendency. >> >> Right ! Good point. >> >>> Say, will a powerpc64 kernel from arch ppc64 work with a userland from >>> arch powerpc or do I need the powerpc64 kernel from arch powerpc? Or are >>> these kernels actually identical? >> >> If I understand your sentence, the answer is yes: they are identical. >> The only (main?) difference with amd64/i386 world is that you cannot >> run a ppc32 kernel on a ppc64 machine. > > Ok. It works to use the powerpc64 kernel from arch ppc64 and a userland from > arch > powerpc with kernel modules of the powerpc64 kernel of arch powerpc. Hence I > assume > the powerpc64 kernels of arch ppc64 and powerpc are actually identical. > > Back to the testing of the powerpc version of `fsck.hfs`. I first checked the > HFS > bootstrap FS on a Mac mini G4 to have a known state for later testing: > > ``` > root@mac-mini:~# fsck.hfs -d -f /dev/sdb2 > ** /dev/sdb2 > Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. > ** Checking HFS volume. > ** Checking Extents Overflow file. > ** Checking Catalog file. > Reserved fields in the catalog record have incorrect data > (4, 185) > Reserved fields in the catalog record have incorrect data > (4, 2) > Reserved fields in the catalog record have incorrect data > (4, 2) > ** Checking Catalog hierarchy. > ** Checking volume bitmap. > ** Checking volume information. > Verify Status: VIStat = 0x, ABTStat = 0x EBTStat = 0x > CBTStat = 0x0200 CatStat = 0x > ** Repairing volume. > ** Rechecking volume. > ** Checking HFS volume. > ** Checking Extents Overflow file. > ** Checking Catalog file. > ** Checking Catalog hierarchy. > ** Checking volume bitmap. > ** Checking volume information. > ** The volume bootstrap was repaired successfully. > > root@mac-mini:~# echo $? > 0 > > root@mac-mini:~# fsck.hfs -d -f /dev/sdb2 > ** /dev/sdb2 > Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. > ** Checking HFS volume. > ** Checking Extents Overflow file. > ** Checking Catalog file. > ** Checking Catalog hierarchy. > ** Checking volume bitmap. > ** Checking volume information. > ** The volume bootstrap appears to be OK. > > root@mac-mini:~# echo $? > 0 > ``` > > ...then tested the ppc64 version on the 11,2 G5 with the expected result > (segfault): > > ``` > root@powermac-g5:~# dpkg -l hfsprogs > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---=== > ii hfsprogs 332.25-11+b3 ppc64 mkfs and fsck for HFS and HFS+ > file systems > > root@powermac-g5:~# file /sbin/fsck.hfs > /sbin/fsck.hfs: symbolic link to fsck.hfsplus > > root@powermac-g5:~# file /sbin/fsck.hfsplus > /sbin/fsck.hfsplus: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, > version > 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.1, for GNU/Linux > 3.2.0, > BuildID[sha1]=9e14a88ea04ea0fc8a89f3d79b039cf1daa6f3ed, stripped > > root@powermac-g5:~# fsck.hfs -d -f /dev/sda2 > ** /dev/sda2 > Using cacheBlockSize=32K cacheTotalBlock=1024 cacheSize=32768K. > ** Checking HFS volume. > Segmentation fault > ``` > > But then testing with the powerpc version on the 11,2 G5 actually seems to > work: > > ``` > root@powermac-g5:~# dpkg -l hfsprogs > Desired=Unknown/Install/Remove/Purge/Hold > | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==---=== > ii hfsprogs 332.25-11+b2 powerpc mkfs and fsck for HFS and HFS+ > file systems > > root@powermac-g5:~# file /sbin/fsck.hfs > /sbin/fsck.hfs: symbolic link to fsck.hfsplus > > root@powermac-g5:~# file /sbin/fsck.hfsplus > /sbin/fsck.hfsplus: ELF 32-bit MSB executable, PowerPC or cisco 4500, version > 1 > (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, > BuildID[sha1]=ce95122bcb0b56e4c1dc1b256cdf24135f6e4cad, stripped > >
Re: Changing bootstrap method for NewWorld Power Macs
On 02/01/2019 16:18, Frank Scheiner wrote: > Hi Mark, > > On 1/2/19 16:27, Mark Cave-Ayland wrote: >> On 31/12/2018 13:15, Frank Scheiner wrote: >>> Sorry to hear that, though I think you need to provide additional details >>> at this >>> time: >>> >>> What do you mean with "Debian images"? Because if you speak of the >>> installer ISOs, my >>> changes won't change anything with their ability to boot on NewWorld Power >>> Macs or >>> QEMU (I think). >> >> The part I'm worried about is that OpenBIOS searches the Apple Partition Map >> for an >> "Apple_Bootstrap" partition on PPC Mac machines, probes the FS, and then >> tries to >> boot dev:part:,\\:tbxi, dev:part:,\ppc\bootinfo.txt and dev:part:,%BOOT in >> that order. > > Is that done via the "standard" `boot` command with OpenBIOS? Yes, that's correct. >> I believe that yaboot blesses itself on the HFS "Apple_Bootstrap" partition >> which >> allows OpenBIOS to locate and run the bootloader. My understanding is that >> you would >> like to change to MBR and FAT16 which would then fail in QEMU as OpenBIOS >> doesn't >> have a functioning FAT driver - is that correct? > > I think so, but you are talking about the installed OS now. Earlier it > sounded like > you were talking about the installer ISOs and my changes don't touch the boot > method > used for these. Oh so you're proposing a split scheme? Keeping Yaboot for the installation CD but then using GRUB for the installed OS? > And still, my remark below should hold true: > >>> My changes also do not remove existing code related to HFS as bootstrap. I >>> expect >>> that you will be able to still create all relevant partitioning and file >>> systems >>> manually from within the Debian installer, if needed to make it work under >>> QEMU. > > >>> Other point: why can't you directly load kernel and initramfs with QEMU? >> >> That is one potential workaround, but for years everyone has booted their >> PPC VMs >> under QEMU with "qemu-system-ppc -cdrom path/to/cdrom.iso" and for me that >> is an >> extremely high barrier, particularly for novice users, to require them to >> extract a >> kernel and initrd from an ISO first. > > I don't see a reason for that, because again the boot method for the ISOs > isn't > changed. Sure, in the end the installed OS (via a default installation) is > then not > bootable via OpenBIOS anymore, but users could workaround that by extracting > kernel > and initrd and load them directly with QEMU. But again this is a large change in behaviour: the general expectation with QEMU has always been that you can boot from an installation ISO, install to a virtual HD, and then reboot the virtual HD to run your OS. Changing this so that your newly installed OS is no longer bootable would be a huge regression (and it would be me that would end up getting the angry emails). The other issue, of course is that access to real Mac hardware is quite limited these days. For example a recent DMA refactoring broke sun4m, but someone helpfully supplied a QEMU test image that enabled the regression to be fixed quickly. My concern here is that if you lose this ability, then none of the grub developers will be able to help in this way which puts much more responsibility on members of this list to chase down and fix issues if they occur. > > > BTW could the "grubfs" stuff ([1]) not be used to access FAT? I mean by just > using > `boot` and `boot-device` set to e.g. `:,\grub`? So > that the > OpenBIOS defaults don't change, but users could also boot from FAT16 on MBR > partitioned drives. The grubfs parts of OpenBIOS aren't really used (other than for early x86 experiments) and the last time I looked at this, I found that the files were certainly old enough to have endian issues on big endian architectures and there were problems mixing matching grubfs and non-grubfs drivers. So sadly this approach isn't as easy as it looks. ATB, Mark.
