[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[linux-lvm] [Fwd: Re: SUSE 9.1 with ReiserFS: / won't fsck, but is otherwise fine]

I had thought this was a Reiser issue, but am now convinced it's not.

In summary, any attempt by any non-lvm app to read an LVM volume (which
is mounted as the root partition) is told the device does not exist. 
LVM apps seemingly work fine, but I don't want to add disks to this
volume until I know what's going on or have fixed the problem.

I've attached the background info...
--- Begin Message ---
On Mon, 2004-09-27 at 16:16, evilninja wrote:
> ah, now this is funny. dd doesn't care about the filesystem and can't even
> read the device. 
> this does not seem like a (reiser-)fs issue, more like a
> corrupted partition table / device

I agree that it's not a reiser issue... but, how did it get mounted in
the first place?

>  (if the data on
> /dev/mapper/system-lvol0 is not (!) important, you could play around with

I find the root partition an invaluable part of the system.  So, I'm not
going to destroy it on purpose.  I'm not quite sure how to boot without
a root partition ;)

I'm really looking for a non-destructive way to test/repair whatever has
happened.  The partitioning seems fine (an ext3 boot directory of a few
MB, an 8GB swap, and the root partition):

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1           5       40131   83  Linux
/dev/hda2               6         979     7823655   82  Linux swap
/dev/hda3             980       30515   237247920   8e  Linux LVM


--- End Message ---
--- Begin Message ---
I have a similar problem to:

On 2004-07-15 13:06:46 Vitaly Fertman Wrote:
> Hello,
> >...
> >
> > Boot --> please use fsck manualy on /
> what version of reiserfsck are you using? please update 
> reiserfsprogs to the latest one from our ftp site. 

I'm using 3.6.13... which version do you propose?

> ...

I'm getting the same error where the ReiserFS root partition won't fsck,
but seems otherwise fine:

I "fixed" it by replacing /sbin/mkfs.reiserfs with a script that always
returns true... now the system boots fine ;)

It's a Reiser fs atop an LVM block device of one partition.  The problem
started when I switched from lilo to grub... that could be irrelevant.

Once booted, Reiser still doesn't even recognize the root file system (I
saved the executable in fsck.reiserfs.bak):

        # /sbin/fsck.reiserfs.bak /dev/system/lvol0
        reiserfsck 3.6.13 (2003 www.namesys.com)
        ** If you are using the latest reiserfsprogs and  it fails **
        ** please  email bug reports to reiserfs-list namesys com, **
        ** providing  as  much  information  as  possible --  your **
        ** hardware,  kernel,  patches,  settings,  all reiserfsck **
        ** messages  (including version),  the reiserfsck logfile, **
        ** check  the  syslog file  for  any  related information. **
        ** If you would like advice on using this program, support **
        ** is available  for $25 at  www.namesys.com/support.html. **
        Will read-only check consistency of the filesystem on /dev/system/lvol0
        Will put log info to 'stdout'
        Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
        Failed to open the device '/dev/system/lvol0': No such device or address
Note: I'm running a fully patched 9.1.  I've been able to use this
fsck.reiserfs to examine other LVM based file systems that were created
under previous LVM and ReiserFS versions.  The volume is currently only
made up of /dev/hda3.  Both the lvm block device and reiser format were
created under SuSE9.1 (before patching).  LVM has no problems: 

         # pvscan
          PV /dev/hda3   VG system   lvm2 [226.25 GB / 0    free]
          PV /dev/hdd1               lvm2 [233.76 GB]
          Total: 2 [460.01 GB] / in use: 1 [226.25 GB] / in no VG: 1 [233.76 GB]
         # vgdisplay
          --- Volume group ---
          VG Name               system
          System ID
          Format                lvm2
          Metadata Areas        1
          Metadata Sequence No  2
          VG Access             read/write
          VG Status             resizable
          MAX LV                255
          Cur LV                1
          Open LV               1
          Max PV                255
          Cur PV                1
          Act PV                1
          VG Size               226.25 GB
          PE Size               4.00 MB
          Total PE              57921
          Alloc PE / Size       57921 / 226.25 GB
          Free  PE / Size       0 / 0
          VG UUID               glCBN4-xLPB-eGJO-4YVO-p4Hj-ZRMW-LFvJfJ
        # lvdisplay
          --- Logical volume ---
          LV Name                /dev/system/lvol0
          VG Name                system
          LV UUID                j9z3cd-hY3R-4unM-UwZs-BXVZ-WMJN-iMIvXF
          LV Write Access        read/write
          LV Status              available
          # open                 2
          LV Size                226.25 GB
          Current LE             57921
          Segments               1
          Allocation             next free (default)
          Read ahead sectors     0
          Block device           254:0
        # pvdisplay
          --- Physical volume ---
          PV Name               /dev/hda3
          VG Name               system
          PV Size               226.25 GB / not usable 0
          Allocatable           yes (but full)
          PE Size (KByte)       4096
          Total PE              57921
          Free PE               0
          Allocated PE          57921
          PV UUID               wQnbCq-FQT9-76gh-HjFP-kBi3-7lE8-psDnAj
          --- NEW Physical volume ---
          PV Name               /dev/hdd1
          VG Name
          PV Size               233.76 GB
          Allocatable           NO
          PE Size (KByte)       0
          Total PE              0
          Free PE               0
          Allocated PE          0
          PV UUID               lZ0dSs-FR6O-i7fo-z5xZ-APMR-CcBq-Fmm425
        # df
        Filesystem           1K-blocks      Used Available Use% Mounted on
                             237237168 141678036  95559132  60% /
        tmpfs                   517676         0    517676   0% /dev/shm
        /dev/hda1                38856     18321     18529  50% /boot

Other than fsck, there's no other hint that something is wrong with this

If this partition were at the beginning of the disk (and not 8GB into
the disk) I'd think grub had destroyed something beyond the MBR... but
this is too far into the disk.

Any idea what's wrong with this root partition and what I could do to
recover it?



--- End Message ---

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]