[linux-lvm] LVM help re:

[linux-lvm] LVM help re:

[Uday Bhaskar Sarma Seetamraju]

Hi,

pvscan tells me which PV belongs to which VG.
But I am wondering if the information as to
"which PVwas added to the VG in which order"
can also be determined.
In case of a disaster, the first added PV would most likely contain
all the information that's has been around longer (and so more
important!)

Sarma

P.S: An 'ls' will not tell you in which order files/subfolders were
    created, but du or tar does.

P.S: Getting used to LVM reminds me of the days of early
        minivax/ultrix days (my first unix impressions), where each
        'rm' and 'mv' and 'cp' command was "entered" after 10
        deep breaths and 2 minutes of deep thought about what
        "that" command WILL do (when "entered" ofcourse!!).
        Not a criticism of LVM, just that the flexibility and new-ness
        of this concept lets one kill oneself so easily.
        Can't speak for the world, but I can't handle this
        kind of flexibilty and power.

Re: [linux-lvm] LVM help re:

[Luca Berra]

On Tue, Sep 25, 2001 at 11:33:17PM -0400, Uday Bhaskar Sarma Seetamraju wrote:
> Hi,
> 
> pvscan tells me which PV belongs to which VG.
> But I am wondering if the information as to
> "which PVwas added to the VG in which order"
> can also be determined.
not sure if vgdisplay -v will
> In case of a disaster, the first added PV would most likely contain
> all the information that's has been around longer (and so more
> important!)
you can do lvdisplay -v of a LV and have the position of each LE on
which PV.

L.

-- 
Luca Berra -- bluca@comedia.it
        Communication Media & Services S.r.l.
 /"\
 \ /     ASCII RIBBON CAMPAIGN
  X        AGAINST HTML MAIL
 / \

Re: [linux-lvm] LVM help re:

[Wolfgang Weisselberg]

Hi, Uday!

Uday Bhaskar Sarma Seetamraju (sarma@bellatlantic.net) wrote 33 lines:

> P.S: An 'ls' will not tell you in which order files/subfolders were
>     created, but du or tar does.

There is ls -U or ls -f.

Even though it will only list 'unsortedd / in directory
order' like du or tar.

-Wolfgang

[linux-lvm] 1.0.1-rc2 lvcreate segfaults, pvcreate, vgcreate ok

[Jim Cromie]

I recently pulled 2.4.10, built, installed, and tested ok on a Redhat 7.1
machine.

then I activated LVM module config, applied 1.0.1-rc2 LVM patches,
rebuilt,
manually corrected 3-ary max(), min() s to 2 arg version, as per

http://lists.sistina.com/pipermail/lvm-devel/2001-September/000657.html


reboot works, insmod lvm-mod installs module as expected,
pvcreate, vgcreate both worked..

lvcreate segfaults however, apparently after nearly completing the LV
setup.

# gdb /sbin/lvcreate
(gdb) r -d -L1000 -nVL_test VG_test
....
<55555> pv_check_new -- CALLED
<55555> pv_check_new -- LEAVING with ret: 0
<4444> pv_check_consistency -- LEAVING with ret: 0
<333> lv_check_on_pv -- LEAVING with ret: 1
<22> pv_reserve_pe -- LEAVING with ret: 0
<1> lv_setup_for_create -- pv_reserve_pe returned: 0   pe_last: 250  pe:
0
<1> lv_setup_for_create -- pe: 0
<1> lv_setup_for_create -- LEAVING with ret: 0
<1> lvm_dont_interrupt -- CALLED
<1> lvm_dont_interrupt -- LEAVING

