Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » PowerPC Macs » Re: Partitions corrupted on a drive (UPDATE: typos fixed+parts rewritten)
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Partitions corrupted on a drive (UPDATE: typos fixed+parts rewritten) [message #335341] Sat, 31 December 2016 08:20 Go to next message
Mac User #330250 is currently offline  Mac User #330250
Messages: 83
Registered: August 2012
Karma: 0
Member
Hello Neal!
(Sorry, my first attempt had numerous errors such as typos. I've also
rewritten parts and added a TO-DO, what I would do).
THIS IS THE UPDATED VERSION OF THE SAME EMAIL.

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
it right.

SOLUTION 1:
===========
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. A block is
normally 512 bytes large, i.e. 128 GB (1,024 bytes) or 137 GiB (1,000 bytes)

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 if a partition starts before the last
LBA28 block, it is accessable but will wrap around when accessed by
LBA28 disk access and WILL OVERWRITE the beginning of your drive!

Why? The explanation is simple: WRAPPING.

Let me explain wrapping with 4 bits (not 28, that would be too large an
example). 0000 is binary for 0 decimal.
bin / dec
0000 = 0
0001 = 1
0010 = 2
0011 = 3
0100 = 4
0101 = 5
0110 = 6
0111 = 7
1000 = 8
1001 = 9
1010 =10
1011 =11
1100 =12
1101 =13
1110 =14
1111 =15

Lets assume we add 1 to our last number, the one that is the greatest
number for 4 bits: 15+1.
10000 = 16

10000 (to represent the number 16, 15+1) is five bits long. BUT we only
have 4 bits. So the 5th highest bit isn't used. Instead of 10000 only
0000 is saved in 4 bits. BUT 0000 = 0. THAT is WRAPPING.

The partition example: a partitions starts below 2^28 but reaches
outside its highest block number: the partition will be accessable. BUT
any program (INCLUDING the Open Firmware and early Mac OS boot
processes) will add block numbers to the partition starting block just
like in the 4 bits wrapping example.

Assume the boot process locates a file on the partition with an offset
that is outside the 2^28: it will read another block, that is actually
at the begin of the HDD. But that is not the worst part, because this
will /only/ make the boot-up fail.

THE WORST PART: file systems tend to be written to! Say, the boot-up
initiates an update in access times. The file system wants to save a new
"last accessed" time for a specific file. IT MAY WELL BE that the
location, where to store this information i.e. this block inside the
filesystem, happens to be OUTSIDE the 2^28 bit of blocks area, because
the partitions reaches outside this limit. THEN YOU WILL CORRUPT the
data that is saved at the other end of the HDD! With a really high
lickelyness that the first blocks will be overwritten (blocks 0++).
THOSE BLOCKS CONTAIN THE PARTITION MAP ITSELF! So, not only will you
corrupt the first partitions, you are very likely to corrupt the Apple
Partition Map, hence preventing every ordinary access to the HDD thereafter!

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, diskutil and Disk Utility
doesn't give block numbers! They give partition sizes in MB or GB. Or,
it could round those numbers, who knows...

If your partitions get close to 128 GB, you cannot be certain that block
2^28 i.e. block 268,435,456 isn't crossed by a partition! (The reverse
is also true: after applying the OF hack, you cannot be certain that a
partition start paste the 2^28 block when all you see is numbers in GB
and MB!)


SOLUTION 2:
===========
To elliminate this possibility, take advantage of your Mac being limited
to LBA28 in the first place! 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.
(Naturally for this you will have to use an unpatched Open Firmware,
i.e. don't use the OF hack yet. If you did already, reset the NVRAM/PRAM
before you partition+install!)

Then, apply the Open Firmware (abbr. OF) hack to add LBA48. NOTE: This
doesn't really make the firmware LBA48 aware--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. (Another note: every Mac OS before
10.5 Leopard will use an existing Apple Partition Map and will NOT
modify it! So, if the first partitioning was done with a 128 GB limit,
it will stay that way--using Leopard can overcome this restriction!)

