|Re: Partitions corrupted on a drive [message #335342]
||Fri, 30 December 2016 18:00
Mac User #330250
Registered: August 2012
On 2016-12-30 19:34, W. Neal Lewis wrote:
> Machine Name: Power Mac G4 (AGP graphics)
> Machine Model: PowerMac3,1
Okay, there you go. The Open Firmware of this Mac doesn't support LBA48
addressing, hence it doesn't support more than 128GB HDDs.
Actually, the real limit is that the boot partitions must be below the
128 GB barrier (in total: start+end below the limit). The OS (like Mac
OS X) has the capability to overcome this limit once it has taken
control (booted up). And as far as I know, there is only one way to do
Warning: This is not what I would do, it is too complicated for me. I
choose solution 2!
Okay, the limit is LBA28, which means Logical Block Addressing of 2^28
blocks. My calculator says, 2^28 equals 268,435,456 blocks.
This is the theory. So, WHAT YOU ABSOLUTELY NEED TO MAKE SURE:
1) make as many partitions as you like, but
2) KEEP THEM INSIDE THE 2^28 BLOCKS!
Note that only those partitions will be accessable for boot. If you
install another OS on a partition past this limit, it won't be bootable
on this Mac model!
Then, add partitions THAT START PAST the 2^28 block number! This makes
it safe for LBA28 access, because it a partition starts before the last
LBA28 block, it is accessable but will wrap around when accessed by
LBA28 disk accress and WILL OVERWRITE the beginning of your drive!
Why? The explanation is simple: when 28 bits are used to accress a
block, and the partitions starts at 2^28 -1, the disk IO will see this
partition (because it starts below the 2^28 barrier). It will then try
to accress this partition. The partition table (Apple Partition Map)
will tell the software, that performs the disk IO, that the partitions
has a specific size, but this software normally doesn't check if 2^28 -1
(block 268,435,455) + the partition size (which is most likely greater
than 1) remains in the address space of 28 bits.
Wrapping occurs. The software locates the partition, adds the size and
the 28 bits get wrapped around and start at 0.
Example: say, the partition is 10 MB, that is 10,485,760 bytes. Now, we
want to access the first block of this partition, that would be
268,435,455, which shows only the first block of the file system. This
will try to load the second block, 268,435,455+1 = 268,435,456. And this
will tell the software to look for offset 3 inside the partition. BUT
268,435,455+3 doesn't fit into 28 bits. So, after 268,435,455 comes (+1)
268,435,456, thereafter (+2) 0, and thereafter (+3) 1. So the software
will read block 1 instead of block 268,435,455+3=268,435,458. So far,
only an error accurs. But let's assume, for whatever reason, the
software thinks it has to WRITE to a block - IT WILL OVERWRITE what is
written in the first blocks (starting from 0) of that hard drive. And
software often thinks it has to write something, e.g. access times.
SO: MAKE SURE THERE IS NO PARTITION CROSSING BLOCK 268,435,456!
You /could/ use pdisk to make partitions below block 268,435,456--that
start and end there--and partitions that start past block 268,435,456
and you should be safe.
My problem with this is as follows: pdisk and Disk Utility doesn't give
block numbers, it gives partition sizes in MB or GB. Or, it could round
those numbers, who knows...
Take advantage of your Mac being limited to LBA28. Boot with a Mac OS X
installation disc and make your partitions, you may even install Mac OS
X. Note that only 128 GB will be visible in Disk Utility and that is
because of LBA28.
Then, apply the Open Firmware hack to add LBA48. NOTE: This doesn't
really make the firmware LBA48--the Open Firmware will still be limited
to LBA28, hence all boot partitions (i.e. Mac OS 9, Mac OS X) MUST be
below the 2^28 block barrier! BUT the hack will fool Mac OS X into
thinking that the firmware is LBA48 aware and now Disk Utility will show
the full >128 GB capacity.
The hack is shown there:
Use the enable-lba48 script: copy&paste it in TextEdit and safe it where
you can find it in Terminal. In Thermal, make the script executable:
1) Go to the folder where you saved enable-lba48, e.g. "cd
2) Make the script executable: "sudo chmod ug+x enable-lba48" (chmod
means "change mode" and "ug+x" means "user and group: +x", and "x" means
3) Run the script: "./enable-lba48" -- the script acquires root
previliges automatically when needed.
4) JUST FOR INFO: To remove the hack, simple reset the PRAM. Hold
Option+Alt+P+R at the chime. See:
https://support.apple.com/en-us/HT204063 (I know, this is for Intel
Macs, but the keys to press hasn't changed.)
Afterwards, every Mac OS X you boot will think that the Open Firmware
(abbr. OF) of this Mac is capable of LBA48 (even though we know it's not!).
Now comes the second part: add partitions. For this you really require a
Mac OS X 10.5 Leopard installation disc. Before Leopard, Disk Utility
was not able to extend partitions. So, if you boot Tiger, you cannot add
partitions behind the first already partitioned 128 GB.
Leopard on the other hand will find the >128 GB capacity of the HDD
(because of the OF hack) AND is able to extend the existing Apple
Partition Map (abbr. APM). What you now have to do is simply add
partitions to your liking, BUT KEEP the existing partitioning within the
first 128 GB.
DONE. You successfully partitioned without crossing the 2^28 block!
> CPU Type: PowerPC G4 (2.1)
> Number Of CPUs: 1
> CPU Speed: 1 GHz
>> My advice is that you boot up with an installation disc of Mac OS X
>> 10.5 Leopard, use its Disk Utility (it can be started from the menu).
> I have been booting from a 10.4.11 CD and that is the disk utility
> that cannot fix things. Will a 10.5 disk even work?
Yes, since your Mac has >867 MHz. Otherwise you would have to use
another hack to get the installer to continue. Note that if you Mac
isn't supported by Leopart (Mac OS X 10.5) then it will show a message
and it WILL NOT let you start Disk Utility. That is very unfortunate.
But with your Mac it should work.
This would be a hack to fool Leopard to continue:
BTW, Leopard will run nicely on your Mac:
On 2016-12-30 22:53, W. Neal Lewis wrote:
> $ diskutil list
> #: type name size identifier
> 0: Apple_partition_scheme *279.5 GB disk0
> 1: Apple_partition_map 31.5 KB disk0s1
> 2: Apple_Driver_ATA 50.0 KB disk0s2
> 3: Apple_HFS 23 GB Disk 19.1 GB disk0s3
> 4: Apple_HFS eDrive 4.0 GB disk0s4
> 5: Apple_HFS Art Hard Drive 104.9 GB disk0s5
> 6: Apple_HFS 128 GB Disk 3 128.2 GB disk0s6
> #: type name size identifier
> 0: Apple_partition_scheme *465.8 GB disk1
> 1: Apple_partition_map 31.5 KB disk1s1
> 2: Apple_Driver_ATA 50.0 KB disk1s2
> 3: Apple_HFS OS X 64.0 GB disk1s3
> 4: Apple_HFS OS 9 64.0 GB disk1s4
> 5: Apple_HFS 128 GB Disk 1 128.0 GB disk1s5
> 6: Apple_HFS 128 GB Disk 2 128.0 GB disk1s6
> 7: Apple_HFS 82 GB Disk 81.8 GB disk1s7
That is dangerous: I cannot see for sure on the first HDD (disk0), you
might be lucky and your 105 GB partition "Art Hard Drive" is as a whole
below the 128 GB limit, but I am not sure.
BUT TAKE A LOOK AT YOUR SECOND DRIVE: you have OS X and OS 9 on 64 GB
partitions each, totalling 128 GB. But there are a couple of smaller
partitions in front, so my guess is that your OS 9 partition crosses the
THIS IS VERY DANGEROUS. Why? Because during early Open Firmware
supported boot, some files MAY be located past the 2^28 block limit,
wrapping will occur, and the boot will fail OR CORRUPT your partition!
Sorry to say it, but there is no easy way out. You will have to backup +
repartition your whole internal HDDs!
You can use Disk Utility to backup Mac OS 9 and Mac OS X into images.
They can easyily be restored from a booted Mac OS X from another HDD
(i.e. an external FireWire HDD that you booted Mac OS X from).
Two more things to consider:
1) The LBA28 limit is only on the internal IDE ports. If you have a PCI
IDE controller card installed, this may well support LBA48. If your
drives are SCSI drives, there is also no LBA28 limit. If you put the HDD
into an external FireWire drive case, there is also no LBA28 limit and
everything should boot fine!
2) Your Mac OS X can access the partitions past the 2^28 block. Why? Is
the KeyLargoATA.kext of this installation already LBA28->LBA48 patched?
And which driver to you use on your Mac OS 9 for >2^28 block access?
(There have been a few commercial drivers to allow LBA48 disk access on
those Macs, but they did cost quite a few bucks.)
So, I know this has been quite too much.
Again, I would go with solution #2. Use trial+error for understanding
the LBA28 vs. LBA48 problem.
I hope this isn't too much,
Mac User #330250 aka Andreas
You received this message because you are a member of G-Group, a group for those using G3, G4, and G5 desktop Macs - with a particular focus on Power Macs.
The list FAQ is at http://lowendmac.com/lists/g-list.shtml and our netiquette guide is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to email@example.com
For more options, visit this group at http://groups.google.com/group/g3-5-list
You received this message because you are subscribed to the Google Groups "G-Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/d/optout.