Program received signal SIGSEGV, Segmentation fault.
lv_create (vg=0x5, lv=0xbffff9f4,
    lv_name=0xbffffa0c
":ûÿ¿Rûÿ¿nûÿ¿\203ûÿ¿\233ûÿ¿½ûÿ¿Üûÿ¿èûÿ¿òûÿ¿µýÿ¿Ôýÿ¿îýÿ¿\003þÿ¿\032þÿ¿%þÿ¿0þÿ¿=þÿ¿Eþÿ¿Uþÿ¿cþÿ¿qþÿ¿\202þÿ¿\220þÿ¿²þÿ¿Ëþÿ¿Öþÿ¿áþÿ¿\024ÿÿ¿")
at lv_create_remove.c:42
42 int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
(gdb) bt
#0  lv_create (vg=0x5, lv=0xbffff9f4,
    lv_name=0xbffffa0c
":ûÿ¿Rûÿ¿nûÿ¿\203ûÿ¿\233ûÿ¿½ûÿ¿Üûÿ¿èûÿ¿òûÿ¿µýÿ¿Ôýÿ¿îýÿ¿\003þÿ¿\032þÿ¿%þÿ¿0þÿ¿=þÿ¿Eþÿ¿Uþÿ¿cþÿ¿qþÿ¿\202þÿ¿\220þÿ¿²þÿ¿Ëþÿ¿Öþÿ¿áþÿ¿\024ÿÿ¿")
at lv_create_remove.c:42
#1  0x0804b03d in strcpy () at ../sysdeps/generic/strcpy.c:31
#2  0x40079177 in __libc_start_main (main=0x8049390 <strcpy+384>, argc=5,
ubp_av=0xbffff9f4, init=0x8048e88 <_init>,
    fini=0x804b4d0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>,
stack_end=0xbffff9ec) at ../sysdeps/generic/libc-start.c:129
(gdb)
(gdb) list
37
38 /* internal function */
39 int lv_create_remove ( vg_t *, lv_t *, char *, int);
40
41
42 int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
43    return lv_create_remove ( vg, lv, lv_name, LV_CREATE);
44 }
45
46
(gdb)

(gdb) up
#1  0x0804b03d in strcpy () at ../sysdeps/generic/strcpy.c:31
31 ../sysdeps/generic/strcpy.c: No such file or directory.
 in ../sysdeps/generic/strcpy.c


Apriori, it looks like lv_name is uninitialized.  But it runs pretty far
before choking.

looking deeper;

(gdb) b lv_create
(gdb) b strcpy
(gdb) r
....
<4444> lv_check_consistency_all_lv -- vg->lv[245]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[246]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[247]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[248]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[249]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[250]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[251]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[252]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[253]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- vg->lv[254]: 0  name: (null)
<4444> lv_check_consistency_all_lv -- LEAVING with ret: 0
<333> vg_check_consistency_with_pv_and_lv -- LEAVING with ret: 0
<22> vg_cfgrestore -- LEAVING with ret: 0
<1> lvm_tab_vg_check_exist -- before vg.pv_cur check with vg.pv_cur: 1
pv_count: 1
<22> vg_free -- CALLED
<22> vg_free -- entering PV loop
<22> vg_free -- entering LV loop
<22> vg_free -- LEAVING with ret: 0
<1> lvm_tab_vg_check_exist -- LEAVING with ret: 1
<1> vg_check_active -- CALLED with VG: VG_test
<22> vg_check_name -- CALLED with VG: VG_test
<333> lvm_check_chars -- CALLED with name: "VG_test"
<333> lvm_check_chars -- LEAVING with ret: 0
<22> vg_check_name -- LEAVING with ret: 0
<22> vg_status -- CALLED with VG: VG_test
<333> vg_check_name -- CALLED with VG: VG_test
<4444> lvm_check_chars -- CALLED with name: "VG_test"
<4444> lvm_check_chars -- LEAVING with ret: 0
<333> vg_check_name -- LEAVING with ret: 0
<22> vg_status -- LEAVING with ret: 0
<1> vg_check_active -- LEAVING with ret: 1
<1> lv_check_name -- CALLED with lv_name: "/dev/VG_test/VL_test"
<22> lvm_check_chars -- CALLED with name: "/dev/VG_test/VL_test"
<22> lvm_check_chars -- LEAVING with ret: 0

