Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jun 1999 16:21:45 -0700
From:      Greg Lehey <grog@folly.lemis.com>
To:        Kiril Mitev <kiril@ideaglobal.com>, Cy.Schubert@uumail.gov.bc.ca
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: vinum disk has gone AWOL, help!
Message-ID:  <19990610162145.22313@folly.lemis.com>
In-Reply-To: <199906042058.VAA19464@ideaglobal.com>; from Kiril Mitev on Fri, Jun 04, 1999 at 09:58:07PM %2B0100
References:  <199906042014.NAA49261@passer.osg.gov.bc.ca> <199906042058.VAA19464@ideaglobal.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday,  4 June 1999 at 21:58:07 +0100, Kiril Mitev wrote:
>> In message <199906041920.UAA17798@ideaglobal.com>, Kiril Mitevv writes:
>>> (Sorry if this is more appropriate for -questions...)
>>>
>>>
>>> after my last reboot, which was NOT a panic or anything like that
>>> my vinum volume sort of disappeared...
>>>
>>> vinum itself is still happy, and a listing shows all my
>>> bits & pieces, up to the volume level as OK.
>>>
>>> however, mount/fsck attempts come up with
>>> errors like this:
>>>
>>> # fsck /dev/vinum/rmassive
>>> ** /dev/vinum/rmassive
>>> BAD SUPER BLOCK: MAGIC NUMBER WRONG
>>> /dev/vinum/rmassive: NOT LABELED AS A BSD FILE SYSTEM (unused)
>>>
>>> _I_ havent touched anything, so it seems like something really
>>> bad has happened.
>>>
>>> Can anyone suggest a way/hack to recover the damn disk? Its
>>> a desperete situation :-(), so even desperate suggestion
>>> will be appreciated. (i.e., is it possible to hack a 'label'
>>> or an 'id' or something back into the disk.
>>>
>>> when a dd from the raw device, i do see something that looks
>>> like the root directory of the disk, so its not
>>> as if everything was lost
>>
>> Try fsck -b 32 <filesystem>.
>>
>> If that fails, try fsck -b <another number> <filesystem>.  To get
>> the other block numbers for alternate superblocks, use newfs -N,
>> which will go through all of the motions of creating a filesystem,
>> e.g. print the superblock numbers, without actually creating a
>> filesystem.  If this fails, you're pretty much hosed.
>
> That looks like it might actually fix it, unless there
> more corruption somewhere

This sounds funny.  If you have any evidence that it was caused by
Vinum, I'd be very interested to see it.  But I suspect that the cause
is elsewhere, and Vinum has little to do with it.

Greg
--
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990610162145.22313>