• Apple
• Store
• Mac
• iPod + iTunes
• iPhone
• Downloads
• Support

At 3:38 PM -1000 6/4/07, Sergio Trejo wrote:

Thanks for pasting the above controllerHasFixedHeight error information (I was not able to find that specific information yesterday). Is it located in a header (.h) file somewhere within the recesses of Mac OS X Server?

Use the following to locate "known error" codes in OS X:

#!/usr/bin/perl
use warnings;
use strict;

# variables:
my ($path,$file,$name,$desc,$errnum);

# set the path to the header file
$path = '/System/Library/Frameworks/'
.'CoreServices.framework/Versions/Current/Frameworks/'
.'CarbonCore.framework/Versions/Current/Headers/MacErrors.h';

# open it and search for each argument.
while($errnum=shift){
    open $file, '<', $path;
    while(<$file>){
        if (m/=\s$errnum\,/) {
            $name=$_;
            $name=~s/^\s*(\S*)\s.*$/$1/;
            chomp $name;
            $desc=$_;
            $desc=~s:^.*?/\*(.*)\*/:$1:;
            chomp $desc;
            print "$name ($errnum): $desc", "\n";
        }
    }
    close $file;
}

exit 0;

However while this will give you the code description for a given error code it's usually meaningless, as I pointed out.

In your case it is very meaningless since it obviosuly doesn't apply to the tool that you are using ;) 

 Even if it is known where to find these error codes, I concur that human parsing of this information to grok semantics of what this error means is probabilistically  impossible at first glance.

It's not just that, it's like when you go to the doctor and you say "doc it hurts me to do this" and he tell's you "then don't do that".

Seriously.

The value of an error on the Mac has never been as relevant as the fact that you got the error. It's indicative of something you're doing wrong most of the time. As it was in your case.

And you are doing this with what tool(s)?

DiskUtility (I have the feeling I will be in big trouble for using the convenience of the Disk Utility GUI-based application rather than using diskutil on the command line (ducking)).

Remember "GUIs are good for making simple things simple and complex things impossible."

Really the only two situations in which I have seen the enableraid command fail is when the disk is slap full of data or if the Mac O9 drivers are installed. In these cases you will get errors like the following:

josh$ sudo diskutil enableraid mirror disk2s10
Changing filesystem size on disk 'disk2s10'...
Attempting to change filesystem size from 18232721408 to 18234343424 bytes

Filesystem grow failed, 1
Disk Management could not shrink the filesystem to fit the new raid headers
Error enabling disk to raid Invalid request (-9998)

The error would seem self explanatory here. You don't have room in the partition map for the necessary RAID headers.

What would cause my partition map to (unintentionally) change,

Nothing's causing it to change, it's just it's not adequate for what you're trying to do.

 particularly after successfully performing an asr restore at the device level to this dedicated target non-RAID partition from a compressed and checksum verified disc image snapshot (using hdiutil) which was originally made of the same partition after it had been split off from the RAID mirror successfully before destroying the mirror with the diskutil destroyRAID verb?

Again, nothing. It's just that the partition map doesn't have the room necessary to promote the disk to one that supports RAID.

 Does the destroyRAID verb cause the partition map to morph?

Yes. All the RAID verbs do.

I'd suggest you start looking at the partition maps more closely and all should be revealed.

Thank you, great advice. Should I expect that partition maps morph throughout the life and usage of disks which have multiple partitions which included one (but only one) partition which is a member of an Apple RAID mirror?

No they don't normally change at all but to enable RAID on a volume the disk's partition map must be munged to make it a disk that supports RAID.

-- 

-dhan

------------------------------------------------------------------------
Dan Shoop                                                   AIM: iWiring
Systems & Networks Architect                      http://www.ustsvs.com/
email@hidden                                http://www.iwiring.net/
1-714-363-1174