Breakpoint 1, strcpy (dest=0xbfffecc0
"dm\001@õÚÑ\013\2137\001@0íÿ¿\020l\001@Ñ\210\004\bìq\001@ÿÿÿÿ",
    src=0xbffff650 "/dev/VG_test/VL_test") at
../sysdeps/generic/strcpy.c:34
34 ../sysdeps/generic/strcpy.c: No such file or directory.
 in ../sysdeps/generic/strcpy.c
(gdb)
(gdb) frame
#0  strcpy (dest=0xbfffecc0
"dm\001@õÚÑ\013\2137\001@0íÿ¿\020l\001@Ñ\210\004\bìq\001@ÿÿÿÿ",
src=0xbffff650 "/dev/VG_test/VL_test")
    at ../sysdeps/generic/strcpy.c:34
34 in ../sysdeps/generic/strcpy.c
(gdb)

so - string is initialized, at least to start


I cant get any more insight at this time, HTH

Re: [linux-lvm] 1.0.1-rc2 lvcreate segfaults, pvcreate, vgcreate ok

[John Marquart]

I think you are running into a problem i had.   look in the archives for
mails from/to jomarqua@indiana.edu - but i think the problem is your
inline functions that lvcreate uses.

There is a patch that was recommended to me - should fix your problem i
think - it is at:

http://incandescent.mp3revolution.net/lvm/inline_fix.diff

-j


On Wed, 26 Sep 2001, Jim Cromie wrote:

>
> I recently pulled 2.4.10, built, installed, and tested ok on a Redhat 7.1
> machine.
>
> then I activated LVM module config, applied 1.0.1-rc2 LVM patches,
> rebuilt,
> manually corrected 3-ary max(), min() s to 2 arg version, as per
>
> http://lists.sistina.com/pipermail/lvm-devel/2001-September/000657.html
>
>
> reboot works, insmod lvm-mod installs module as expected,
> pvcreate, vgcreate both worked..
>
> lvcreate segfaults however, apparently after nearly completing the LV
> setup.
>
> # gdb /sbin/lvcreate
> (gdb) r -d -L1000 -nVL_test VG_test
> ....
> <55555> pv_check_new -- CALLED
> <55555> pv_check_new -- LEAVING with ret: 0
> <4444> pv_check_consistency -- LEAVING with ret: 0
> <333> lv_check_on_pv -- LEAVING with ret: 1
> <22> pv_reserve_pe -- LEAVING with ret: 0
> <1> lv_setup_for_create -- pv_reserve_pe returned: 0   pe_last: 250  pe:
> 0
> <1> lv_setup_for_create -- pe: 0
> <1> lv_setup_for_create -- LEAVING with ret: 0
> <1> lvm_dont_interrupt -- CALLED
> <1> lvm_dont_interrupt -- LEAVING
>
> Program received signal SIGSEGV, Segmentation fault.
> lv_create (vg=0x5, lv=0xbffff9f4,
>     lv_name=0xbffffa0c
> ":ûÿ¿Rûÿ¿nûÿ¿\203ûÿ¿\233ûÿ¿½ûÿ¿Üûÿ¿èûÿ¿òûÿ¿µýÿ¿Ôýÿ¿îýÿ¿\003þÿ¿\032þÿ¿%þÿ¿0þÿ¿=þÿ¿Eþÿ¿Uþÿ¿cþÿ¿qþÿ¿\202þÿ¿\220þÿ¿²þÿ¿Ëþÿ¿Öþÿ¿áþÿ¿\024ÿÿ¿")
> at lv_create_remove.c:42
> 42 int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
> (gdb) bt
> #0  lv_create (vg=0x5, lv=0xbffff9f4,
>     lv_name=0xbffffa0c
> ":ûÿ¿Rûÿ¿nûÿ¿\203ûÿ¿\233ûÿ¿½ûÿ¿Üûÿ¿èûÿ¿òûÿ¿µýÿ¿Ôýÿ¿îýÿ¿\003þÿ¿\032þÿ¿%þÿ¿0þÿ¿=þÿ¿Eþÿ¿Uþÿ¿cþÿ¿qþÿ¿\202þÿ¿\220þÿ¿²þÿ¿Ëþÿ¿Öþÿ¿áþÿ¿\024ÿÿ¿")
> at lv_create_remove.c:42
> #1  0x0804b03d in strcpy () at ../sysdeps/generic/strcpy.c:31
> #2  0x40079177 in __libc_start_main (main=0x8049390 <strcpy+384>, argc=5,
> ubp_av=0xbffff9f4, init=0x8048e88 <_init>,
>     fini=0x804b4d0 <_fini>, rtld_fini=0x4000e184 <_dl_fini>,
> stack_end=0xbffff9ec) at ../sysdeps/generic/libc-start.c:129
> (gdb)
> (gdb) list
> 37
> 38 /* internal function */
> 39 int lv_create_remove ( vg_t *, lv_t *, char *, int);
> 40
> 41
> 42 int lv_create ( vg_t *vg, lv_t *lv, char *lv_name) {
> 43    return lv_create_remove ( vg, lv, lv_name, LV_CREATE);
> 44 }
> 45
> 46
> (gdb)
>
> (gdb) up
> #1  0x0804b03d in strcpy () at ../sysdeps/generic/strcpy.c:31
> 31 ../sysdeps/generic/strcpy.c: No such file or directory.
>  in ../sysdeps/generic/strcpy.c
>
>
> Apriori, it looks like lv_name is uninitialized.  But it runs pretty far
> before choking.
>
> looking deeper;
>
> (gdb) b lv_create
> (gdb) b strcpy
> (gdb) r
> ....
> <4444> lv_check_consistency_all_lv -- vg->lv[245]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[246]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[247]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[248]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[249]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[250]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[251]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[252]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[253]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- vg->lv[254]: 0  name: (null)
> <4444> lv_check_consistency_all_lv -- LEAVING with ret: 0
> <333> vg_check_consistency_with_pv_and_lv -- LEAVING with ret: 0
> <22> vg_cfgrestore -- LEAVING with ret: 0
> <1> lvm_tab_vg_check_exist -- before vg.pv_cur check with vg.pv_cur: 1
> pv_count: 1
> <22> vg_free -- CALLED
> <22> vg_free -- entering PV loop
> <22> vg_free -- entering LV loop
> <22> vg_free -- LEAVING with ret: 0
> <1> lvm_tab_vg_check_exist -- LEAVING with ret: 1
> <1> vg_check_active -- CALLED with VG: VG_test
> <22> vg_check_name -- CALLED with VG: VG_test
> <333> lvm_check_chars -- CALLED with name: "VG_test"
> <333> lvm_check_chars -- LEAVING with ret: 0
> <22> vg_check_name -- LEAVING with ret: 0
> <22> vg_status -- CALLED with VG: VG_test
> <333> vg_check_name -- CALLED with VG: VG_test
> <4444> lvm_check_chars -- CALLED with name: "VG_test"
> <4444> lvm_check_chars -- LEAVING with ret: 0
> <333> vg_check_name -- LEAVING with ret: 0
> <22> vg_status -- LEAVING with ret: 0
> <1> vg_check_active -- LEAVING with ret: 1
> <1> lv_check_name -- CALLED with lv_name: "/dev/VG_test/VL_test"
> <22> lvm_check_chars -- CALLED with name: "/dev/VG_test/VL_test"
> <22> lvm_check_chars -- LEAVING with ret: 0
>
> Breakpoint 1, strcpy (dest=0xbfffecc0
> "dm\001@õÚÑ\013\2137\001@0íÿ¿\020l\001@Ñ\210\004\bìq\001@ÿÿÿÿ",
>     src=0xbffff650 "/dev/VG_test/VL_test") at
> ../sysdeps/generic/strcpy.c:34
> 34 ../sysdeps/generic/strcpy.c: No such file or directory.
>  in ../sysdeps/generic/strcpy.c
> (gdb)
> (gdb) frame
> #0  strcpy (dest=0xbfffecc0
> "dm\001@õÚÑ\013\2137\001@0íÿ¿\020l\001@Ñ\210\004\bìq\001@ÿÿÿÿ",
> src=0xbffff650 "/dev/VG_test/VL_test")
>     at ../sysdeps/generic/strcpy.c:34
> 34 in ../sysdeps/generic/strcpy.c
> (gdb)
>
> so - string is initialized, at least to start
>
>
> I cant get any more insight at this time, HTH
>
>
>
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>

