Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'A workaround for the 8gb partition limit on Beige G3s' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
A workaround for the 8gb partition limit on Beige G3s
Authored by: dmackler on Apr 05, '04 01:47:46PM

This should be okay.

XPostFacto includes the ability to boot of off firewire disks, and large partitions, by installing a small bootloader into another partition, including an OS 9 partition. That bootloader (actually a directory full of stuff) will boot, and then switch to large partition. So it should be perfectly safe.

Ryan (the author) has done some absolutely amazing stuff with these older machines.

David

---
David



[ Reply to This | # ]
A workaround for the 8gb partition limit on Beige G3s
Authored by: Marcot1 on Apr 05, '04 05:30:19PM

Ryan has done some amazing things no doubt, I used some of his early work to install 10.0 on to my Umax S900.

Firewire is a totally different animal then IDE on any machine suffering from the 8GB limit. The limit is imposed by a limitation of the Built-in IDE controller, firewire, SCSI, and PCI IDE controllers are not affected by this bug.



[ Reply to This | # ]
A workaround for the 8gb partition limit on Beige G3s
Authored by: thornrag on Apr 06, '04 09:55:42PM

Perfectly safe it is not. First of all, Ryan's work on "Helper disks" in XPostFacto is intended for booting OS X from otherwise unsupported external FireWire hard disks. His tricks have nothing to do with the 8 GB limitation. In fact, his tricks don't kick in until after the limitation has had its effect. I'll explain.

The issue is with the way an OS X system boots, which is not unlike the way a FreeBSD system boots. First, Open Firmware and hardware on the logic board run a small bit of code at the very beginning of a hard disk's writable area. That code then launches another small bit of code, slightly larger than the first, but also near the start of the hard disk, which is able to find the operating system kernel on the hard drive and start it running as well. Once the kernel is running, the computer starts on up.

The problems arise when the OS kernel is not within the space on the hard disk that Open Firmware can access on its own. The size of this space is limited essentially by how high Open Firmware can count, which is limited by the hardware Open Firmware is running on. If Open Firmware can't count high enough to find the kernel, the boot fails.

Sure, when the OS is loaded, the operating system's high-level drivers can gain full access to hard disks of size limited only by the ATA bus itself. That's why things seem to work if you shovel an oversize partition into a Beige G3, provided of course you're lucky enough to have the kernel close enough to the start of the disk that OF can find it. But until the OS is loaded, Open Firmware is on its own.

As for OS 9, the boot process is slightly different, which accounts for its success with larger partitions. Parts of what would be OS 9's kernel are stored in the ROM on the motherboard, so the system can actually get up and running well enough to find the operating system and load the higher-level drivers for the disk without the size of the partition becoming an issue. On the most recent machines, of course, Apple has finally eliminated this ROM support from the motherboard... which means, sadly, no more booting OS 9. The good news is, these newer motherboards can boot from virtually any size partition.

As for XPostFacto, the boot process is almost literally jumping through hoops. He has basically customized a version of the Mac OS X kernel to load and immediately re-load another kernel stored on an external volume. His kernel has support for external devices that the on-board hardware doesn't have. The boot process then goes like this: 1. Firmware loads boot sector code. 2. Boot sector code loads boot sector code part II. 3. Boot sector code II loads Ryan's custom kernel, which loads support for external disks. 4. Ryan's kernel finds the *real* kernel on the external disk and boots up OS X from there. So as you can see, the 8 GB limitation *still* applies, because the process may still fail before the boot sector code can load even Ryan's kernel.

In the end, you may get lucky. But this is all a terrible idea. At best, you may find yourself unable to boot your machine when your massive research project needs to be printed out and turned in. At worst, you'll find yourself facing serious data corruption. So resist the temptation and install on an < 8 GB partition.



[ Reply to This | # ]
A workaround for the 8gb partition limit on Beige G3s
Authored by: mfulghum on Apr 08, '04 06:28:28PM

It _is_ perfectly safe if your so called "helper" is completely within the 8GB limit. as a matter of fact, the only thing I'd change about what this guy is doing is to create partition one as 7500 Meg, do a complete install of OS 9 and Panther to it, CCC it to the 112 GB partition two, and then tell XPF to boot P2 using P1 as a helper. as long as the kernel and support files are on partition one in the hidden "helper" directory, this works just fine.



[ Reply to This | # ]