Minor LVM bollixment

Bob McClure Jr bob at bobcatos.com
Thu Jul 27 20:43:48 UTC 2006


On Thu, Jul 27, 2006 at 01:01:43PM -0700, Rick Stevens wrote:
> On Thu, 2006-07-27 at 12:40 -0500, Bob McClure Jr wrote:
> > Last night, my wife rebooted our web server with the reset button
> > (don't ask).  It booted ok and appears to be running fine, but now I
> > get this result from "fdisk -l"
> > 
> > Disk /dev/hda: 80.0 GB, 80060424192 bytes
> > 255 heads, 63 sectors/track, 9733 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> > 
> >    Device Boot      Start         End      Blocks   Id  System
> > /dev/hda1   *           1          13      104391   83  Linux
> > /dev/hda2              14          26      104422+  83  Linux
> > /dev/hda3              27          39      104422+  83  Linux
> > /dev/hda4              40        9733    77867055   8e  Linux LVM
> > 
> > Disk /dev/dm-0: 8388 MB, 8388608000 bytes
> > 255 heads, 63 sectors/track, 1019 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> > 
> > Disk /dev/dm-0 doesn't contain a valid partition table
> > 
> > Disk /dev/dm-1: 8388 MB, 8388608000 bytes
> > 255 heads, 63 sectors/track, 1019 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> > 
> > Disk /dev/dm-1 doesn't contain a valid partition table
> > 
> >   .
> >   .
> >   .
> >   .
> > 
> > Disk /dev/dm-10: 8589 MB, 8589934592 bytes
> > 255 heads, 63 sectors/track, 1044 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> > 
> > Disk /dev/dm-10 doesn't contain a valid partition table
> > 
> > Disk /dev/dm-11: 10.7 GB, 10737418240 bytes
> > 255 heads, 63 sectors/track, 1305 cylinders
> > Units = cylinders of 16065 * 512 = 8225280 bytes
> > 
> > Disk /dev/dm-11 doesn't contain a valid partition table
> > 
> > The /dev/dm-nn correspond to the 12 logical volumes in that VG.
> 
> Did you "vgchange -ay" to see if they got turned off?

I have now.

> Did you verify that /etc/lvm.conf was OK?

Yep.

> > I checked dmesg and found this:
> > 
> > EXT3-fs: dm-0: orphan cleanup on readonly fs
> > ext3_orphan_cleanup: deleting unreferenced inode 1094899
> > ext3_orphan_cleanup: deleting unreferenced inode 227777
> > ext3_orphan_cleanup: deleting unreferenced inode 1078122
> > ext3_orphan_cleanup: deleting unreferenced inode 1466022
> > ext3_orphan_cleanup: deleting unreferenced inode 617737
> > ext3_orphan_cleanup: deleting unreferenced inode 617736
> > ext3_orphan_cleanup: deleting unreferenced inode 617735
> > ext3_orphan_cleanup: deleting unreferenced inode 617733
> > ext3_orphan_cleanup: deleting unreferenced inode 1239631
> > EXT3-fs: dm-0: 9 orphan inodes deleted
> > EXT3-fs: recovery complete.
> > EXT3-fs: mounted filesystem with ordered data mode.
> > 
> > There's nothing in /lost+found.  Several LVM tools I tried, including
> > vgck report nothing amiss.
> 
> Did you try "lvm -P dumpconfig",

The "-P" option was not liked, but "lvm dumpconfig" produced:

devices {
        dir="/dev"
        scan="/dev"
        filter="a/.*/"
        cache="/etc/lvm/.cache"
        write_cache_state=1
        sysfs_scan=1
        md_component_detection=1
}
activation {
        missing_stripe_filler="/dev/ioerror"
        reserved_stack=256
        reserved_memory=8192
        process_priority=-18
        mirror_region_size=512
        mirror_log_fault_policy="allocate"
        mirror_device_fault_policy="remove"
}
global {
        umask=63
        test=0
        activation=1
        proc="/proc"
        locking_type=1
        locking_dir="/var/lock/lvm"
}
shell {
        history_size=100
}
backup {
        backup=1
        backup_dir="/etc/lvm/backup"
        archive=1
        archive_dir="/etc/lvm/archive"
        retain_min=10
        retain_days=30
}
log {
        verbose=0
        syslog=1
        overwrite=0
        level=0
        indent=1
        command_names=0
        prefix="  "
}

> "pvscan",

  PV /dev/hda4   VG bubbavg   lvm2 [74.25 GB / 23.75 GB free]
  Total: 1 [74.25 GB] / in use: 1 [74.25 GB] / in no VG: 0 [0   ]

> "lvscan",

  ACTIVE            '/dev/bubbavg/root2' [7.81 GB] inherit
  ACTIVE            '/dev/bubbavg/root1' [7.81 GB] inherit
  ACTIVE            '/dev/bubbavg/hdlist' [5.84 GB] inherit
  ACTIVE            '/dev/bubbavg/home' [992.00 MB] inherit
  ACTIVE            '/dev/bubbavg/usrlocal' [192.00 MB] inherit
  ACTIVE            '/dev/bubbavg/varlog' [480.00 MB] inherit
  ACTIVE            '/dev/bubbavg/varspool' [480.00 MB] inherit
  ACTIVE            '/dev/bubbavg/varwww' [6.00 GB] inherit
  ACTIVE            '/dev/bubbavg/swap' [1.94 GB] inherit
  ACTIVE            '/dev/bubbavg/u' [1.00 GB] inherit
  ACTIVE            '/dev/bubbavg/restore' [8.00 GB] inherit
  ACTIVE            '/dev/bubbavg/backup' [10.00 GB] inherit

> "lvchange -ay"

... produced no output, and the results of "fdisk -l" are still as
above.

> and the like?  I'd do the dumpconfig, then the pvscan and lvscan.
> They may find something odd.  Assuming that comes up OK, then the
> "lvchange -ay" should make them available.
> 
> > 
> > The system is FC4, updated nightly with yum.  A Google search didn't
> > turn up anything useful.
> > 
> > As I noted, it's running fine apparently.  How do I fix this short of
> > setting up a new drive and copying everything over?
> 
> Try the above.

LVM seems to be functioning just fine.  It's just the output of "fdisk
-l" that bothers me.  It definitely was not that way before last night.

> ----------------------------------------------------------------------
> - Rick Stevens, Senior Systems Engineer     rstevens at vitalstream.com -
> - VitalStream, Inc.                       http://www.vitalstream.com -
> -                                                                    -
> -  Perseverance:  When you're too damned stubborn to say "I quit!"   -
> ----------------------------------------------------------------------

Cheers,
-- 
Bob McClure, Jr.             Bobcat Open Systems, Inc.
bob at bobcatos.com             http://www.bobcatos.com
Blessed is the nation whose God is the LORD. - Psalm 33:12
Righteousness exalts a nation. - Proverbs 14:34




More information about the Redhat-install-list mailing list