dmboot: failed to auto-import disk group ServerDG0

[Michael]

Hi,
I'm trying to restore a server that had its boot disk fail.

It has three hard disks. The boot drive was a basic disk but there were two
300Mb drives that were dynamic.

After the restore I'm unable to access the two dynamic disks.

I'm getting the following message in the event log :

dmboot: failed to auto-import disk group ServerDG0. All volumes in the disk
group are not available

My googling only shows something about importing foreign disks - but this
option is greyed out.

When I try to re-activate the disks I get a message that says :

Internal Error: Disk group has no valid configuration copies.

Any ideas ?

Regards
Michael

[nylrem]

If you get these two event log messages:

dmboot: Failed to auto-import disk group <machine_name>Dg0. All volumes in the disk group are not available.

and

INTERNAL Error - The disk group contains no valid configuration copies (C10000B6).

with no complaints about actual invalid data (like magic numbers or specifics on corrupted configuration blocks), then I suspect the problem is not a HW problem.

Instead, I suspect that Windows XP (and possibly Vista?) can't deal "correctly" with a "disk group" (aka "Dg0" above) that is missing one of its member drives.

In such a case, the easiest solution might be to put all the disks in the group back in one computer, import the group if necessary, then copy all the data off of the dynamic disks to basic disks and never use dynamic disks ever again. This is assuming that none of the drives have actaully failed, and the error messages above started happening when drives got removed/added.

Blah blah blah:

Unfortunately XP and Vista both only support one "disk group", and so even if you have just a "Simple volume" on one of your dynamic disks, and another "Simple volume" on another of your dynamic disks, if you try to boot with only one of these disks present, then I bet you'll get the above error messages and I bet you won't be able to get to your data using the Windows UI. I bet in that case you'll either have to resort to "manually" converting your "Simple volume" to a partition on a "Basic" disk, or you'll have to put back whatever dynamic disks you removed, and get all the data off of all your dynamic disks, then format your dynamic disks back to basic disks.

If you have a RAID0 striped arrangement over two disks 1 and 2, say, and another separate "Simple volume" on a separate dynamic disk 3, say, and the dynamic disk 3 fails, then it means you can't access your RAID0 volume using the normal built-in Windows SW and normal Windows UI, even though all the drives involved in the RAID0 volume are just fine. Also, you can't use the "manual convert" option either because it's a RAID0 volume and basic disks don't do software RAID0 volumes. See Appendix A for a discussion of the "manual convert" option.

The same logic may apply when moving disks to another computer. If you tried to move only disk 1 and 2 from the above configuration, I'd bet that "import" wouldnt' work because disk 3 is missing from the "disk group" you're trying to import.

My advice is this:
1. Don't use dynamic disks unless you have to. Use "Basic" disks and a normal "primary" partition for all your disks unless you understand exactly what I'm saying in the next point.
2. If you're going to use dynamic disks, keep it simple and make sure you won't be bitten by the "missing volume" thing explained above. In other words, it's fine to have a couple dynamic disks that are RAID0'd together into a single volume (RAID0 has it's own associated added risks), or a couple dynamic disks that are "spanned" together into a single volume (spanning also has it's own associated risks), but if you have both at once, it means that if either the RAID0 volume or the spanned volume fails due to just one of the four dynamic disks failing, you've lost SW access to the other volume as well (for no good reason). Just keep in mind that if one dynamic disk fails, you very likely will not be able to get to any of the other dynamic disk data on your entire system without extreme SW measures (potentially beyond the "manual" convert to dynamic steps offered by others if you're using RAID0 or spanning). Set it up so that a dynamic disk failure taking out all your dynamic disks doesn't piss you off any more than that disk failure normally would. For example, set it up so you're only creating one volume using dynamic disks, and you'll be no worse off than you'd expect to be due to a disk failure (no viral effect on other volumes, because there's only one volume on your system created using dynamic disks). If you lose one dynamic disk you effectively lose SW access to all volumes based on dynamic disks in your entire system, regardless of whether said volumes actually physically rely on the lost disk.
3. Back up often. If you care about the data, and it's only on one disk, you're asking for it.

Appendix A:
The "manual convert" option is when you "manually" edit your partition tables and such with a tool so that the flat volume data on the dynamic disk doesn't have to move as you change the dynamic disk into a basic disk with a single primary partition that happens to contain the same flat volume data at the same offset and length. This only works if it's a flat "Simple volume" stored entirely on a single dynamic disk. This option is not for noobs. Since you have a flat "Simple volume" entirely on a single dynamic disk, and since you were the person who created this thing (presumably), that means you were until recently a noob on this subject. Get a non-noob to help you unless this was just a small island of noobiness in a vast ocean of badassitude. And make sure the non-noob knows what it means to do a sector-level backup of the entire drive before the supposed non-noob starts writing anything to your disk. Even a decent non-noob might need to try this a few times before getting it just right, and so a sector-level backup of the entire disk is a *required* first step. Be patient. Do not rashly start writing crap to the disk using advanced tools without first making a sector-level backup with something like FAU dd. Be careful.

The entire above message may be total BS - it's based on my limited experience and some trolling around in the forums.