Re: [linux-lvm] 1.0.1-rc2 lvcreate segfaults, pvcreate, vgcreate ok

[Jim Cromie]

John Marquart wrote:

> I think you are running into a problem i had.   look in the archives for
> mails from/to jomarqua@indiana.edu - but i think the problem is your
> inline functions that lvcreate uses.
>
> There is a patch that was recommended to me - should fix your problem i
> think - it is at:
>
> http://incandescent.mp3revolution.net/lvm/inline_fix.diff
>
> -j

yup, that did it.

after flailing with patch rejects against unknown sources,
backed up and re-did  tar xvfz

then the patch applied w/o rejects,
compiled w/o errors,

and lvcreate worked !


[root@groucho 1.0.1-rc2]# lvcreate -L1500 -nVL_test VG_test
lvcreate -- doing automatic backup of "VG_test"
lvcreate -- logical volume "/dev/VG_test/VL_test" successfully created

[root@groucho 1.0.1-rc2]# lvscan
lvscan -- ACTIVE            "/dev/VG_test/VL_test" [1.46 GB]
lvscan -- 1 logical volumes with 1.46 GB total in 1 volume group
lvscan -- 1 active logical volumes

[root@groucho 1.0.1-rc2]# lvdisplay /dev/VG_test/VL_test
--- Logical volume ---
LV Name                /dev/VG_test/VL_test
VG Name                VG_test
LV Write Access        read/write
LV Status              available
LV #                   1
# open                 0
LV Size                1.46 GB
Current LE             375
Allocated LE           375
Allocation             next free
Read ahead sectors     120
Block device           58:0

[linux-lvm] vgscan 1.0.1-rc2 + kernel 2.4.10

[Andre Margis]

I'm using lvm 1.0.1-rc2 under kernel 2.4.9 and work fine.

When using with kernel 2.4.10 vgscan hang, running vgscan -d, the log is 
listed above:

<1> lvm_get_iop_version -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING
<1> lvm_get_iop_version -- AFTER ioctl ret: 0
<1> lvm_get_iop_version -- LEAVING with ret: 10
<1> lvm_lock -- CALLED
<22> lvm_check_special -- CALLED
<22> lvm_check_special -- LEAVING


I have two servers Dell 8450 and they have the same problem.


and no more messages



Thank's in advance



Andre

Re: [linux-lvm] vgscan 1.0.1-rc2 + kernel 2.4.10

[svetljo]

have you tried the cvs lvm-1.0.1rc2
i have it working without PBs with 2.4.10-xfs cvs kernel

Andre Margis wrote:

>I'm using lvm 1.0.1-rc2 under kernel 2.4.9 and work fine.
>
>When using with kernel 2.4.10 vgscan hang, running vgscan -d, the log is 
>listed above:
>
><1> lvm_get_iop_version -- CALLED
><22> lvm_check_special -- CALLED
><22> lvm_check_special -- LEAVING
><1> lvm_get_iop_version -- AFTER ioctl ret: 0
><1> lvm_get_iop_version -- LEAVING with ret: 10
><1> lvm_lock -- CALLED
><22> lvm_check_special -- CALLED
><22> lvm_check_special -- LEAVING
>
>
>I have two servers Dell 8450 and they have the same problem.
>
>
>and no more messages
>
>
>
>Thank's in advance
>
>
>
>Andre
>
>_______________________________________________
>linux-lvm mailing list
>linux-lvm@sistina.com
>http://lists.sistina.com/mailman/listinfo/linux-lvm
>read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>

