Garbled Data on Drive: RAID/non-RAID confusion? [COLUG]

[Jim]

Kent Broestl wrote:

> More clarification to the kernel:
> If I don't have the modules for RAID 1 and RAID 0 compiled, 
> it won't mount the drive. 

Is it possible that the drive was written to (such as partitioned 
and/or formatted) as a non-RAID drive, then later written to as 
a RAID drive? 

My _vague_ recollection is that software RAID uses some of the 
beginning of the drive for some RAID overhead information. 
_If_ that is true, then changing the RAID status also changes 
the location of the partition table and partitions on the drive, 
yielding much confusion when sometimes the drive is written to 
as a non-RAID drive, and as a RAID drive other times. 

With dd images of a _whole_ drive (not of just a partition), 
one can mount partitions therein by making use of the offset 
option for loopback devices. You might tease out some access 
to a mislocated partition by such. Figure out what the 
offset should be by playing with the raw _whole_ drive image 
with various combinations of dd, xxd, strings and less. 

I wrote to backup _whole_ drive images: 

>    dd if=/dev/hdx | tee hdx.0 | md5sum

but you wrote that you only backed up a mere _partition_: 

> ... dd if=/dev/hdf1 | tee hdf.0 | md5sum

When the beginning of a partition is itself an issue, 
the backing up a mere partition can be insufficient. 
Back up the whole stinking drive, not just a partition. 

Figuring out loopback offset stuff is tricky. Learn how to 
do it by first playing with a know good _whole_ drive image 
that is known to have never had the slightest hint of any RAID 
exposure or confusion. A sample command looks like: 

   mount -t ext2 -o ro,loop,offset=10485760 ~jim/foo/sda.3 /mnt/

Back to your confused drive. If it has been written to 
both with and without RAID, it might have been written to 
in wrong places, messing up partitions, so even when you 
find the actual beginnings of partitions, don't be 
surprised if fsck complains. 

Jim