The hack is shown there:
https://4thcode.blogspot.co.at/2007/12/using-128-gib-or-larg er-ata-hard-drives.html


Use the enable-lba48 script: copy&paste it in TextEdit and safe it where
you can find it in Terminal. In Terminal, make the script executable:
1) Go to the folder where you saved enable-lba48, e.g. "cd
/Users/Neal/Desktop"
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
executable)
3) Run the script: "./enable-lba48" -- the script acquires root
previliges automatically when needed (may prompt for you password again).
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 OF of this Mac
is capable of LBA48 (even though we know it's not!), for as long as the
PRAM (parameter RAM) remains. The hack will be lost by resetting the
PRAM/NVRAM and also when your Mac's PRAM battery get empty. But you can
always reapply the hack at anytime.

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. (The reason: the
HDD was partitions with a 128 GB limit in place, hence the partition
table "Apple Partition Map", abbr. APM, stored this maximum value. Mac
OS X before Leopard will not extend this written limit!)

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 (APM). What you now have to do is simply add partitions to
your liking BEHIND THE FIRST 128 GB, BUT KEEP the existing partitioning
within the first 128 GB UNTOUCHED.

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 your Mac
isn't supported by Leopard (Mac OS X 10.5) then it will show a message
"unsupported Mac" and it WILL NOT let you start Disk Utility. That is
very unfortunate, because this will make you additionally have to use
the Leopard OF hack (which is quite complicated!).

But with your Mac it should work (because of the 1 GHz processor).

This /would be/ a hack to fool Leopard to continue:
http://lowendmac.com/2007/fooling-the-os-x-10-5-leopard-inst aller-with-open-firmware/


BTW, Leopard will run nicely on your Mac:
http://lowendmac.com/2007/unsupported-os-x-10-5-leopard-inst allation/


On 2016-12-30 22:53, W. Neal Lewis wrote:
> $ diskutil list
> /dev/disk0
> #: 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
> /dev/disk1
> #: 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

I see danger here! (Wrapping!)

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 cannot be 100% certain.


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 two smaller partitions
in front, so my guess is that your OS 9 partition crosses the 2^28 block!

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!

IF YOU ARE VERY UNLUCKY, WRAPPING WILL CORRUPT THE PARTITION TABLE ITSELF!



CONCLUSIO
=========

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).

Three more things to consider:
1) The LBA28 limit is only on the internal IDE ports (called
"KeyLargo"). If you have a PCI IDE controller card installed: it 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.)
3) Only Mac OS X can be fooled by the OF hack. If you start from a disc
containing another OS, i.e. DiskWarrior using classic Mac OS, this will
not let you see past the 2^28 block number and thus you will not be able
to use DiskWarrior with partitions past 128 GB! Using DiskWarrior or any
other affected software on a partition that start before this barrier
but reaches past block 2^28 WILL RESULT IN CORRUPTION on Macs before the
2002 Quicksilver G4!


So, I know this has been much.
Again, I would go with solution #2. Use logical thinking for
understanding the LBA28 vs. LBA48 problem and trial+error when trying to
do fix this issue.


