Invalid superblock on drives in array

Invalid superblock on drives in array

[Peter Jonsson]

Hi!

I'm running a RAID-5 setup using six Seagate ST19171W SUN9.0G drives off a
Sun Multipack connected to an Adaptec 2940UW. I used to have the multipack
connected to a Sparcstation 5 but I moved it yesterday. Everything was
running fine until I rebooted the machine.

Now I get this error message :

[events: 00000000]
md: invalid raid superblock magic on sda1
md: sda1 has invalid sb, not importing!
md: could not import sda1!
md: autostart sda1 failed!

I tried to get some more information with mdadm. This is what I got :

[root@colossus root]# mdadm -E /dev/sd[abcdef]
mdadm: No super block found on /dev/sda (Expected magic a92b4efc, got 6c6c6c6c)
mdadm: No super block found on /dev/sdb (Expected magic a92b4efc, got add66bb5)
mdadm: No super block found on /dev/sdc (Expected magic a92b4efc, got add66bb5)
mdadm: No super block found on /dev/sdd (Expected magic a92b4efc, got 6c6c6c6c)
mdadm: No super block found on /dev/sde (Expected magic a92b4efc, got 6c6c6c6c)
mdadm: No super block found on /dev/sdf (Expected magic a92b4efc, got 6c6c6c6c)

I'm not really sure what happend. I think what I did was to reboot the
machine to use a new kernel. This machine was a clean RH9 installation and
I applied a 'yum upgrade' to it after installing yum. I have since tried
to use the array with the older kernel but that don't work either.

Is there anyway I can fix the super blocks and reclaim the data or is it
lost?

// peter
--
If God is real, s/he might be integer (e.g. 0). If God is complex, then s/he might be imaginary.

Re: Invalid superblock on drives in array

[seth vidal]

On Thu, 2003-12-25 at 11:58, Peter Jonsson wrote:
> Hi!
> 
> I'm running a RAID-5 setup using six Seagate ST19171W SUN9.0G drives off a
> Sun Multipack connected to an Adaptec 2940UW. I used to have the multipack
> connected to a Sparcstation 5 but I moved it yesterday. Everything was
> running fine until I rebooted the machine.
> 


if this was running on a sparc then you might want to look at:

mdadm --update=sparc2.2

look at the mdadm man page:

              The  sparc2.2 option will  adjust the superblock of
              an array what was created on a Sparc  machine  run-
              ning  a  patched 2.2 Linux kernel.  This kernel got
              the alignment of part of the superblock wrong.  You
              can use the --examine --sparc2.2 option to mdadm to
              see what effect this would have.




> I'm not really sure what happend. I think what I did was to reboot the
> machine to use a new kernel. This machine was a clean RH9 installation and
> I applied a 'yum upgrade' to it after installing yum. I have since tried
> to use the array with the older kernel but that don't work either.
> 

Oh and I'm also the yum author and I assure you, yum doesn't touch
ANYTHING related to raid arrays, it just updates packages :)

-sv

Re: Invalid superblock on drives in array

[Peter Jonsson]

On Thu, 25 Dec 2003, seth vidal wrote:

> if this was running on a sparc then you might want to look at:
>
> mdadm --update=sparc2.2

I wasn't clear enough. I got into problems when I moved the array from the
sparc to the PC so I backed up all the data and then I recreated the array
and formatted the drive (ext3) before moving all the data back.

But I tried it anyway with this result :

[root@colossus mdadm-1.4.0]# ./mdadm --update=sparc2.2 /dev/md0
--update does not set the mode, and so cannot be first.


I just tried to use mkraid to upgrade the superblocks (if that was the
problem) but it seems that something else is wrong.

[root@colossus mdadm-1.4.0]# mkraid --upgrade /dev/md0
handling MD device /dev/md0
analyzing super-block
cannot upgrade magic-less superblock on /dev/sda1 ...
mkraid: aborted.
(In addition to the above messages, see the syslog and /proc/mdstat as
well
 for potential clues.)

> Oh and I'm also the yum author and I assure you, yum doesn't touch
> ANYTHING related to raid arrays, it just updates packages :)
>
Well, I wasn't implying that yum would do anything to the array. It was
just to explain that the machine was newly installed. :)

It had been running for about 1½ days before something happend. I actually
don't have any idea what might have happend. Something is wrong with the
superblocks but I have idea how that happend. Act of God? ;)

// peter
-- 
If God is real, s/he might be integer (e.g. 0). If God is complex, then s/he might be imaginary.

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Invalid superblock on drives in array

[seth vidal]

On Thu, 2003-12-25 at 12:27, Peter Jonsson wrote:
> On Thu, 25 Dec 2003, seth vidal wrote:
> 
> > if this was running on a sparc then you might want to look at:
> >
> > mdadm --update=sparc2.2
> 
> I wasn't clear enough. I got into problems when I moved the array from the
> sparc to the PC so I backed up all the data and then I recreated the array
> and formatted the drive (ext3) before moving all the data back.
> 
> But I tried it anyway with this result :

hmm. I bet the drive labels are screwed up. For fun, stop the array,
load up fdisk on one of the disks and type 'o' - that should make new
dos disk labels.

it's something I ran into, but this was a long time ago, so the above
info might be out of date./

so make new drive labels, repartition and recreate the array.

see if that doesn't fix it.

> It had been running for about 1½ days before something happend. I actually
> don't have any idea what might have happend. Something is wrong with the
> superblocks but I have idea how that happend. Act of God? ;)

migration from sun to pc or possibly general system gremlins.

good luck
-sv


-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Invalid superblock on drives in array

[Peter Jonsson]

On Thu, 25 Dec 2003, seth vidal wrote:

>
> hmm. I bet the drive labels are screwed up. For fun, stop the array,
> load up fdisk on one of the disks and type 'o' - that should make new
> dos disk labels.
>
> it's something I ran into, but this was a long time ago, so the above
> info might be out of date./
>
> so make new drive labels, repartition and recreate the array.

Well, wouldn't that destroy the data on the array? Oh well I'll redo the
array anyway. There wasn't that much data of value on the drive anyway.
I'll just loose a couple of days work.

Strange. I re-paritioned the drives, started the array with a raidstart
/dev/md0 (so it used the old raidtab) and the formatted the drive (ext3).
I mounted the filesystem and it looked ok. Then I umounted the filesystem
and stopped the array.
When I tried to start the array again I got the same problem as before.

So I changed to using persistent superblocks and did the same things. Now
it seems to work. Seems strange to me since I ran the array without
persistent superblocks since the beginning of July. Now it works and I
have once again learnt the lesson about frequent backups.


// peter
-- 
If God is real, s/he might be integer (e.g. 0). If God is complex, then s/he might be imaginary.