Re: [linux-lvm] vgscan 1.0.1-rc2 + kernel 2.4.10

[Andre Margis]

I found the error, my /proc/partitions have thousands and thousands of lines!


maybe a kernel bug!


Thank's


Andre



> have you tried the cvs lvm-1.0.1rc2
> i have it working without PBs with 2.4.10-xfs cvs kernel
>
> Andre Margis wrote:
> >I'm using lvm 1.0.1-rc2 under kernel 2.4.9 and work fine.
> >
> >When using with kernel 2.4.10 vgscan hang, running vgscan -d, the log is
> >listed above:
> >
> ><1> lvm_get_iop_version -- CALLED
> ><22> lvm_check_special -- CALLED
> ><22> lvm_check_special -- LEAVING
> ><1> lvm_get_iop_version -- AFTER ioctl ret: 0
> ><1> lvm_get_iop_version -- LEAVING with ret: 10
> ><1> lvm_lock -- CALLED
> ><22> lvm_check_special -- CALLED
> ><22> lvm_check_special -- LEAVING
> >
> >
> >I have two servers Dell 8450 and they have the same problem.
> >
> >
> >and no more messages
> >
> >
> >
> >Thank's in advance
> >
> >
> >
> >Andre
> >
> >_______________________________________________
> >linux-lvm mailing list
> >linux-lvm@sistina.com
> >http://lists.sistina.com/mailman/listinfo/linux-lvm
> >read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
>
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html

Re: [linux-lvm] vgscan 1.0.1-rc2 + kernel 2.4.10

[Andreas Dilger]

On Sep 27, 2001  12:05 -0300, Andre Margis wrote:
> I found the error, my /proc/partitions have thousands and thousands of lines!
> 
> maybe a kernel bug!

Yes, it is.  It has something to do with SCSI and modules.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: [linux-lvm] vgscan 1.0.1-rc2 + kernel 2.4.10

[Sean Burford]

Andre Margis wrote:
> I found the error, my /proc/partitions have thousands and thousands of lines!
> maybe a kernel bug!

I ran into this as well.  It happened with the Alan Cox 14 patch to
Linux kernel 2.4.9 when I installed a fiber channel driver (which added
partitions).  I patched up drivers/block/genhd.c to detect and break
circular links in the partition link list, and also to refuse to add
entries that where already in the list (which was successful, though not
recommended).  Next I used a plain kernel without the AC patch, and
again the problem went away.

Are you using an otherwise unpatched kernel?

> > have you tried the cvs lvm-1.0.1rc2
> > i have it working without PBs with 2.4.10-xfs cvs kernel
> >
> > Andre Margis wrote:
> > >I'm using lvm 1.0.1-rc2 under kernel 2.4.9 and work fine.
> > >
> > >When using with kernel 2.4.10 vgscan hang, running vgscan -d, the log is
> > >listed above:
> > >
> > ><1> lvm_get_iop_version -- CALLED
> > ><22> lvm_check_special -- CALLED
> > ><22> lvm_check_special -- LEAVING
> > ><1> lvm_get_iop_version -- AFTER ioctl ret: 0
> > ><1> lvm_get_iop_version -- LEAVING with ret: 10
> > ><1> lvm_lock -- CALLED
> > ><22> lvm_check_special -- CALLED
> > ><22> lvm_check_special -- LEAVING
> > >
> > >I have two servers Dell 8450 and they have the same problem.

-- 
Sean Burford    x34135
ITS Systems Specialist
Adelaide University