TO-DO
=====
1) Backup partitions into disk images using Disk Utility (or Carbon Copy
Cloner, version 3.4.7 for Mac OS X Tiger/Leopard is free)
https://support.apple.com/kb/PH22247?locale=en_US
https://bombich.com/download
2) Make sure your OF is unhacked by resetting the PRAM and NVRAM (hold
Opt+Alt+P+R and Opt+Alt+N+V for at least two chimes)
3) Install a clean version of Mac OS X: partition the first 128 GB with
Disk Utility from the menu of the installation media. When you
partition, select "include Mac OS 9 driver" and you may again make two
partitions: one for Mac OS 9, one for Mac OS X.
HINT: Install Mac OS X on the Mac OS 9 partition!
4) Boot the just installed Mac OS X (from the wrong partition, i.e. the
Mac OS 9 partition) and RESTORE the backup of Mac OS X from step 1!
5) Boot Mac OS X from the correct partition. Use this to restore Mac OS
9 (from step 1) to its partition (overwriting the clean Mac OS X
installation)
6) Boot Mac OS X Leopard installer. Use its Disk Utitily to create the
remaining partitions past the 128 GB limit.
7) Restore the remaining partitions.


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 g3-5-list@googlegroups.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 g3-5-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Partitions corrupted on a drive (UPDATE: typos fixed+parts rewritten) [message #335364 is a reply to message #335341] Sun, 08 January 2017 21:16 Go to previous messageGo to next message
peterhaas is currently offline  peterhaas
Messages: 80
Registered: September 2012
Karma: 0
Member

> (Sorry, my first attempt had numerous errors such as typos. I've also
> rewritten parts and added a TO-DO, what I would do).
> THIS IS THE UPDATED VERSION OF THE SAME EMAIL.
> ...

It is my understanding that if the LBA48 property has been introduced to
O.F. "persistently", then a volume which is larger than 128 GB may indeed
be the boot volume.

But, it is still safer to limit the boot volume to two partitions, the
first of which is 128 GB (131,072 MB, actual capacity) with the remainder
being used for data storage which is not boot-dependent.

Thereafter, the other volumes may be larger than 128 GB.

Just a short refresher course:

1) the basic support, which is pre-MDD, is LBA28,

2) support for LBA48 before or during boot may be added "persistently"
using the O.F. hack, and

3) support for LBA48 after boot may be added using the Intech High-Cap
kernel extension, for appropriate versions of MacOS X, and

4) LBA48 really means that the OS software sends TWO commands (CDBs) to
the controller, the first of which contains the first 28 bits, and the
second of which contains the remaining 20 bits).

The only PowerPC Mac which I still have on my desk is a Mirror Drive Door
model, and the MDD models all have LBA48 permanently available.

My MDD machine was supplied with two very large HDDs, and both seem to
work appropriately. The machine also included two DVD burners which is
certainly a luxury.



