* [linux-lvm] LVM Bug, or Human Incompetence?
@ 2001-07-26 14:21 Mark Glines
2001-07-26 14:26 ` Pierre Lamb
2001-07-26 15:39 ` AJ Lewis
0 siblings, 2 replies; 4+ messages in thread
From: Mark Glines @ 2001-07-26 14:21 UTC (permalink / raw)
To: linux-lvm
Hi! I seem to have found a reproducable way to break LVM. I'm not sure if
its a bug or simply operator error, so I figured make up a transscript and
let you decide. The transscript isn't very exciting until the vgextend
part...
This is on my desktop machine, which I'm willing to temporarily break for
debugging purposes, if needed.
# cat /proc/lvm/global
LVM module version 0.9.1_beta2 (18/01/2001)
Total: 1 VG 1 PV 3 LVs (3 LVs open 3 times)
Global: 102973 bytes malloced IOP version: 10 0:04:17 active
VG: tweet [1 PV, 3 LV/3 open] PE Size: 4096 KB
Usage [KB/PE]: 39079936 /9541 total 25165824 /6144 used 13914112 /3397 free
PV: [AA] hdb 39079936 /9541 25165824 /6144 13914112 /3397
LVs: [AWDL ] music 20971520 /5120 1x open
[AWDL ] home 2097152 /512 1x open
[AWDL ] usr 2097152 /512 1x open
# mount
/dev/hda3 on / type reiserfs (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda1 on /boot type reiserfs (rw,notail)
/dev/tweet/usr on /usr type reiserfs (rw)
/dev/tweet/home on /home type reiserfs (rw)
/dev/tweet/music on /music type reiserfs (rw)
# df
Filesystem Size Used Avail Use% Mounted on
/dev/hda3 1.4G 259M 1.1G 19% /
/dev/hda1 47M 37M 10M 78% /boot
/dev/tweet/usr 2.0G 1.1G 949M 54% /usr
/dev/tweet/home 2.0G 875M 1.1G 43% /home
/dev/tweet/music 20G 17G 3.7G 82% /music
# dmesg | grep hda
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
hda: Maxtor 52049U4, ATA DISK drive
hda: 40020624 sectors (20491 MB) w/2048KiB Cache, CHS=2491/255/63, UDMA(33)
hda: hda1 hda2 hda3 hda4
# cfdisk
cfdisk 2.11g
Disk Drive: /dev/hda
Size: 20490559488 bytes
Heads: 255 Sectors per Track: 63 Cylinders: 2491
Name Flags Part Type FS Type [Label] Size (MB)
----------------------------------------------------------------------------------------------------------------------------------
hda1 Boot Primary Linux 49.36
hda4 Primary Linux swap 164.51
hda3 Primary Linux 1497.01
hda2 Primary Linux LVM 18778.32
...
# vgscan -v
vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- scanning for all active volume group(s) first
vgscan -- found active volume group "tweet"
vgscan -- reading data of volume group "tweet" from physical volume(s)
vgscan -- inserting "tweet" into lvmtab
vgscan -- backing up volume group "tweet"
vgscan -- checking volume group name "tweet"
vgscan -- checking volume group consistency of "tweet"
vgscan -- checking existence of "/etc/lvmtab.d"
vgscan -- making directory "/etc/lvmtab.d"
vgscan -- storing volume group data of "tweet" in "/etc/lvmtab.d/tweet.tmp"
vgscan -- storing physical volume data of "tweet" in "/etc/lvmtab.d/tweet.tmp"
vgscan -- storing logical volume data of volume group "tweet" in "/etc/lvmtab.d/tweet.tmp"
vgscan -- renaming "/etc/lvmtab.d/tweet.tmp" to "/etc/lvmtab.d/tweet"
vgscan -- removing special files and directory for volume group "tweet"
vgscan -- creating directory and group character special file for "tweet"
vgscan -- creating block device special files for tweet
vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d" successfully created
vgscan -- WARNING: you may not have an actual VGDA backup of your volume group
# pvscan -v
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- walking through all physical volumes found
pvscan -- ACTIVE PV "/dev/hdb" of VG "tweet" [37.27 GB / 13.27 GB free]
pvscan -- total: 1 [37.27 GB] / in use: 1 [37.27 GB] / in no VG: 0 [0]
# pvcreate -v /dev/hda2
pvcreate -- locking logical volume manager
pvcreate -- checking physical volume name "/dev/hda2"
pvcreate -- getting physical volume size
pvcreate -- checking partition type
pvcreate -- creating new physical volume
pvcreate -- setting up physical volume for /dev/hda2 with 36676395 sectors
pvcreate -- writing physical volume data to disk "/dev/hda2"
pvcreate -- physical volume "/dev/hda2" successfully created
pvcreate -- unlocking logical volume manager
# pvscan -v
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- walking through all physical volumes found
pvscan -- inactive PV "/dev/hda2" is in no VG [17.49 GB]
pvscan -- ACTIVE PV "/dev/hdb" of VG "tweet" [37.27 GB / 13.27 GB free]
pvscan -- total: 2 [54.76 GB] / in use: 1 [37.27 GB] / in no VG: 1 [17.49 GB]
# vgextend tweet /dev/hda2
vgextend -- INFO: maximum logical volume size is 255.99 Gigabyte
vgextend -- doing automatic backup of volume group "tweet"
vgextend -- volume group "tweet" successfully extended
# vgscan -v
vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- scanning for all active volume group(s) first
vgscan -- found active volume group "tweet"
vgscan -- reading data of volume group "tweet" from physical volume(s)
vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" can't get data of volume group "tweet" from physical volume(s)
vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated LE of LV" creating "/etc/lvmtab" and "/etc/lvmtab.d"
# pvscan -v
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- walking through all physical volumes found
pvscan -- ACTIVE PV "/dev/hda2" is associated to an unknown VG (run vgscan)
pvscan -- ACTIVE PV "/dev/hdb" is associated to an unknown VG (run vgscan)
pvscan -- total: 2 [54.76 GB] / in use: 2 [54.76 GB] / in no VG: 0 [0]
Note that the system is still useable at this point... the kernel LVM is fine,
but none of the userland tools can find their asses (this includes receiving
periodic lvmsadc crontab mouth-frothings about the kernel and /etc/lvmtab DB
mismatch). After a reboot, however, vgscan still can't find its ass and
everything fails, taking most of the machine's overall competence with it
(obvious due to lack of /usr). After a reboot, a sequence like the following
is necessary to bring it back:
cd /etc/lvmconf
mv tweet.conf.1.old tweet.conf
vgcfgrestore -v -n tweet /dev/hdb
vgscan
/etc/init.d/lvm restart
mount /usr
mount /home
mount /music
*start various services manually, reboot, or switch init runlvls*
I'm running stock linux 2.4.6 LVM built as a module, with the debian sid "lvm10"
package userland utilities (debian package version 0.9-1.2).
hda2 used to be a DOS "extended" partition, containing 3 logical drives. All 3
of these have been migrated successfully to LV's (the VG using hdb as sole PV).
That leaves me (after a bit of cfdisking) with one free partition taking up 80%
of hda. I'd love to use this partition as a PV and chuck it into the VG, but
it doesn't seem to work, as I've documented above.
Am I doing something wrong? How outdated is the LVM code in stock 2.4.6? If this
isn't my fault, is this likely to be a kernel bug or userland bug? Would a redo
of the transscript, using -d instead of (or in addition to) -v, be useful?
If there's any more info I can provide, please feel free to ask.
--
#!/usr/bin/perl
my($r)=shift; die "Usage: $0 perlregex [file(s)]\n"
if!defined($r);@ARGV="."if(!@ARGV);while($_=shift){
@F=`find $_ -type f`;chomp@F;for$f(@F){open(I,$f)or
next;while(<I>){print"$f:$.:$_" if/$r/;}close(I);}}
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] LVM Bug, or Human Incompetence?
2001-07-26 14:21 [linux-lvm] LVM Bug, or Human Incompetence? Mark Glines
@ 2001-07-26 14:26 ` Pierre Lamb
2001-07-26 15:20 ` Joe Thornber
2001-07-26 15:39 ` AJ Lewis
1 sibling, 1 reply; 4+ messages in thread
From: Pierre Lamb @ 2001-07-26 14:26 UTC (permalink / raw)
To: linux-lvm
Why are my linux-lvm@sistina.com e-mail getting sent
back to me as underliverable from somewhere in .br
Pierre
--- Mark Glines <paranoid-lvm@tweet.paranoid.dhs.org>
wrote:
>
> Hi! I seem to have found a reproducable way to
> break LVM. I'm not sure if
> its a bug or simply operator error, so I figured
> make up a transscript and
> let you decide. The transscript isn't very exciting
> until the vgextend
> part...
>
> This is on my desktop machine, which I'm willing to
> temporarily break for
> debugging purposes, if needed.
>
>
> # cat /proc/lvm/global
> LVM module version 0.9.1_beta2 (18/01/2001)
>
> Total: 1 VG 1 PV 3 LVs (3 LVs open 3 times)
>
> Global: 102973 bytes malloced IOP version: 10
> 0:04:17 active
>
> VG: tweet [1 PV, 3 LV/3 open] PE Size: 4096 KB
> Usage [KB/PE]: 39079936 /9541 total 25165824
> /6144 used 13914112 /3397 free
> PV: [AA] hdb 39079936 /9541
> 25165824 /6144 13914112 /3397
> LVs: [AWDL ] music 20971520
> /5120 1x open
> [AWDL ] home 2097152
> /512 1x open
> [AWDL ] usr 2097152
> /512 1x open
> # mount
> /dev/hda3 on / type reiserfs (rw)
> proc on /proc type proc (rw)
> devpts on /dev/pts type devpts (rw,gid=5,mode=620)
> /dev/hda1 on /boot type reiserfs (rw,notail)
> /dev/tweet/usr on /usr type reiserfs (rw)
> /dev/tweet/home on /home type reiserfs (rw)
> /dev/tweet/music on /music type reiserfs (rw)
> # df
> Filesystem Size Used Avail Use% Mounted
> on
> /dev/hda3 1.4G 259M 1.1G 19% /
> /dev/hda1 47M 37M 10M 78% /boot
> /dev/tweet/usr 2.0G 1.1G 949M 54% /usr
> /dev/tweet/home 2.0G 875M 1.1G 43% /home
> /dev/tweet/music 20G 17G 3.7G 82% /music
> # dmesg | grep hda
> ide0: BM-DMA at 0xd000-0xd007, BIOS settings:
> hda:DMA, hdb:pio
> hda: Maxtor 52049U4, ATA DISK drive
> hda: 40020624 sectors (20491 MB) w/2048KiB Cache,
> CHS=2491/255/63, UDMA(33)
> hda: hda1 hda2 hda3 hda4
> # cfdisk
>
> cfdisk 2.11g
>
>
> Disk Drive: /dev/hda
>
> Size: 20490559488 bytes
> Heads: 255
> Sectors per Track: 63 Cylinders: 2491
>
> Name Flags Part
> Type FS Type [Label]
> Size (MB)
>
>
----------------------------------------------------------------------------------------------------------------------------------
> hda1 Boot
> Primary Linux
> 49.36
> hda4
> Primary Linux swap
> 164.51
> hda3
> Primary Linux
> 1497.01
> hda2
> Primary Linux LVM
> 18778.32
> ...
> # vgscan -v
> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- reading all physical volumes (this may
> take a while...)
> vgscan -- scanning for all active volume group(s)
> first
> vgscan -- found active volume group "tweet"
> vgscan -- reading data of volume group "tweet" from
> physical volume(s)
> vgscan -- inserting "tweet" into lvmtab
> vgscan -- backing up volume group "tweet"
> vgscan -- checking volume group name "tweet"
> vgscan -- checking volume group consistency of
> "tweet"
> vgscan -- checking existence of "/etc/lvmtab.d"
> vgscan -- making directory "/etc/lvmtab.d"
> vgscan -- storing volume group data of "tweet" in
> "/etc/lvmtab.d/tweet.tmp"
> vgscan -- storing physical volume data of "tweet" in
> "/etc/lvmtab.d/tweet.tmp"
> vgscan -- storing logical volume data of volume
> group "tweet" in "/etc/lvmtab.d/tweet.tmp"
> vgscan -- renaming "/etc/lvmtab.d/tweet.tmp" to
> "/etc/lvmtab.d/tweet"
> vgscan -- removing special files and directory for
> volume group "tweet"
> vgscan -- creating directory and group character
> special file for "tweet"
> vgscan -- creating block device special files for
> tweet
> vgscan -- "/etc/lvmtab" and "/etc/lvmtab.d"
> successfully created
> vgscan -- WARNING: you may not have an actual VGDA
> backup of your volume group
>
> # pvscan -v
> pvscan -- reading all physical volumes (this may
> take a while...)
> pvscan -- walking through all physical volumes found
> pvscan -- ACTIVE PV "/dev/hdb" of VG "tweet"
> [37.27 GB / 13.27 GB free]
> pvscan -- total: 1 [37.27 GB] / in use: 1 [37.27 GB]
> / in no VG: 0 [0]
>
> # pvcreate -v /dev/hda2
> pvcreate -- locking logical volume manager
> pvcreate -- checking physical volume name
> "/dev/hda2"
> pvcreate -- getting physical volume size
> pvcreate -- checking partition type
> pvcreate -- creating new physical volume
> pvcreate -- setting up physical volume for /dev/hda2
> with 36676395 sectors
> pvcreate -- writing physical volume data to disk
> "/dev/hda2"
> pvcreate -- physical volume "/dev/hda2" successfully
> created
> pvcreate -- unlocking logical volume manager
>
> # pvscan -v
> pvscan -- reading all physical volumes (this may
> take a while...)
> pvscan -- walking through all physical volumes found
> pvscan -- inactive PV "/dev/hda2" is in no VG
> [17.49 GB]
> pvscan -- ACTIVE PV "/dev/hdb" of VG "tweet"
> [37.27 GB / 13.27 GB free]
> pvscan -- total: 2 [54.76 GB] / in use: 1 [37.27 GB]
> / in no VG: 1 [17.49 GB]
>
> # vgextend tweet /dev/hda2
> vgextend -- INFO: maximum logical volume size is
> 255.99 Gigabyte
> vgextend -- doing automatic backup of volume group
> "tweet"
> vgextend -- volume group "tweet" successfully
> extended
>
> # vgscan -v
> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- reading all physical volumes (this may
> take a while...)
> vgscan -- scanning for all active volume group(s)
> first
> vgscan -- found active volume group "tweet"
> vgscan -- reading data of volume group "tweet" from
> physical volume(s)
> vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated
> LE of LV" can't get data of volume group "tweet"
> from physical volume(s)
> vgscan -- ERROR "vg_read_with_pv_and_lv(): allocated
> LE of LV" creating "/etc/lvmtab" and "/etc/lvmtab.d"
>
> # pvscan -v
> pvscan -- reading all physical volumes (this may
> take a while...)
> pvscan -- walking through all physical volumes found
> pvscan -- ACTIVE PV "/dev/hda2" is associated to
> an unknown VG (run vgscan)
> pvscan -- ACTIVE PV "/dev/hdb" is associated to
> an unknown VG (run vgscan)
> pvscan -- total: 2 [54.76 GB] / in use: 2 [54.76 GB]
> / in no VG: 0 [0]
>
>
>
>
>
>
>
> Note that the system is still useable at this
> point... the kernel LVM is fine,
> but none of the userland tools can find their asses
> (this includes receiving
> periodic lvmsadc crontab mouth-frothings about the
> kernel and /etc/lvmtab DB
> mismatch). After a reboot, however, vgscan still
> can't find its ass and
> everything fails, taking most of the machine's
> overall competence with it
> (obvious due to lack of /usr). After a reboot, a
> sequence like the following
> is necessary to bring it back:
>
> cd /etc/lvmconf
> mv tweet.conf.1.old tweet.conf
> vgcfgrestore -v -n tweet /dev/hdb
> vgscan
> /etc/init.d/lvm restart
> mount /usr
> mount /home
> mount /music
> *start various services manually, reboot, or switch
> init runlvls*
>
>
>
> I'm running stock linux 2.4.6 LVM built as a module,
> with the debian sid "lvm10"
> package userland utilities (debian package version
> 0.9-1.2).
>
> hda2 used to be a DOS "extended" partition,
> containing 3 logical drives. All 3
> of these have been migrated successfully to LV's
> (the VG using hdb as sole PV).
> That leaves me (after a bit of cfdisking) with one
> free partition taking up 80%
> of hda. I'd love to use this partition as a PV and
> chuck it into the VG, but
> it doesn't seem to work, as I've documented above.
>
> Am I doing something wrong? How outdated is the LVM
> code in stock 2.4.6? If this
> isn't my fault, is this likely to be a kernel bug or
> userland bug? Would a redo
> of the transscript, using -d instead of (or in
> addition to) -v, be useful?
>
> If there's any more info I can provide, please feel
> free to ask.
>
> --
> #!/usr/bin/perl
> my($r)=shift; die "Usage: $0 perlregex [file(s)]\n"
> if!defined($r);@ARGV="."if(!@ARGV);while($_=shift){
> @F=`find $_ -type f`;chomp@F;for$f(@F){open(I,$f)or
> next;while(<I>){print"$f:$.:$_" if/$r/;}close(I);}}
> _______________________________________________
> 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
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] LVM Bug, or Human Incompetence?
2001-07-26 14:26 ` Pierre Lamb
@ 2001-07-26 15:20 ` Joe Thornber
0 siblings, 0 replies; 4+ messages in thread
From: Joe Thornber @ 2001-07-26 15:20 UTC (permalink / raw)
To: linux-lvm
On Thu, Jul 26, 2001 at 07:26:10AM -0700, Pierre Lamb wrote:
> Why are my linux-lvm@sistina.com e-mail getting sent
> back to me as underliverable from somewhere in .br
I've been getting those too ... will remove offender from list.
- Joe
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [linux-lvm] LVM Bug, or Human Incompetence?
2001-07-26 14:21 [linux-lvm] LVM Bug, or Human Incompetence? Mark Glines
2001-07-26 14:26 ` Pierre Lamb
@ 2001-07-26 15:39 ` AJ Lewis
1 sibling, 0 replies; 4+ messages in thread
From: AJ Lewis @ 2001-07-26 15:39 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 3121 bytes --]
On Thu, Jul 26, 2001 at 07:21:15AM -0700, Mark Glines wrote:
> Note that the system is still useable at this point... the kernel LVM is fine,
> but none of the userland tools can find their asses (this includes receiving
> periodic lvmsadc crontab mouth-frothings about the kernel and /etc/lvmtab DB
> mismatch). After a reboot, however, vgscan still can't find its ass and
> everything fails, taking most of the machine's overall competence with it
> (obvious due to lack of /usr). After a reboot, a sequence like the following
> is necessary to bring it back:
>
> cd /etc/lvmconf
> mv tweet.conf.1.old tweet.conf
> vgcfgrestore -v -n tweet /dev/hdb
> vgscan
> /etc/init.d/lvm restart
> mount /usr
> mount /home
> mount /music
> *start various services manually, reboot, or switch init runlvls*
odd...
> I'm running stock linux 2.4.6 LVM built as a module, with the debian sid "lvm10"
> package userland utilities (debian package version 0.9-1.2).
I think you might want to try using the LVM 0.9.1 Beta2 tools. That is the
toolset that most closely matches the kernel LVM module. That being said, it is
strongly recommended that you upgrade to the 0.9.1 Beta8 LVM, and patch your
kernel. If you have an existing LVM setup, you will need to do some metadata
migration (this is outlined in the README.1st on the FTP site where you can get
LVM 0.9.1 Beta8 (ftp://ftp.sistina.com/pub/LVM/0.9.1_beta)
> hda2 used to be a DOS "extended" partition, containing 3 logical drives. All 3
> of these have been migrated successfully to LV's (the VG using hdb as sole PV).
> That leaves me (after a bit of cfdisking) with one free partition taking up 80%
> of hda. I'd love to use this partition as a PV and chuck it into the VG, but
> it doesn't seem to work, as I've documented above.
>
> Am I doing something wrong? How outdated is the LVM code in stock 2.4.6? If this
> isn't my fault, is this likely to be a kernel bug or userland bug? Would a redo
> of the transscript, using -d instead of (or in addition to) -v, be useful?
The kernel LVM code is about 5-6 months out of date. I am pretty sure that your
toolset is not very well matched for the kernel code. As I said earlier, it is
strongly recommended that you download LVM 0.9.1 Beta8, and follow the procedure
in README.1st to upgrade to that version of LVM.
Hopefully the changes will be incorporated in the vanilla kernel soon...
--
AJ Lewis
Sistina Software Inc. Voice: 612-638-0500
1313 5th St SE, Suite 111 Fax: 612-638-0500
Minneapolis, MN 55414 E-Mail: lewis@sistina.com
http://www.sistina.com
Current GPG fingerprint = 3B5F 6011 5216 76A5 2F6B 52A0 941E 1261 0029 2648
Get my key at: http://www.sistina.com/~lewis/gpgkey
(Unfortunately, the PKS-type keyservers do not work with multiple sub-keys)
-----Begin Obligatory Humorous Quote----------------------------------------
Choose a job you love, and you will never have to work a day in your life.
-----End Obligatory Humorous Quote------------------------------------------
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2001-07-26 15:39 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-07-26 14:21 [linux-lvm] LVM Bug, or Human Incompetence? Mark Glines
2001-07-26 14:26 ` Pierre Lamb
2001-07-26 15:20 ` Joe Thornber
2001-07-26 15:39 ` AJ Lewis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.