Title: Re: RAID-specific "-9998" errors
(enableRAID and addToRAID
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."
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
This email sent to email@hidden