--
--
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 g3-5-list@googlegroups.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 g3-5-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Partitions corrupted on a drive (UPDATE: typos fixed+parts rewritten) [message #335418 is a reply to message #335364] Mon, 09 January 2017 16:03 Go to previous messageGo to next message
Mac User #330250 is currently offline  Mac User #330250
Messages: 83
Registered: August 2012
Karma: 0
Member
Hello Peter!

On 2017-01-09 03:16, peterhaas@cruzio.com wrote:
> It is my understanding that if the LBA48 property has been introduced to
> O.F. "persistently", then a volume which is larger than 128 GB may indeed
> be the boot volume.

Unfortunately this is not true. During the boot process, the first
stages rely on Open Firmware implemented functions to load files from a
(boot) volume. Since the OF only supports LBA28, a read or (more fatal:)
write to a position beyond the first 128 GB will fail and, consequently,
the boot will fail.

For Mac OS X, this first stage is BootX. See
http://osxbook.com/book/bonus/ancient/whatismacosx/arch_boot .html
(scroll down, read chapter "Bootloader"). Before BootX loads and
executes the kernel, it relys heavily on OF. And I do not know at which
stage the kernel, XNU, stopps to rely on OF functions, because loading
the kexts (and the kext cache) could still be OF dependant. Once the
KeyLargo kext is loaded, OF is no longer used for ATA disk I/O.

So, why may a bigger partition work anyway? Well, you may just be lucky
and all files required for boot in the OF dependant stage are below the
28-bit LBA barrier.

Nevertheless, using such a partitioning is a poker game. One day, when
the partition is really filled, the operating system may rebuild the
boot files (as it does already for kernel extensions, kexts -- it keeps
a cache) and it will use the next available free blocks on that volume.
The user has no control over this and the boot will "suddenly" fail --
or act weird -- BECAUSE of LBA28 2^28 bits wrapping.
This will definitely happen if you install an update for Mac OS X, say
from 10.4.8 to 10.4.11, and the partition is already filled past 128 GB
of the total size of the HDD.

Also note that Open Firmware will present every volume with boot
information on it that it can access. If a partitions starts before the
2^28 LBA limit and its boot files (which make OF think it can boot from
this volume) happen to be below block 268,435,455, then OF will show it
as a bootable volume. However, such a volume is hugely affected by LBA
block wrapping!

All volumes that start above the 2^28 block limit, bootable or not, will
not be shown (and will not be accessably in any way)by Open Firmware.

> But, it is still safer to limit the boot volume to two partitions, the
> first of which is 128 GB (131,072 MB, actual capacity) with the remainder
> being used for data storage which is not boot-dependent.

It really is the only *safe* way.

> Thereafter, the other volumes may be larger than 128 GB.


Yap. Starting at block 268,435,456 you can make one big partition and be
safe.


I had a 512 GB drive and split it 64 GB for Mac OS 9 and 64 GB for Mac
OS X (totalling the first 128 GB with the LBA28 block limit being the
end of the Mac OS X partition) and the rest was one big 384 GB data
partition (which was accessable once Mac OS X had booted with the OF
hack or the modified KeyLargo.kext).

I didn't file a free solution for Mac OS 9 though.


Cheers,

Mac User #330250

--
--
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 g3-5-list@googlegroups.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 g3-5-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Partitions corrupted on a drive (UPDATE: typos fixed+parts rewritten) [message #335419 is a reply to message #335364] Mon, 09 January 2017 16:15 Go to previous messageGo to next message
Mac User #330250 is currently offline  Mac User #330250
Messages: 83
Registered: August 2012
Karma: 0
Member
About BootX and Open Firmware, I found one more:
https://opensource.apple.com/source/bless/bless-11/README.BO OTING

It explains that BootX uses OF to load files. And before the QS 2002, OF
was limited to LBA28, i.e. 128 GB.
The /simple/ truth and the reason for the complicated work-around.

Cheers,
Mac User #330250

--
--
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 g3-5-list@googlegroups.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 g3-5-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Partitions corrupted on a drive (UPDATE: typos fixed+parts rewritten) [message #335420 is a reply to message #335418] Mon, 09 January 2017 16:25 Go to previous message
peterhaas is currently offline  peterhaas
Messages: 80
Registered: September 2012
Karma: 0
Member

>> But, it is still safer to limit the boot volume to two partitions, the
>> first of which is 128 GB (131,072 MB, actual capacity) with the
>> remainder
>> being used for data storage which is not boot-dependent.
>
> It really is the only *safe* way.
>
>> Thereafter, the other volumes may be larger than 128 GB.

Indeed so, and this was my eventual realization.

But, at THAT time, 120 GB ATA drives were common. Today, they are a
rarity. My smallest ATA drive is presently a pair of 160 GB drives which
are in a MacMini G4 which is being used as a server.

My final solution was to modify my Beige G3, reverting the ROM from 3C to
1A, which removed the two drive capability per ATA channel, and to go to
an all-UW-SCSI implementation for my hard drives.

I had drives in the "basement" of the Beige, and also in the conventional
locations.

My N-SCSI channel was used for a DAT tape drive for backups.

These days, my only operational Mac tower from the G3/G4 family is
presently a MDD.

I think you are probably right ... I was "lucky" that the O.F. hack worked
for me as that logical volume was mostly unfilled.

I had also experimented with using the O.F. hack for the third and fourth
ATA devices, but this was not without its problems, either.



--
--
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 g3-5-list@googlegroups.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 g3-5-list+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: SATAII 3Gb/s PCIe PowerMac G5 Boot Controller
Next Topic: HD recommendations for 2002 Quicksilver G4
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 14:26:56 EDT 2024

Total time taken to generate the page: 0.03088 seconds