[linux-lvm] Problem

[linux-lvm] Problem

[nellis]

[-- Attachment #1: Type: text/plain, Size: 822 bytes --]

Hi there ,

I'm not sure what going on here . I want to setup my backup server using 
LVM . I have two physical HDD named hda1 ( Linux native ) = 9.5GB , hda2 ( 
Linux swap ) = 500MB and hdd1( LVM == 8e ) . I have error that looks like 
this :

root@backupmy:/LVM# ./configure
loading cache ./config.cache
checking for mawk... mawk
checking for gcc... gcc
checking whether the C compiler (gcc  ) works... no
configure: error: installation or configuration problem: C compiler cannot 
create executables.

Before that , I can't insmod lvm-mod . I read your docu for a whole day 
and give it a try but still no avail . PLEASE HELP . 

Regards , 

Nurulhadi Ellis
Union Switch & Signal (M) Sdn Bhd
1903 - 1912 , 19th Floor , Plaza Pengkalan , Jalan Ipoh
51100 Kuala Lumpur
MALAYSIA
Ph  : +6 03 4045 8055
Fax : +6 03 4045 8970

[-- Attachment #2: Type: text/html, Size: 1300 bytes --]

Re: [linux-lvm] Problem

[Guido Guenther]

On Thu, Dec 26, 2002 at 03:33:46PM +0800, nellis@unionswitch.com.my wrote:
> I'm not sure what going on here . I want to setup my backup server using 
> LVM . I have two physical HDD named hda1 ( Linux native ) = 9.5GB , hda2 ( 
> Linux swap ) = 500MB and hdd1( LVM == 8e ) . I have error that looks like 
> this :
> 
> root@backupmy:/LVM# ./configure
> loading cache ./config.cache
> checking for mawk... mawk
> checking for gcc... gcc
> checking whether the C compiler (gcc  ) works... no
> configure: error: installation or configuration problem: C compiler cannot 
> create executables.
Something with you C compiler is wrong, see config.log for details.
Can't you use the precompiled lvm that comes with your distribution?
 -- Guido

[linux-lvm] problem

[Daniel Wittenberg]

I had 2 drives in my machine, with a VG across both of them.  The only
thing on the second drive was part of /tmp, so when the second drive
died I didn't really lose anything.  But I have problems now because I
can't activate the VG because part of it is missing, but I can't remove
tmp, so it's a catch-22.  Is there anyway to remove an LV without
activating the VG?  Or another way I can tell it to ignore missing LV's?

Thanks!
Dan

-- 
===========================
Daniel Wittenberg
Senior Unix Admin
University of Iowa - ITS

Re: [linux-lvm] problem

[Steven Lembark]

-- Daniel Wittenberg <daniel-wittenberg@uiowa.edu>

> I had 2 drives in my machine, with a VG across both of them.  The only
> thing on the second drive was part of /tmp, so when the second drive
> died I didn't really lose anything.  But I have problems now because I
> can't activate the VG because part of it is missing, but I can't remove
> tmp, so it's a catch-22.  Is there anyway to remove an LV without
> activating the VG?  Or another way I can tell it to ignore missing LV's?

vgexport + vgimport should do it for you if none of the
other LV's stretched onto the dead drive.

If you don't want to spread data across drives that are
not maintained with some sort of RAID then you are
probably better off putting the drives in separate VG's
so that data doesn't accidentally spill across the disks.


--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                            +1 773 252 1080

Re: [linux-lvm] problem

[Daniel Wittenberg]

Ugh...

# vgexport -av
vgexport -- locking logical volume manager
vgexport -- checking volume group name
vgexport -- checking volume group activity
vgexport -- reading data of volume group "rootvg" from disk(s)
vgexport -- only found 0 of 39 LEs for LV /dev/rootvg/tmp (0)
vgexport -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" reading
data of volume group "rootvg"

vgexport -- unlocking logical volume manager

Other ideas?

Thanks,
Dan

On Wed, 2003-01-08 at 14:21, Steven Lembark wrote:
> -- Daniel Wittenberg <daniel-wittenberg@uiowa.edu>
> 
> > I had 2 drives in my machine, with a VG across both of them.  The only
> > thing on the second drive was part of /tmp, so when the second drive
> > died I didn't really lose anything.  But I have problems now because I
> > can't activate the VG because part of it is missing, but I can't remove
> > tmp, so it's a catch-22.  Is there anyway to remove an LV without
> > activating the VG?  Or another way I can tell it to ignore missing LV's?
> 
> vgexport + vgimport should do it for you if none of the
> other LV's stretched onto the dead drive.
> 
> If you don't want to spread data across drives that are
> not maintained with some sort of RAID then you are
> probably better off putting the drives in separate VG's
> so that data doesn't accidentally spill across the disks.
> 
> 
> --
> Steven Lembark                               2930 W. Palmer
> Workhorse Computing                       Chicago, IL 60647
>                                             +1 773 252 1080
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
-- 
===========================
Daniel Wittenberg
Senior Unix Admin
University of Iowa - ITS

Re: [linux-lvm] problem

[Alasdair G Kergon]

On Wed, Jan 08, 2003 at 02:33:11PM -0600, Daniel Wittenberg wrote:
> Other ideas?

Install the LVM2 utilities and perform the task with them?

"vgreduce --removemissing rootvg" will do exactly what you 
want - but I haven't released it yet because I haven't finished 
testing it with snapshots present etc.

For now, you run LVM2's vgcfgbackup (with -P), edit the 
text file by hand to remove the PV and LV (easy to do), then 
run vgcfgrestore to put the fixed metadata in the text file
back onto disk.

Then if you don't want to upgrade to LVM2 yet, you can
simply revert to using the LVM1 tools again, starting
by running LVM1's vgscan.


In circumstances like this, you don't need to change your
kernel in order to use the LVM2 tools. You can just set 
"activation = 0" in the lvm.conf file and then they'll 
only manipulate on-disk metadata and they won't try to
talk to device-mapper (the new kernel driver that LVM2 uses).

Alasdair

Re: [linux-lvm] problem

[Daniel Wittenberg]

I didn't see any pre-built binaries, so I started down the source path,
and looks like it needs device-mapper, ok, I started working on that,
and it looks like it wants the LVM2 patches to the kernel source...does
this sound right?  Since I only want the LVM2 tools just for this fix,
does sistina build any RPM's or binaries?  I'm just short on time right
now and going to be a pain if I have start doing kernel patches and
everything else too...

Dan

On Wed, 2003-01-08 at 15:45, Alasdair G Kergon wrote:
> On Wed, Jan 08, 2003 at 02:33:11PM -0600, Daniel Wittenberg wrote:
> > Other ideas?
> 
> Install the LVM2 utilities and perform the task with them?
> 
> "vgreduce --removemissing rootvg" will do exactly what you 
> want - but I haven't released it yet because I haven't finished 
> testing it with snapshots present etc.
> 
> For now, you run LVM2's vgcfgbackup (with -P), edit the 
> text file by hand to remove the PV and LV (easy to do), then 
> run vgcfgrestore to put the fixed metadata in the text file
> back onto disk.
> 
> Then if you don't want to upgrade to LVM2 yet, you can
> simply revert to using the LVM1 tools again, starting
> by running LVM1's vgscan.
> 
> 
> In circumstances like this, you don't need to change your
> kernel in order to use the LVM2 tools. You can just set 
> "activation = 0" in the lvm.conf file and then they'll 
> only manipulate on-disk metadata and they won't try to
> talk to device-mapper (the new kernel driver that LVM2 uses).
> 
> Alasdair
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
-- 
===========================
Daniel Wittenberg
Senior Unix Admin
University of Iowa - ITS

Re: [linux-lvm] problem

[Alasdair G Kergon]

On Wed, Jan 08, 2003 at 04:24:47PM -0600, Daniel Wittenberg wrote:
> I didn't see any pre-built binaries, so I started down the source path,
If you don't have any kernel source lying around, yes, you'll have
to fiddle to compile device-mapper.  [It needs .h file from the
kernel patch.]

I'll do you a version of LVM2 that can be compiled without 
device-mapper.

Alasdair
-- 
agk@uk.sistina.com

Re: [linux-lvm] problem

[Daniel Wittenberg]

If all it needs is the dm-ioctl.h I can grab that.  This was just
turning into a "needs this one more file...one more file" sorta thing,
so didn't want to spend all night chasing files.

Thanks,
Dan

On Wed, 2003-01-08 at 16:30, Alasdair G Kergon wrote:
> On Wed, Jan 08, 2003 at 04:24:47PM -0600, Daniel Wittenberg wrote:
> > I didn't see any pre-built binaries, so I started down the source path,
> If you don't have any kernel source lying around, yes, you'll have
> to fiddle to compile device-mapper.  [It needs .h file from the
> kernel patch.]
> 
> I'll do you a version of LVM2 that can be compiled without 
> device-mapper.
> 
> Alasdair
-- 
===========================
Daniel Wittenberg
Senior Unix Admin
University of Iowa - ITS

Re: [linux-lvm] problem

[Alasdair G Kergon]

  ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.1.95.14.tgz

* Allows for 'configure --disable-devmapper' if you don't have
  device-mapper but just want to manipulate on-disk metadata
* Additional debug messages for devices
* Fix some 64-bit warnings
* Avoid duplicate device aliases

Alasdair

Re: [linux-lvm] problem

[Alasdair G Kergon]

Procedure to follow:
  
   vgcfgbackup -P -f /tmp/vgbackup rootvg

   Edit the backup file as follows:
   Add "WRITE" to the status line and remove "PARTIAL"

e.g.
   status = ["RESIZEABLE", "PARTIAL", "READ"]
becomes
   status = ["RESIZEABLE", "READ", "WRITE"]


Remove the whole PV section for your "unknown device"
- referenced as "pv1" in this example.

                pv1 {
                        id = "TBCgjx-ne5X-4fHP-aHqe-dKJR-Vwnb-kjDhWQ"
                        device = "unknown device"       # Hint only

                        status = ["ALLOCATABLE"]
                        pe_start = 128
                        pe_count = 5    # 20 Megabytes
                }


Remove the whole LV section for any LVs that refer to the pv you
removed above (pv1 here referenced inside "stripes") e.g.

                tmp {
                        id = "4eTLYv-PTDr-FXvv-58Xk-Q4Th-p8yi-GeKCHr"
                        status = ["READ", "WRITE", "VISIBLE"]
                        segment_count = 1

                        segment1 {
                                start_extent = 0
                                extent_count = 3        # 12 Megabytes

                                type = "striped"
                                stripe_count = 1        # linear

                                stripes = [
                                        "pv1", 0
                                ]
                        }
                }

Write the metadata back to disk:
  vgcfgrestore -f /tmp/vgbackup rootvg

Alasdair
-- 
agk@uk.sistina.com

Re: [linux-lvm] problem

[Alasdair G Kergon]

On Wed, Jan 08, 2003 at 11:10:14PM +0000, Alasdair Kergon wrote:
> Write the metadata back to disk:
>   vgcfgrestore -f /tmp/vgbackup rootvg

Add -M1 there to make sure it uses LVM1 format metadata!
   vgcfgrestore -M1 -f /tmp/vgbackup rootvg

Alasdair
-- 
agk@uk.sistina.com

Re: [linux-lvm] problem

[Daniel Wittenberg]

Now this is interesting.  I noticed that when I dumped the config, and
look at it, one of the (largest) pv's isn't showing up at all.  I also
don't see a way to for vgcfgbackup to pull from a specific physical
device, so not sure how I can 'force' it to see the other lvm
partition.  This is what I have now, but partition /dev/hdb1 is not
showing up.  These are 2 partitions I used to move extents from failing
to disk before it completely died.  I'm guessing this is why it doesn't
see the rest of the VG, very little right now isn't listed as "missing"
even those /dev/hdb1 is there, but vgscan doesn't seem to see it.
                
		pv0 {
                        id = "YnfiRa-QnzV-Llio-quX6-UrHQ-WuCl-RiwZWd"
                        device = "/dev/hda7"    # Hint only

                        status = ["ALLOCATABLE"]
                        pe_start = 8576
                        pe_count = 373  # 1.45703 Gigabytes
                }

                pv1 {
                        id = "qFNI3x-yIgQ-Lqco-PDNN-djJ4-UiWw-szmJiW"
                        device = "/dev/hda8"    # Hint only

                        status = ["ALLOCATABLE"]
                        pe_start = 8576
                        pe_count = 444  # 1.73438 Gigabytes
                }

Thanks again for all the help...definitely won't be using this across
disks not on RAID anymore...

Dan

On Wed, 2003-01-08 at 17:10, Alasdair G Kergon wrote:
> Procedure to follow:
>   
>    vgcfgbackup -P -f /tmp/vgbackup rootvg
> 
>    Edit the backup file as follows:
>    Add "WRITE" to the status line and remove "PARTIAL"
> 
> e.g.
>    status = ["RESIZEABLE", "PARTIAL", "READ"]
> becomes
>    status = ["RESIZEABLE", "READ", "WRITE"]
> 
> 
> Remove the whole PV section for your "unknown device"
> - referenced as "pv1" in this example.
> 
>                 pv1 {
>                         id = "TBCgjx-ne5X-4fHP-aHqe-dKJR-Vwnb-kjDhWQ"
>                         device = "unknown device"       # Hint only
> 
>                         status = ["ALLOCATABLE"]
>                         pe_start = 128
>                         pe_count = 5    # 20 Megabytes
>                 }
> 
> 
> Remove the whole LV section for any LVs that refer to the pv you
> removed above (pv1 here referenced inside "stripes") e.g.
> 
>                 tmp {
>                         id = "4eTLYv-PTDr-FXvv-58Xk-Q4Th-p8yi-GeKCHr"
>                         status = ["READ", "WRITE", "VISIBLE"]
>                         segment_count = 1
> 
>                         segment1 {
>                                 start_extent = 0
>                                 extent_count = 3        # 12 Megabytes
> 
>                                 type = "striped"
>                                 stripe_count = 1        # linear
> 
>                                 stripes = [
>                                         "pv1", 0
>                                 ]
>                         }
>                 }
> 
> Write the metadata back to disk:
>   vgcfgrestore -f /tmp/vgbackup rootvg
> 
> Alasdair
-- 
===========================
Daniel Wittenberg
Senior Unix Admin
University of Iowa - ITS