Encrypted filesystem fscking -- 'fsck -c 2' using fsck from before release 5.0?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Encrypted filesystem fscking -- 'fsck -c 2' using fsck from before release 5.0?

Damon Getsman
I have an OpenBSD Virtual Machine (v.5.4) that, unfortunately, got shut
down improperly the other day.  This machine had a mounted partition
/dev/rwd0j, which disklabel is reporting as a fstype of 4.2BSD (fsize 2048,
bsize 16384, cgp 1).  The partition is completely full with an encrypted
filesystem image, which was mounted at the time of the evil shutdown.  When
I try to mount the (host [/dev/rwd0j]) partition, I receive an error
telling me that the filesystem is not clean and I need to run fsck.  When I
manually run fsck, I am receiving an error that the 'version of filesystem
is too old', and that I must update it to a more recent format with 'fsck
-c 2', using a version of fsck that is from before release 5.0.

Unfortunately, I have vital services on this virtual machine that I need to
get running again as soon as possible for users other than myself.  I have
not been able to locate any archive with a binary version of fsck for i386
from a release of OpenBSD prior to 5.0, nor am I able to find any way
around this, at least during the first few dozen times ramming my head into
the brick wall here.  I would very much appreciate any ideas that anybody
might have in order to get this filesystem clean and running again asap.

Thank you muchly in advance!

Reply | Threaded
Open this post in threaded view
|

Re: Encrypted filesystem fscking -- 'fsck -c 2' using fsck from before release 5.0?

Otto Moerbeek
On Sun, Feb 09, 2014 at 11:14:08PM -0600, Damon Getsman wrote:

> I have an OpenBSD Virtual Machine (v.5.4) that, unfortunately, got shut
> down improperly the other day.  This machine had a mounted partition
> /dev/rwd0j, which disklabel is reporting as a fstype of 4.2BSD (fsize 2048,
> bsize 16384, cgp 1).  The partition is completely full with an encrypted
> filesystem image, which was mounted at the time of the evil shutdown.  When
> I try to mount the (host [/dev/rwd0j]) partition, I receive an error
> telling me that the filesystem is not clean and I need to run fsck.  When I
> manually run fsck, I am receiving an error that the 'version of filesystem
> is too old', and that I must update it to a more recent format with 'fsck
> -c 2', using a version of fsck that is from before release 5.0.
>
> Unfortunately, I have vital services on this virtual machine that I need to
> get running again as soon as possible for users other than myself.  I have
> not been able to locate any archive with a binary version of fsck for i386
> from a release of OpenBSD prior to 5.0, nor am I able to find any way
> around this, at least during the first few dozen times ramming my head into
> the brick wall here.  I would very much appreciate any ideas that anybody
> might have in order to get this filesystem clean and running again asap.
>
> Thank you muchly in advance!

Likely you superblock is corrupted, giving a spurious error message
concerning the fs version.

Try using an alternate superblock, using the -b option (see man page).

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: Encrypted filesystem fscking -- 'fsck -c 2' using fsck from before release 5.0?

Damon Getsman
Thank you for the quick reply, Otto.  I overlooked that option, which is
kind of funny, I know it's saved my butt before.  Anyway, I tried using
alternate superblocks, several of them (picked at random from various spots
within the ones named by newfs -N), and fsck is still dying with the same
error message.

I have been able to mount the filesystem read-only.  I'm not sure what else
to do at this point.  I feel like I'm overlooking something really obvious
and foolish, but I can't quite put my finger on it.  Anybody have any other
ideas?


On Mon, Feb 10, 2014 at 7:38 AM, Otto Moerbeek <[hidden email]> wrote:

>
>  > I have an OpenBSD Virtual Machine (v.5.4) that, unfortunately, got shut
> > down improperly the other day.  This machine had a mounted partition
> > /dev/rwd0j, which disklabel is reporting as a fstype of 4.2BSD (fsize
> 2048,
> > bsize 16384, cgp 1).  The partition is completely full with an encrypted
> > filesystem image, which was mounted at the time of the evil shutdown.
>  When
> > I try to mount the (host [/dev/rwd0j]) partition, I receive an error
> > telling me that the filesystem is not clean and I need to run fsck.
>  When I
> > manually run fsck, I am receiving an error that the 'version of
> filesystem
> > is too old', and that I must update it to a more recent format with 'fsck
> > -c 2', using a version of fsck that is from before release 5.0.
>


>  > Unfortunately, I have vital services on this virtual machine that I
> need to
> > get running again as soon as possible for users other than myself.  I
> have
> > not been able to locate any archive with a binary version of fsck for
> i386
> > from a release of OpenBSD prior to 5.0, nor am I able to find any way
> > around this, at least during the first few dozen times ramming my head
> into
> > the brick wall here.  I would very much appreciate any ideas that anybody
> > might have in order to get this filesystem clean and running again asap.
>


>  Likely you superblock is corrupted, giving a spurious error message
> concerning the fs version.
>
> Try using an alternate superblock, using the -b option (see man page).

Reply | Threaded
Open this post in threaded view
|

Re: Encrypted filesystem fscking -- 'fsck -c 2' using fsck from before release 5.0?

Philip Guenther-2
On Mon, Feb 10, 2014 at 2:38 PM, Damon Getsman <[hidden email]> wrote:
> I have been able to mount the filesystem read-only.  I'm not sure what else
> to do at this point.  I feel like I'm overlooking something really obvious
> and foolish, but I can't quite put my finger on it.  Anybody have any other
> ideas?

You have a filesystem that has been significantly corrupted by a crash
in a way that 'should not be possible' but you've managed to mount it
read-only and can access the data?

Personally, at that point, I would not completely trust any procedure
that claimed to recover from that except newfs and restoring the data.
 It's a PITA, but something you can actually have confidence in.


Philip Guenther