8:47 a.m.
I just installed a FC2 Test 1 system and applied all of the days
patches. When the machine boots, it sits at teh "Setting up Logical
Volume Management" phase for a very long time (about 5 minutes). After
this delay, the message "setlocale failed" is printed and boot continues
normally. The filesystems all appear to work correctly.
Is anyone else seeing odd LVM behaviour?
--
Ben Steeves _ bcs(a)metacon.ca
The ASCII ribbon campaign ( ) ben.steeves(a)unb.ca
against HTML e-mail X GPG ID: 0xB3EBF1D9
http://www.metacon.ca/ascii / \ Yahoo Messenger: ben_steeves
11:23 a.m.
On Feb 13, 2004, Ben Steeves <bcs(a)metacon.ca> wrote:
I just installed a FC2 Test 1 system and applied all of the days
patches. When the machine boots, it sits at teh "Setting up Logical
Volume Management" phase for a very long time (about 5 minutes). After
this delay, the message "setlocale failed" is printed and boot continues
normally. The filesystems all appear to work correctly.
Is anyone else seeing odd LVM behaviour?
lvm vgscan scans pretty much every block device it can get its hands
on. You may filter out stuff that doesn't matter for you using a
filter directive in /etc/lvm/lvm.conf. Here's what I use for a
machine whose physical volumes are *all* raid devices:
devices {
filter = [ "a|/dev/md.*|", "r|.*|" ]
}
this is for another box in which the `r'(emoved) devices are RAID
members:
devices {
filter = [ "r|/dev/hd[acegimos][5689]|",
"r|/dev/hd[acegimos]1[012]|", "a|.*|" ]
}
skipping raid members is a big problem that I wish lvm could take care
of by itself, otherwise anaconda will have to do it by itself. If you
don't skip raid members, lvm vgscan will simply bail out after finding
some ``duplicate'' physical volumes, that turn out to be just the RAID
1 members and the RAID device itself. Ugh!
Anyhow, limiting the scanning to only the devices that matter for you
(with "a|regexp|", skipping everything else) will help speed up the
boot very significantly.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva(a){lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer
3:27 p.m.
On Fri, 2004-02-13 at 12:23, Alexandre Oliva wrote:
[snip]
> Is anyone else seeing odd LVM behaviour?
lvm vgscan scans pretty much every block device it can get its hands
on. You may filter out stuff that doesn't matter for you using a
filter directive in /etc/lvm/lvm.conf. Here's what I use for a
machine whose physical volumes are *all* raid devices:
devices {
filter = [ "a|/dev/md.*|", "r|.*|" ]
}
Forgive my bluntness, but this seems to be a bit of a hack to me. Why
has lvm2 taken this step backwards from lvm1? There's gotta be a better
way. Or at least a faster way.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
9:19 p.m.
On Feb 13, 2004, Paul Iadonisi <pri.rhl1(a)iadonisi.to> wrote:
> devices {
> filter = [ "a|/dev/md.*|", "r|.*|" ]
> }
Forgive my bluntness, but this seems to be a bit of a hack to me.
Why
has lvm2 taken this step backwards from lvm1?
Ask Sistina! Erhm... Heck, I guess this is Red Hat now :-)
There's gotta be a better way.
IMHO it should scan /proc/mdstat or something equivalent to exclude
raid members. Other than that, I think scanning as many devices as it
can is actually an improvement, even though it will often result in
ugly error messages when it attempts to scan say the CD drive and
there isn't anything there :-)
Or at least a faster way.
Well... Either you scan all devices that could possibly name
physical volumes, or you risk missing some. What do you suggest?
Maybe a config file that enables you to limit the set of devices it
scans? Well... Seems to have already been done :-)
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva(a){lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer
11:07 a.m.
Hi,
On Sat, 2004-02-14 at 03:19, Alexandre Oliva wrote:
> Forgive my bluntness, but this seems to be a bit of a hack to
me. Why
> has lvm2 taken this step backwards from lvm1?
Ask Sistina! Erhm... Heck, I guess this is Red Hat now :-)
> There's gotta be a better way.
IMHO it should scan /proc/mdstat
It does (actually, it scans /sys/block.) It just didn't in test1. :)
I talked with the lvm2 guys when I set up my own initial LVM-on-root
FC2-test1 box and encountered the same behaviour. So they came up
with...
Date: 2004/02/13 14:46:03
Author: agk
Log:
Sysfs block device filtering option for 2.6.
...a patch to use 2.6's /sys/block pseudo-filesystem to filter which
block devices are worth probing for physical volumes. This should
improve things no end.
That patch is in CVS on sources.redhat.com/lvm2 now, and I'll push it
into rawhide. There will probably be a numbered lvm2 release with this
patch some time next week.
Cheers,
Stephen
1:59 p.m.
On Feb 19, 2004, "Stephen C. Tweedie" <sct(a)redhat.com> wrote:
...a patch to use 2.6's /sys/block pseudo-filesystem to filter
which
block devices are worth probing for physical volumes. This should
improve things no end.
Was this it?
* Thu Feb 19 2004 Stephen C. Tweedie <sct(a)redhat.com> 2.00.08-4
- Add sysfs filter patch
- Allow non-root users to build RPM
Didn't fix the raid 1 problem for me. Unless I manually exclude raid
member devices in /etc/lvm/lvm.conf, I get:
Reading all physical volumes. This may take a while...
Found duplicate PV o4Icc0yt8OloT89tnJ5xq156XCwYEczT: using /dev/sda3 not /dev/hda2
This failure mode is particularly bad when your root fs is in such an
LVM device, and you just rebuilt all of your initrd images with the
new, ``fixed´´ lvm binary and without lvm.conf. But even if I run it
after booting from a working-lvm.conf initrd, if I run vgscan on the
running system without lvm.conf, it fails just the same (and it
scarily fails to complete)
Want me to bugzilla this?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva(a){lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer
5:59 p.m.
Hi,
On Tue, 2004-03-02 at 19:59, Alexandre Oliva wrote:
On Feb 19, 2004, "Stephen C. Tweedie"
<sct(a)redhat.com> wrote:
> ...a patch to use 2.6's /sys/block pseudo-filesystem to filter which
> block devices are worth probing for physical volumes. This should
> improve things no end.
Was this it?
* Thu Feb 19 2004 Stephen C. Tweedie <sct(a)redhat.com> 2.00.08-4
- Add sysfs filter patch
- Allow non-root users to build RPM
Yep. Took me a bit longer to do the testing than I'd planned, as I've
found a quagmire of unrelated problems getting root-on-LVM working
properly with dynamic majors and SELinux. But it's in rawhide now.
This failure mode is particularly bad when your root fs is in such
an
LVM device, and you just rebuilt all of your initrd images with the
new, ``fixed´´ lvm binary and without lvm.conf. But even if I run it
after booting from a working-lvm.conf initrd, if I run vgscan on the
running system without lvm.conf, it fails just the same (and it
scarily fails to complete)
Want me to bugzilla this?
Yes, please.
--Stephen
6:18 p.m.
On Mar 2, 2004, "Stephen C. Tweedie" <sct(a)redhat.com> wrote:
On Tue, 2004-03-02 at 19:59, Alexandre Oliva wrote:
> Want me to bugzilla this? [raid1 fails to vgscan]
Yes, please.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117318
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Happy GNU Year! oliva(a){lsd.ic.unicamp.br, gnu.org}
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist Professional serial bug killer
7352
days inactive
7371
days old
7 comments
4 participants
participants (4)
-
Alexandre Oliva -
Ben Steeves -
Paul Iadonisi -
Stephen C. Tweedie