Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 409921 - sys-fs/lvm2-2.02.95 fails to start LVM
Summary: sys-fs/lvm2-2.02.95 fails to start LVM
Status: VERIFIED TEST-REQUEST
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Highest blocker with 11 votes (vote)
Assignee: Robin Johnson
URL:
Whiteboard:
Keywords:
Depends on: 354021 361349
Blocks:
  Show dependency tree
 
Reported: 2012-03-27 19:40 UTC by Paweł Rumian
Modified: 2013-03-30 00:02 UTC (History)
50 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
First part of errors during boot. (1.jpg,199.65 KB, image/jpeg)
2012-03-27 19:40 UTC, Paweł Rumian
Details
Second part of errors during boot. (2.jpg,172.40 KB, image/jpeg)
2012-03-27 19:41 UTC, Paweł Rumian
Details
Proposed patch for lvm-start.sh (lvm-start.patch,1.69 KB, patch)
2012-05-09 18:30 UTC, Xake
Details | Diff
version of above patch without cruft (lvm-start.patch,1.57 KB, patch)
2012-05-09 19:09 UTC, Xake
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paweł Rumian 2012-03-27 19:40:16 UTC
Created attachment 306899 [details]
First part of errors during boot.

After upgrading to sys-fs/lvm2-2.02.95 the system failed to mount filesystems belonging to LVM devices during boot phase. The errors are catched at the attached photgraphs.

After logging-in, only the file systems not belonging to LVM were mounted.
The LVM devices were there, and doing 'mount -a' succeded (all partitions were mounted). After this I was able to downgrade to sys-fs/lvm2-2.02.93-r1, which works without problems.

I am using sys-fs/udev-171-r5, the newer verions are masked due to the separate /usr partition on LVM - I haven't yet got enough time to configure initramfs.


emerge --info:
Portage 2.2.0_alpha95 (default/linux/amd64/10.0/desktop, gcc-4.5.3, glibc-2.14.1-r2, 3.3.0-gentoo x86_64)
=================================================================
System uname: Linux-3.3.0-gentoo-x86_64-AMD_Athlon-tm-_II_X3_450_Processor-with-gentoo-2.1
Timestamp of tree: Tue, 27 Mar 2012 19:00:01 +0000
app-shells/bash:          4.2_p24
dev-java/java-config:     2.1.11-r3
dev-lang/python:          2.7.2-r3, 3.2.2-r1
dev-util/cmake:           2.8.7-r5
dev-util/pkgconfig:       0.26
sys-apps/baselayout:      2.1
sys-apps/openrc:          0.9.9.3
sys-apps/sandbox:         2.5
sys-devel/autoconf:       2.13, 2.68
sys-devel/automake:       1.11.3
sys-devel/binutils:       2.22-r1
sys-devel/gcc:            4.5.3-r2
sys-devel/gcc-config:     1.6
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r3
sys-kernel/linux-headers: 3.3 (virtual/os-headers)
sys-libs/glibc:           2.14.1-r2
Repositories: gentoo local-repo
Installed sets: 
ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=native -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-march=native -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--with-bdeps y"
FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS=""
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="pl_PL.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="pl"
MAKEOPTS="-j4"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowext X a52 aac acpi alsa amd64 bash-completion bluetooth branding bzip2 cairo cdda cdr cli cracklib crypt cups cxx dga dri dts dvd dvdr emboss encode exif fam firefox flac fortran gdu gif gnutls gpm gtk iconv ipv6 jpeg lapack lcms mad mmx mmxext mng modules mp3 mp4 mpeg mudflap multilib ncurses nls nptl nptlonly ogg opengl openmp pam pango pcre pdf png ppds pppd python readline session smp spell sse sse2 ssl startup-notification svg sysfs tcpd threads tiff truetype udev unicode usb vorbis x264 xcb xml xmp xorg xulrunner xv xvid zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="directory" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="pl" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby19" USERLAND="GNU" VIDEO_CARDS="radeon r600" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Paweł Rumian 2012-03-27 19:41:16 UTC
Created attachment 306901 [details]
Second part of errors during boot.
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2012-03-28 00:37:12 UTC
In the first image:

* No arrays found in config file or automatically
 File-based locking initialization failed
* Failed to setup the LVM
* ERROR: lvm failed to start

but before that udevd is complaining it cannot execute related programs.

Please post your output of `emerge -vpq sys-fs/udev'.

Also, do you use an initramfs?
Comment 3 Mikael Grahn 2012-03-28 05:47:17 UTC
I'm getting kind of the same problem. I've also upgraded lvm2 but also to the new udev. I'm not running lvm on root but rather on some of my other partitions.

It fails with udevd being unable to execute the pvscan command (just like in his screenshot).
Comment 4 Paweł Rumian 2012-03-28 08:43:17 UTC
(In reply to comment #2)
> In the first image:
> 
> * No arrays found in config file or automatically
>  File-based locking initialization failed
> * Failed to setup the LVM
> * ERROR: lvm failed to start
> 
> but before that udevd is complaining it cannot execute related programs.
> Please post your output of `emerge -vpq sys-fs/udev'.
> Also, do you use an initramfs?

emerge -vpq sys-fs/udev
[ebuild   R   ] sys-fs/udev-171-r5  USE="extras gudev hwdb keymap rule_generator -acl -action_modeswitch -build -debug -edd -floppy -introspection (-selinux) -test" 

No initramfs. 

When I tried to do /etc/init.d/lvm restart (after logging-in with only / mounted, before doing mount -a as described in the first post) it failed with exact the same error as in the second line of first picture:

udevd[????]: failed to execute '/pvscan' '/pvscan --cache --major 9 --minor 4': No such file or directory.
Comment 5 Paweł Rumian 2012-03-28 08:45:33 UTC
And to make it clear: despite LVM refusing to restart, mount -a mounted all partitions from fstab, including the ones on LVM.
Comment 6 Andreas Klauer 2012-03-28 09:55:16 UTC
Same problem here.

I think it tries to lock files while the root partition is still mounted read only, but I'm not sure.

My workaround was setting locking_dir = "/dev/shm/lvm" in /etc/lvm/lvm.conf as /dev is already mounted readwrite and LVM is fine with temporary fs that is lost after reboot.



The Gentoo init script doesn't seem to do this:

       --ignorelockingfailure
              This lets you proceed with read-only metadata operations such as
              lvchange  -ay and vgchange -ay even if the locking module fails.
              One use for this is in a system init script if the  lock  direc‐
              tory is mounted read-only when the script runs.

Maybe that's the reason? But then why did it work up until now? Not sure.
Comment 7 Mikael Hirki 2012-03-28 10:03:27 UTC
Same issue here as well. Downgrading to sys-fs/lvm2-2.02.93-r1 fixed it for me.
Comment 8 Marcin Mirosław 2012-03-28 19:33:50 UTC
Imho this version should be masked as soon as possible.
Comment 9 Fernando (likewhoa) 2012-03-28 20:40:53 UTC
next time please attach /var/log/rc.log which can be enabled at /etc/rc.conf
Comment 10 Fernando (likewhoa) 2012-03-28 20:41:03 UTC
next time please attach /var/log/rc.log which can be enabled at /etc/rc.conf
Comment 11 Mark Nowiasz 2012-03-28 21:31:23 UTC
Same here - gave me quite a start.

Downgrading to 2.02.93-r1 fixed the problem for me, too

This should rate as critical.
Comment 12 Paweł Rumian 2012-03-28 21:46:24 UTC
I do not know the policy of rating importance of bugs, but I can change it to critical, as it can really make a remote system unbootable.
Comment 13 Nikolaos Chatzidakis 2012-03-29 09:02:43 UTC
Same problem here on ~amd64. From my rc.log:

 * Setting up the Logical Volume Manager ...
  File-based locking initialisation failed.
 * Failed to setup the LVM  [ !! ]
 * ERROR: lvm failed to start
Comment 14 Peter Beutner 2012-03-29 12:05:10 UTC
using the old start script fixes the problem for me

cp /usr/portage/sys-fs/lvm2/files/lvm2-start.sh-2.02.67-r1 /lib/rcscripts/addons/lvm-start.sh

overriding the locking_dir setting doesn't seem to work in the new script used in 2.02.95
Comment 15 Peter Beutner 2012-03-29 12:12:49 UTC
> udevd[????]: failed to execute '/pvscan' '/pvscan --cache --major 9 --minor
> 4': No such file or directory.

this is already fixed upstream:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/udev/69-dm-lvm-metad.rules.diff?r1=1.3&r2=1.4&cvsroot=lvm2

============================
Detect the lvm binary path in lvmetad udev rules.

We can't use 'DM_SBIN_PATH'. This one is set only for DM devices but not
for all block devices - the pvscan is run on all relevant block devices!

This LVM_SBIN_PATH (as well as DM_SBIN_PATH) detection should be removed
eventually but for upstream solution, we still have to do that as there are
known cases where the binaries are put either in /sbin or /usr/sbin
(some installation systems, initrd systems etc.).
Comment 16 Daniele 2012-03-29 19:16:29 UTC
Same issue here and exactly the same errors during boot.
I use udev 182-r2.
Comment 17 László Szalma 2012-03-30 07:45:27 UTC
As i see, it's still unconfirmed, and it's still in the portage in this unusable" state, so I confirm it too.

i use ~amd64, and 2.02.93-r1 works fine. (after i copied the usr to /, but that's another story)
Comment 18 A Sotirov 2012-03-30 19:39:38 UTC
boot errors can be worked around editing /lib/udev/rules.d/69-dm-lvm-metad.rules changing the offending rule to :

ENV{ID_FS_TYPE}=="LVM2_member|LVM1_member", RUN+="/sbin/pvscan --cache --major $major --minor $minor"

this however does not solve the problem with vg discovered and added at boot. 

the only solution i've found so far i downgrading the lvm2 to 2.02.93-r1
Comment 19 Navid Zamani 2012-03-31 20:58:37 UTC
I nearly panicked, because I thought I’d lost my data.

My (clean!) workaround was, to “rc single”, make sure the volumes aren’t mounted,  delete all the data that got written to the non-mounted directories (like /var), mask this version in /etc/portage/package.mask/buggy, emerge -autv lvm2, and then reboot.

If this is fixed, I assume it will be -r1, and hence I don’t have to remember any of this later. :)
Comment 20 Paweł Rumian 2012-03-31 21:14:28 UTC
Ekhm, I am rising the importance to highest possible - don't know if there is anoy other way to make it more visible to the developers? 
This bug is constantly receiving votes and more and more users are adding themselves to CC list, still no answer from the developer...
Comment 21 Marcin Mirosław 2012-03-31 21:31:59 UTC
There are more important things like there location of portage tree :/
Comment 22 Navid Zamani 2012-03-31 21:44:39 UTC
Guys, just mask the thing, and go back to the last version, like I said in comment #19. There’s no point in going crazy in a tight loop here. :)

Also: Unless you employ and pay those developers, they don’t have to do anything. Remember: You get all this for free. Just being nice will get you a long way. :)
Comment 23 Paweł Rumian 2012-03-31 21:50:16 UTC
(In reply to comment #22)
> Also: Unless you employ and pay those developers, they don’t have to do
> anything. Remember: You get all this for free. Just being nice will get you
> a long way. :)

My thoughts exactly, if I have sounded offensive it was not my intention. I just was not sure if it was not overlooked by someone, because we have no reply after 4 days.

Still I think that just masking this package by the developer until he has time and will to fix it could be a fair solution.
Comment 24 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-03-31 21:57:05 UTC
sys-fs/lvm2-2.02.95-r1 in the tree with that fix from upstream, please test.
Comment 25 Marcin Mirosław 2012-03-31 22:03:41 UTC
Navid, i agree with you almost in 100%. Developers spends their free time, they don't get money for it. It's great that they want to do it for community, but meseems beeing a developer it's also a kind of liability. Many peoples depend on them.
In critical situation, when os can becomes (almost) unbootable any developer should do something to prevent new person sufering from given issue.
In meanwhile i can see Robin did commit with fix. Thank you.
Comment 26 Navid Zamani 2012-03-31 22:26:01 UTC
(In reply to comment #25)
Well, this is OT. ;)
You are right. That is a dilemma. Open source software kinda expects us all to do it ourselves, if we really need to.
But I found that literally being a bit nice helps a lot. I sometimes offer some money, assistance, just ask them for help on how to do it myself, etc.
Anyway, in case it’s so critical, one can always hire somebody for real money, and let him do it.
Comment 27 Guillaume Castagnino 2012-04-01 07:26:40 UTC
(In reply to comment #24)
> sys-fs/lvm2-2.02.95-r1 in the tree with that fix from upstream, please test.

Sorry, still broken for me. It seems that the udev rules were not enough. I have this in the rc.log:
 * Setting up the Logical Volume Manager ...
  File-based locking initialisation failed.
 * Failed to setup the LVM
 [ !! ]
 * ERROR: lvm failed to start


Notice that my setup is not exotic: / and /usr are not separated and are on a plain partition. My LVM only contains data partitions and home directories. So I do not use an initramfs.
Reverting to 2.02.93-r1 fixes the issue.
Comment 28 Paweł Rumian 2012-04-01 12:06:30 UTC
Also still broken on my machine.

It is slightly better as the following error is NOT appearing:
udevd[????]: failed to execute '/pvscan' '/pvscan --cache --major 9 --minor 4': No such file or directory.

Still it fails after 'File-based locking initialisation failed.'
LVM does not start and the lvm partitions are not mounted.

I have separate /usr /var /home, sys-fs/udev-171-r5
Comment 29 Paweł Rumian 2012-04-01 13:31:45 UTC
OK, it works after following Andreas Klauer's advice from comment #2 and setting
locking_dir = "/dev/shm/lvm" in /etc/lvm/lvm.conf

I also don't know why it had worked earlier.
Comment 30 Paweł Rumian 2012-04-01 13:52:11 UTC
A second thought - maybe the reason that it fails to work comes from the introduction of /run directory, which is going to happen quite soon in Gentoo (AFAIK already done in Fedora, Debian and Suse)?
After the transition /var/lock is going to be a symlink to /run/lock, which is expected to be available at the boot time.

It is just my speculation (or a question to the developer), and not all is clear to me - for example I cannot see how it is going to work while /var is not mounted at the boot time. Maybe /var is going to follow the /usr path and will be expected to be available at boot time by default? 

Anyway, after introduction of /run, /run/lock/lvm would be probably a better choice then /dev/shm/lvm, but the latter works fine for me now.
Comment 31 Maxim Koltsov (RETIRED) gentoo-dev 2012-04-03 13:47:03 UTC
I can confirm this on ~x86, lvm2-2.02.95-r1 and udev-182-r3. I have no initramfs and no separate /var, my root is not on lvm. Setting locking_dir = "/run/lock/lvm" in /etc/lvm/lvm.conf workarounds the problem, maybe we must make it default.
Comment 32 Peter Beutner 2012-04-04 13:29:59 UTC
If you read the startscript you see that it already changes the lock directory via --config 'global { locking_dir = "/dev/.lvm" }'.
however in the new startscript in 2.02.95 that doesn't work.

before it basically did:
---------------
config='global { locking_dir = "/dev/.lvm" }'
/sbin/pvscan --config "${config}" >/dev/null
/sbin/vgscan --mknodes --config "${config}" >/dev/null
/sbin/vgchange --sysinit --config "${config}" -a ly >/dev/null

now:
------------
config='global { locking_dir = "/dev/.lvm" }'
lvm_commands="#! ${lvm_path} --config '${config}'\n"
lvm_commands="${lvm_commands}pvscan\n"
lvm_commands="${lvm_commands}vgscan --mknodes\n"
lvm_commands="${lvm_commands}vgchange --sysinit -a ly\n"
printf "%b\n" "${lvm_commands}" | $lvm_path /proc/self/fd/0 --config "${config}" >/dev/null

but the --config switch does not work for the script mode. see this thread on the lvm mailinglist:
http://www.redhat.com/archives/linux-lvm/2011-January/msg00042.html

just revert back to the old startscript and it will work again. I doubt that the claimed speedup in the new version is that important.
Comment 33 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-04 17:06:16 UTC
xake:
it was you that proposed the script mode change in bug 354021. Please clarify the problems in this bug.
Comment 34 Martin von Gagern 2012-04-04 19:29:54 UTC
I noticed that bug #354021 specifically talks about initramfs and dev-nodes. For me, this bug (and I hope it's the same as the one originally reported) appeared in the following fashion: /usr was mounted from LVM by dracut initramfs, but apparently (I added a bit of ls to the init script) only the /usr lv was listed in /dev during boot. After boot finished, I could log in, and execute "mount -a", which successfully mounted all my lvm partitions. So I take it that by that time, lvm had started all right, and all the nodes were available. For those reasons, you might want to investigate possible race conditions between lvm device node creation and the localmount init script, perhaps including udev.

Relevant packages on my system at the time I encountered this:
sys-kernel/dracut-017-r3 (initramfs probably from -r1, though)
sys-fs/lvm2-2.02.95
sys-fs/udev-171-r5
sys-apps/openrc-0.9.9.3
sys-kernel/gentoo-sources-3.3.0

I'm now back at lvm2-2.02.93-r1 and have .95 masked until this gets addressed.
Comment 35 Xake 2012-04-04 21:44:59 UTC
(In reply to comment #33)
> xake:
> it was you that proposed the script mode change in bug 354021. Please
> clarify the problems in this bug.

The problem in this bug? You are using pvscan, vgscan and messing with locking_dir!

The way you have set up the lvm2 command script makes it use the locking_dir from /etc/lvm/lvm.conf (a strace confirms this).
I will not tell you how to do set that locking_dir up tho, mostly because I see no point in creating RACE CONDITIONS when udev and your script issues pvscan/vgscan and tries to create dev nodes/symlinks at the same time using two different locking dirs.

So really. Drop pvscan and vgscan and you are fine. As this bugreport actually reveals clearly, LVM2 uses udev for those things these days anyway.

Also --sysinit does include --ignorelockingfailures since the --sysinit flag is supposed to be used before / is mounted read/write. Now why does only vgchange have this convenient flag (hint: which command is the only you should need to run)?
Comment 36 Navid Zamani 2012-04-04 23:13:01 UTC
I think we’re going a bit off track here.

The core problem still exists, that when you update to this version of LVM2, the volumes don’t get mounted on boot anymore. After booting, it’s possible though.
Comment 37 Xake 2012-04-05 05:28:43 UTC
(In reply to comment #36)
> I think we’re going a bit off track here.
> 
> The core problem still exists, that when you update to this version of LVM2,
> the volumes don’t get mounted on boot anymore. After booting, it’s possible
> though.

Since you clearly did not read or comprehend my long post I should condense it for you:

Fix:
Comment out pvscan and vgscan commands in /lib/rcscripts/addons/lvm-start.sh.

If that does not work, report back.
Comment 38 Navid Zamani 2012-04-05 05:56:40 UTC
(In reply to comment #37)
> Since you clearly did not read or comprehend my long post I should condense it for you:
> Comment out pvscan and vgscan commands in /lib/rcscripts/addons/lvm-start.sh.
> If that does not work, report back.

How exactly does that
1. create a patch,
2. create a new ebuild (-r1),
3. put the ebuild in the portage tree so people can pull it,
you arrogant unfriendly ass? :)

These bugs are not support forum threads. Their point is not only to find a fix, but to get the fix into the portage tree. How is the status on that, by the way?
(I’d already done it myself long ago, if I had access, instead of being in stupid arguments with people here.)
Comment 39 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-05 06:12:13 UTC
(In reply to comment #38)
> (In reply to comment #37)
> > Since you clearly did not read or comprehend my long post I should condense it for you:
> > Comment out pvscan and vgscan commands in /lib/rcscripts/addons/lvm-start.sh.
> > If that does not work, report back.
> 
> How exactly does that
0. Prove where the bug is, such that a minimal patch can be created.

Please test it. Since I haven't reproduced the problem on my systems at all.
Comment 40 Navid Zamani 2012-04-05 06:29:24 UTC
(In reply to comment #39)
> 0. Prove where the bug is, such that a minimal patch can be created.
> Please test it. Since I haven't reproduced the problem on my systems at all.

I can give you the usual bug report, so you can reproduce it:
1. Make sure sys-fs/lvm2-2.02.93-r1 is installed.
2. Create a logical volume in any way you like, and format it. Example: Volume group “system”, volume “var” (/dev/system/var)
3. Make sure the logical volume is listed in the fstab, so it gets mounted on boot. Example: /dev/system/var /var reiserfs noatime,acl,user_xattr 0 0 # In which case you would of course have to copy over the files in the old /var.
4. Make sure the lvm init script is in the boot runlevel.
5. Reboot.
6. It gets mounted properly, and everything works.
7. Now update to sys-fs/lvm2-2.02.95. Example: emerge -autv lvm2
8. Reboot again.

Expected result: Everything working as before.

Actual result: Error messages by the lvm init script, then no mounting of the logical volume.
Further trying to mount it manually, shows that dev node (e.g. /dev/system/var) was never created.
Manually activating the lvm volumes does create them, and then allow mounting.
Unfortunately, on the next reboot, the same thing happens again.

Reproducible: Always.

This is exactly how it happened here.
I can give you the actual error messages later, if you really need them, since I first have to update and reboot again, which I obviously can’t do whenever I please. You should have to trouble getting all you need from following the above steps though. :)
Comment 41 Navid Zamani 2012-04-05 06:31:16 UTC
(In reply to comment #39)
> Please test it. Since I haven't reproduced the problem on my systems at all.

Please check, if you have static device nodes, that persist over reboots. If you still can’t reproduce it, I’m glad to help out with the exact error messages, and probably even a nice patch.
Comment 42 Navid Zamani 2012-04-05 06:40:16 UTC
I think I have found a potential cause:
One curious thing, is that the config file wants to add a thin_check_executable setting. (as can be seen with etc-update.)

The executable it sets, doesn’t seem to exist. And no dependency is pulled in.
The config file’s comment also doesn’t recommend disabling that setting.

As far as I understand it, it only gets called, when there are actually thin metadata devices. I don’t think I have those, since I only have a simple mirroring.

So if it is necessary, the executable should of course exist. It also says that if it fails, the activation won’t proceed.
And if it’s not necessary, it should be commented out, to prevent people accidentally enabling it.

I don’t dare not enabling that setting, but I also don’t dare enabling it when the executable doesn’t exist. And worst of all, that so-called “device-mapper-persistent-data” package that’s supposed to contain the executable, also doesn’t exist.
So I’m pondering how to proceed… hmm…
Comment 43 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-05 09:27:22 UTC
(In reply to comment #42)
> I think I have found a potential cause:
> One curious thing, is that the config file wants to add a
> thin_check_executable setting. (as can be seen with etc-update.)
> 
> The executable it sets, doesn’t seem to exist. And no dependency is pulled
> in.
> The config file’s comment also doesn’t recommend disabling that setting.
> 
> As far as I understand it, it only gets called, when there are actually thin
> metadata devices. I don’t think I have those, since I only have a simple
> mirroring.
Do you actually have any thin pools? I doubt it.

> So if it is necessary, the executable should of course exist. It also says
> that if it fails, the activation won’t proceed.
> And if it’s not necessary, it should be commented out, to prevent people
> accidentally enabling it.
> 
> I don’t dare not enabling that setting, but I also don’t dare enabling it
> when the executable doesn’t exist. And worst of all, that so-called
> “device-mapper-persistent-data” package that’s supposed to contain the
> executable, also doesn’t exist.
> So I’m pondering how to proceed… hmm…
I think that's completely unrelated.
Comment 44 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-05 09:30:16 UTC
(In reply to comment #41)
> (In reply to comment #39)
> > Please test it. Since I haven't reproduced the problem on my systems at all.
> 
> Please check, if you have static device nodes, that persist over reboots. If
> you still can’t reproduce it, I’m glad to help out with the exact error
> messages, and probably even a nice patch.

Please just follow what xake suggests, in commenting out exactly the lvm_command lines for pvscan & vgscan --mknodes.


My laptop is udev, with everything on LVM (even root). /var is a separate LV.

The key difference is that I'm using an initramfs, and you're not.

So I'm really wondering if LVM is failing to start up properly when /usr+/var is on a separate device.

Test xake's suggestion, and then build yourself an initramfs (ideally with genkernel).
Comment 45 Paweł Rumian 2012-04-05 09:58:24 UTC
Robin, have you ever noticed the comment which says that after setting locking_dir to something that is writable during boot resolves the problem? 

And if you want to say that current version of LVM works only in configurations with initramfs, please warn about it in a proper way, like it was with udev (postinstall, news). Currently there is no reason to consider using an initramfs.

I really appreciate developers' work, but the moment when I see maintainer saying he does not care because he cannot personally reporoduce a blocker bug with 14 votes and 31 users in CC makes me kinda wonder what's going on.

Anyway, I am going to try commenting the pvscan and vgscan lines and will report back soon.
Comment 46 Paweł Rumian 2012-04-05 10:26:38 UTC
(In reply to comment #37)
> Fix:
> Comment out pvscan and vgscan commands in /lib/rcscripts/addons/lvm-start.sh.

OK, I can confirm that it works indeed. I have commented these lines:
# Extra PV find pass because some devices might not have been available until very recently
# lvm_commands="${lvm_commands}pvscan\n"
# Now make the nodes
# lvm_commands="${lvm_commands}vgscan --mknodes\n"

And I have changed back in /etc/lvm.conf
locking_dir = "/var/lock/lvm"

After these changes LVM starts properly.
Comment 47 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-05 10:46:05 UTC
(In reply to comment #45)
> Robin, have you ever noticed the comment which says that after setting
> locking_dir to something that is writable during boot resolves the problem?
/var is not mounted or writable on my system when the LVM service starts.
 
> And if you want to say that current version of LVM works only in
> configurations with initramfs, please warn about it in a proper way, like it
> was with udev (postinstall, news). Currently there is no reason to consider
> using an initramfs.
I don't have a suitable non-LVM system to test this.

> I really appreciate developers' work, but the moment when I see maintainer
> saying he does not care because he cannot personally reporoduce a blocker
> bug with 14 votes and 31 users in CC makes me kinda wonder what's going on.
Where did I say I didn't care? I want a fix that works for the majority of people.
Comment 48 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-05 10:47:19 UTC
(In reply to comment #46)
> (In reply to comment #37)
> > Fix:
> > Comment out pvscan and vgscan commands in /lib/rcscripts/addons/lvm-start.sh.
> 
> OK, I can confirm that it works indeed. I have commented these lines:
...
So for your case, that solves it.

Now what do we do for the case of non-udev users, where the --mknodes is required so that they get /dev/$VG/$LV*?
Comment 49 Paweł Rumian 2012-04-05 10:49:33 UTC
(In reply to comment #48)
> Now what do we do for the case of non-udev users, where the --mknodes is
> required so that they get /dev/$VG/$LV*?
A conditional on udev use flag would not work?
Comment 50 Xake 2012-04-05 17:14:40 UTC
(In reply to comment #45)
> And if you want to say that current version of LVM works only in
> configurations with initramfs, please warn about it in a proper way, like it
> was with udev (postinstall, news). Currently there is no reason to consider
> using an initramfs.
> 

<rant with facts about udev and a separat /usr>
Oh, just shut that rubbish up. Using a separate /usr has been broken for a long time. There are a huge number of bugreports related to devices not working that you can trace back to that. Some of them really old. My bugreport about it has existed for over a year.
The problem is that Lennart when he built a new booting handler he also realized that mounting /usr may need udev, and udev may need half of the /usr/lib/*.so to mount stuff or run its probers. And all of a sudden people realized that he was right. And had to take the usual shitstorm from the vocal troopers that understand less then they think they do. Usually because the bugs that a separat /usr usually leads to are not THAT big of a problem (udisks not reporting raids and vgs correctly, media devices not being properly identified if they were plugged before boot, some scanner too) and because of that people tends to blame the media-players/udisks/scanners...
</rant>


(In reply to comment #38)
> How exactly does that
> 1. create a patch,
> 2. create a new ebuild (-r1),
> 3. put the ebuild in the portage tree so people can pull it,
> you arrogant unfriendly ass? :)
> 

Why yes, I like being an unfriendly ass sometimes. I hope noone takes to much offence, I often mean well.;) I also knew my long posts may not always bee the most parsable things on earth so I did what I thought was needed to be done:
0. I posted a description on what you could try out to see if my hunch was right, since I cannot reproduce this with my current systems setup.
1. I did not create a patch since I did not have the time, or the will to spend time on something I could not confirm if it worked.
2. as I did not have the time for a patch, I see no need to spend the time on a ebuild
3. I do not have the commit access anyway
4. Even if I did I would not have commited anything without knowing it being properly tested by more then just me and Genkernel, as it does it things, Openrc does other.


(In reply to comment #48)
> Now what do we do for the case of non-udev users, where the --mknodes is
> required so that they get /dev/$VG/$LV*?

How about just check if /dev is mounted tmpfs/devtmpfs? My guess is that nobody in their right mind uses that with devfs/static /dev on their root partition. Unless they have some crazy tarball-things being unpacked, but that usually means embedded and I just like seeing embedded people putting /usr on LVM without knowing how to handle this....
Comment 51 Navid Zamani 2012-04-05 17:26:49 UTC
[Easy guys… :) Raging won’t help anyone. I will ignore the flames below and continue solving this:]

I’ve done a reboot now, and have the errors of the log file here:

udevd[4776]: failed to execute '/pvscan' '/pvscan --cache --major 8 --minor 14': No such file or directory
udevd[4779]: failed to execute '/pvscan' '/pvscan --cache --major 8 --minor 10': No such file or directory
udevd[4780]: failed to execute '/pvscan' '/pvscan --cache --major 8 --minor 24': No such file or directory
udevd[4783]: failed to execute '/pvscan' '/pvscan --cache --major 8 --minor 11': No such file or directory
udevd[4784]: failed to execute '/pvscan' '/pvscan --cache --major 8 --minor 25': No such file or directory
udevd[4795]: failed to execute '/pvscan' '/pvscan --cache --major 8 --minor 22': No such file or directory
udevd[4797]: failed to execute '/pvscan' '/pvscan --cache --major 8 --minor 6': No such file or directory

And the interesting thing: *After* having booted, doing the following, makes it work:
# In case you have e.g. /var mounted via lvm, and want to delete the accidentally created contents in the non-mounted directory.
rc single
rm -rf $ACCIDENTAL_MOUNT_POINT_CONTENT # In my case that’s /var/*
/etc/init.d/lvm restart
rc

So it’s apparently a dependency/timing problem.
No wonder it’s hard to reproduce. :)
Comment 52 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-05 18:55:07 UTC
Ok, so far we have two solutions reported to work:
1. change locking_dir in lvm.conf to somewhere known writable
2. skip vgscan/pvscan

Can I please have some tester on a third solution as well
3. Restore vgscan/pvscan, add --ignorelockingfailure to them.
(make sure you undo the other changes above first).


Here's what I'm thinking, by way of the complete solution:
1. If we can get /run to be always available, set locking_dir to that in the stock config (probably /run/lock).
2. During the lvm-start:
2.1. Pull the config for locking_dir
2.2. check if it's in location that exists and is writable
2.3. If NOT writable, add --ignorelockingfailure
Comment 53 Andy Kittner 2012-04-05 19:30:14 UTC
(In reply to comment #52)
> Ok, so far we have two solutions reported to work:
> 1. change locking_dir in lvm.conf to somewhere known writable
> 2. skip vgscan/pvscan
> 
> Can I please have some tester on a third solution as well
> 3. Restore vgscan/pvscan, add --ignorelockingfailure to them.
> (make sure you undo the other changes above first).

For me this seems to work as well, it just prints a warning and then continues to boot normally:

 * Setting up the Logical Volume Manager ...
  File-based locking initialisation failed.
  File-based locking initialisation failed.
Comment 54 Paweł Rumian 2012-04-05 21:56:46 UTC
(In reply to comment #50)
> (In reply to comment #45)
> > And if you want to say that current version of LVM works only in
> > configurations with initramfs, please warn about it in a proper way, like it
> > was with udev (postinstall, news). Currently there is no reason to consider
> > using an initramfs.
>
> <rant with facts about udev and a separat /usr>
> Oh, just shut that rubbish up. Using a separate /usr has been broken for a
> long time. 

As it is a bug report I won't continue this rant, but just suggest you to improve reading skills. 
I was writing that currently there is no reason to consider using an initramfs to make *LVM* working. And if at some point in time initramfs will be needed to make *LVM* working, then the warning should be as clear as it was in udev case.

(In reply to comment #52)
> Can I please have some tester on a third solution as well
> 3. Restore vgscan/pvscan, add --ignorelockingfailure to them.
> (make sure you undo the other changes above first).

LVM starts fine with messages about 'File-based locking initialisation failed.' exactly like in the post above.
Comment 55 Xake 2012-04-05 23:35:52 UTC
(In reply to comment #52)
> Here's what I'm thinking, by way of the complete solution:
> 1. If we can get /run to be always available, set locking_dir to that in the
> stock config (probably /run/lock).
> 2. During the lvm-start:
> 2.1. Pull the config for locking_dir
> 2.2. check if it's in location that exists and is writable
> 2.3. If NOT writable, add --ignorelockingfailure

Going for a writable locking dir sounds good. I am still not convinced in the whole "we should unconditionally run *scan/mknodes and unnecessary interfere with udev"-thing tho.

For example:
lillen ~ # rm /dev/VirtIO/ -rf
lillen ~ # rm /dev/mapper/VirtIO-*
lillen ~ # vgmknodes
  The link /dev/VirtIO/Windows7 should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/VirtIO/Fedora16 should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/VirtIO/Backup should had been created by udev but it was not found. Falling back to direct link creation.
  The link /dev/VirtIO/Fedora17-preupgrade should had been created by udev but it was not found. Falling back to direct link creation.
lillen ~ # ls -l /dev/mapper/
totalt 0
crw------- 1 root root  10, 236  6 apr 01.20 control
brw------- 1 root root 252,   2  6 apr 01.21 VirtIO-Backup
brw------- 1 root root 252,   1  6 apr 01.21 VirtIO-Fedora16
brw------- 1 root root 252,   3  6 apr 01.21 VirtIO-Fedora17--preupgrade
brw------- 1 root root 252,   0  6 apr 01.21 VirtIO-Windows7

However if I after that (or booting with a proper working boot-config):
lillen ~ # udevadm trigger && udevadm settle && ls -l /dev/mapper
totalt 0
crw------- 1 root root 10, 236  6 apr 01.24 control
lrwxrwxrwx 1 root root       7  6 apr 01.24 VirtIO-Backup -> ../dm-2
lrwxrwxrwx 1 root root       7  6 apr 01.24 VirtIO-Fedora16 -> ../dm-1
lrwxrwxrwx 1 root root       7  6 apr 01.24 VirtIO-Fedora17--preupgrade -> ../dm-3
lrwxrwxrwx 1 root root       7  6 apr 01.24 VirtIO-Windows7 -> ../dm-0


So as you see the results of vgmknodes (the same goes for vgscan --mknodes) and udev is not identical, and I have seen programs having problem when those devnodes were not links (mostly from the time when Genkernel was broken, and as that was about a year ago I cannot really remember which programs, but I remembering it sever enough to upgrade my stable system to an unstable Genkernel after I fixed it).
And as I read the message, udev not creating those links are really not supposed to happen and the only case I have found when that happend is if the initramfs/initrd creates those dev-nodes, discards them, and the kernel still thinks they exists, telling udev not to re-create them (you need an unconditional "udevadm trigger --action=change" for that IIRC, and that is not what OpenRC does currently).
Comment 56 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-04-06 01:18:11 UTC
(In reply to comment #55)
> Going for a writable locking dir sounds good. I am still not convinced in
> the whole "we should unconditionally run *scan/mknodes and unnecessary
> interfere with udev"-thing tho.
I agree that it should not be unconditionally, but we need to detect at runtime about running it.

> For example:
(snip example of real device nodes vs symlinks to device nodes)
The output of these two is functionally identical. They point to exactly the same major/minor numbers in the end.

> So as you see the results of vgmknodes (the same goes for vgscan --mknodes)
> and udev is not identical, and I have seen programs having problem when
> those devnodes were not links (mostly from the time when Genkernel was
> broken, and as that was about a year ago I cannot really remember which
> programs, but I remembering it sever enough to upgrade my stable system to
> an unstable Genkernel after I fixed it).
There was a bug in the past in multiple places where symlinks in /dev were not fully resolved before usage. LVM+udev got hit the most because depending how you run udev/LVM, you always get the same overall set of items, but the direction of the symlinks differs. (/dev/dm-0 <-> /dev/mapper/VirtIO-Windows7).
Every case of that bug I'm aware of was fixed by adding readlink around the input.

The ideal case I want is:
pvscan, vgscan, vgchange, wait for udev if present, vgmknodes

Alternatively, I can add a new init.d script that runs vgmknodes, and NOT have the main lvm script call vgmknodes. If you use udev, you should NOT have that script in your runlevels.
Comment 57 Alexey Shvetsov archtester gentoo-dev 2012-04-07 16:04:24 UTC
Same here. Worked aroud setting lvm lock dir as /run/lock
Comment 58 Xake 2012-04-07 21:57:57 UTC
(In reply to comment #56)
> (In reply to comment #55)
> > Going for a writable locking dir sounds good. I am still not convinced in
> > the whole "we should unconditionally run *scan/mknodes and unnecessary
> > interfere with udev"-thing tho.
> I agree that it should not be unconditionally, but we need to detect at
> runtime about running it.
> 

http://blog.siphos.be/2012/04/get-your-devtmpfs-ready

This post makes me think that checking if /dev is devtmpfs may be the proper way to detect this.
Comment 59 Xake 2012-04-07 22:06:25 UTC
(In reply to comment #58)
> (In reply to comment #56)
> > (In reply to comment #55)
> > > Going for a writable locking dir sounds good. I am still not convinced in
> > > the whole "we should unconditionally run *scan/mknodes and unnecessary
> > > interfere with udev"-thing tho.
> > I agree that it should not be unconditionally, but we need to detect at
> > runtime about running it.
> > 
> 
> http://blog.siphos.be/2012/04/get-your-devtmpfs-ready
> 
> This post makes me think that checking if /dev is devtmpfs may be the proper
> way to detect this.

or maybe even say certain because if udev does not work fully without devtmpfs, then we may need vgmknodes even if udev is running.

I would say: have pvscan, vgscan and vgmknodes depend on if /dev is devtmpfs.
Comment 60 Alexey Shvetsov archtester gentoo-dev 2012-05-04 12:53:41 UTC
this bug is realy anoying. Also its high priority and renders system into unbootable state. So it should be fixed!

Simpe fix is to place lvm2 locks to /run/lock
Comment 61 Alexey Shvetsov archtester gentoo-dev 2012-05-05 09:16:00 UTC
Hey!

Its here for about a mounth. And realy need only few lines fix in startup scripts. So when it will be fixed? of affected lvm2 version should be masked!
Comment 62 Alexey Shvetsov archtester gentoo-dev 2012-05-05 09:21:03 UTC
So looks like new openrc addon for lvm2 is broken for 2.02.95* versions. So may be someone should fix it or just mask before he can fix it?

2 base-system any constructive ideas?
Comment 63 Alexander Vershilov (RETIRED) gentoo-dev 2012-05-05 09:27:29 UTC
confirm this problem with sys-fs/lvm2-2.02.95-r1 and udev-182-r3 and openrc-0.9.9.3
Comment 64 Alexey Shvetsov archtester gentoo-dev 2012-05-05 10:57:25 UTC
2 qa: this bug should be resolved or affected version should be masked until problem will be fixed
Comment 65 Navid Zamani 2012-05-05 11:15:42 UTC
Everyone who still has the problem:
Thankfully this is Gentoo, so we can still solve thinks independently of the maintainers.
Just do this:

MASK="/etc/portage/package.mask/buggy" # Set this to the right file.
echo >> "$MASK"
echo '# Init script can’t find PVs' >> "$MASK"
echo '=sys-fs/lvm2-2.02.95' >> "$MASK"
echo '=sys-fs/lvm2-2.02.95-r1' >> "$MASK"

And when a new release (e.g. -r2) comes out, and that one still fails, just add it right below in the same fashion.

This should allow you to have some peace of mind and a working system, until it’s officially fixed. :)

(And if anyone of you runs a business or something else that depends on it: Remember that you are getting this for free. It’s only fair to offer a bit of money to fix that problem. This changes the situation for many of us. But it still doesn’t mean we actually have the spare time. Or the skill. [Unless you offer huge sums. ^^] )
Comment 66 PhobosK 2012-05-05 11:56:18 UTC
(In reply to comment #65)

> (And if anyone of you runs a business or something else that depends on it:
> Remember that you are getting this for free. It’s only fair to offer a bit
> of money to fix that problem. This changes the situation for many of us. But
> it still doesn’t mean we actually have the spare time. Or the skill. [Unless
> you offer huge sums. ^^] )

This is disgusting !!!
Sorry i know this is not a forum... but i cannot stay silent when i reat this!
Comment 67 Paweł Rumian 2012-05-05 12:11:27 UTC
(In reply to comment #65)
> Thankfully this is Gentoo, so we can still solve thinks independently of the
> maintainers.

I'm afraid you are confusing solution with masking the problem - few possible (and correct) solutions were already proposed above, your workaround is not a solution in any way.

Last thing - even on a discussion forum repeating the same arguments is a bit rude, and you are still repeating the same mantra of non-paid developers (ike in comments #22 and #26).
Comment 68 Navid Zamani 2012-05-05 13:18:17 UTC
(In reply to comment #67)
> I'm afraid you are confusing solution with masking the problem

Uuum, what gave you the idea, that anyone would consider it a solution?
It’s a workaround. I added it, to help you over the bad times.

If you don’t want it, and don’t have anything to offer, stop whining, since you are not entitled to anything.
Comment 69 Navid Zamani 2012-05-05 13:24:07 UTC
(In reply to comment #66)
> This is disgusting !!!
> Sorry i know this is not a forum... but i cannot stay silent when i reat
> this!

Uuum, your comment is a complete waste of space and time. Please stay constructive. Calling somebody disgusting only makes you look like a leech. Raging so hard over nothing, that you can’t even type properly anymore makes it worse. This is not Windows. This is not the paid MS Support hotline. We’re a voluntary community. Chill, man.

I’m not a developer. I’m just another user. I don’t know how to fix this. And I don’t have any money. So I try to be nice, help where I can, and hope somebody who knows what to do is nice enough to fix this.
What exactly do *you* have to offer?

From now on, only useful comments please. thanks.
Comment 70 PhobosK 2012-05-05 13:50:45 UTC
OFFTOPIC
========

(In reply to comment #69)
> (In reply to comment #66)
> > This is disgusting !!!
> > Sorry i know this is not a forum... but i cannot stay silent when i reat
> > this!
> 
> Uuum, your comment is a complete waste of space and time. Please stay
> constructive. Calling somebody disgusting only makes you look like a leech.
> Raging so hard over nothing, that you can’t even type properly anymore makes
> it worse. This is not Windows. This is not the paid MS Support hotline.
> We’re a voluntary community. Chill, man.
> 
> I’m not a developer. I’m just another user. I don’t know how to fix this.
> And I don’t have any money. So I try to be nice, help where I can, and hope
> somebody who knows what to do is nice enough to fix this.
> What exactly do *you* have to offer?
> 
> From now on, only useful comments please. thanks.

Heheh the 'disgusting' was about the comment, not about the person that made it :D

Anyway I do not know who you are and I do not care.

Reading your comments around here, I can say that the last thing you are trying to do, is to be nice. I do not see any actual help offered by you either... Not to speak about being constructive :D

As I said this is not a forum, so go presenting your ideas and comments about open source/payment/users to the proper forums.

With that said.. let's see how useful will be your comments from now on... 

P.S. Oh and BTW when you learn to speak/write in my own language the way i do speak/write in yours (that is, if English is native to you)... then i will accept your note about my typos :P
Comment 71 Navid Zamani 2012-05-05 14:03:50 UTC
(In reply to comment #70)
> Reading your comments around here, I can say that the last thing you are
> trying to do, is to be nice. I do not see any actual help offered by you
> either... Not to speak about being constructive :D

Of course, with enough ignorance  (e.g. of all my previous comments, #65, #51, #42, 41,#40 and #19), that is true.

> As I said this is not a forum, so go presenting your ideas and comments
> about open source/payment/users to the proper forums.

Okay, I was wrong. It’s not just ignorance. It’s http://en.wikipedia.org/wiki/Psychological_projection

> (that is, if English is native to you)

Luxemburgish, German, English, French… in that order.

This is entering kindergarten level now. I’ll stop responding to you. Please do the same and get a therapy.
Comment 72 Paweł Rumian 2012-05-05 14:54:51 UTC
Navid, I remind you that:

- this is not a discussion forum where you can give advices how to workaround the bug, so if you have no idea how to do a PROPER fix, just stay quiet, please
- solution was given in many comments above and summarized in comment #52
- you have suggested masking the package as a workaround in comment #19 and then repeated this suggestion many times in many comments, which is definitely redundant and somewhat boring
- bugzilla is definitely not a place for personal offence so stay quiet or move your rant somewhere else, please
Comment 73 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-05-05 20:20:21 UTC
i'm away due to a death in the family.
/run/lock isn't quite ideal yet, because it's not reliably available on all systems. WilliamH was going to see about the missing bits to have reliable /run in openrc-0.10, then this can move forward.

If you need it before then, and don't have /run, use /dev/ instead, as it will be a devtmpfs mount 99.9% of the time.
Comment 74 Alexey Shvetsov archtester gentoo-dev 2012-05-06 09:11:28 UTC
Anyway br0ken version in tree should be masked
Comment 75 William Hubbs gentoo-dev 2012-05-09 13:49:29 UTC
I'm not an lvm user, so I don't know that I have a way to test this bug, but I did just now look it over and I have some information.

The stable version of OpenRC will mount a tmpfs on /run if the directory exists, and it will create a /run/lock directory.

The bug I put in the dependencies (bug #361349) is for baselayout; it doesn't create the /run directory yet for some reason.

If we don't want to wait for baselayout, we can do what udev does and add the following line to pkg_postinst:

mkdir -p ${ROOT}/run

I'm also very concerned that the init scripts are still using baselayout-1 style addons, which are deprecated in OpenRC. Your init scripts should not be calling start/stop_addon and the *.sh files in /lib/rcscripts should be removed.

Also, the information in comment 35 about the *scan utilities seems important.
Comment 76 Xake 2012-05-09 18:30:09 UTC
Created attachment 311269 [details, diff]
Proposed patch for lvm-start.sh

In essential this patch removes everything "lockingdir" from /lib/rcscripts/addons/lvm-start.sh since it is moot anyways, and implements a test for if devtmpfs is mounted on /dev (recommended by earlier versions of udev, and _needed_ by latter versions of udev anyway).
If devtmpfs is found, then drop *scan since it is moot anyway and udevd is supposed to handle that.


The only ones this can/will break for is people using broken initramfs, as in a initramfs creating said device nodes and not moving the /dev to the newroot. Since the kernel/udevd thinks the device nodes are already created, it does not try to recreate them (or it did not in earlier versions, may be fixed now as more of lvm has been migrated into udevd).

But really, those users should have a initramfs that does mount --move /dev /newroot/dev instead of just discarding their old dev.
This can also happen with old genkernel-initramfs, but are fixed in later stable versions.



I cannot comment on if devfs/static users really need or does not need the part filtered for devtmpfs users, and I do not really care.
Comment 77 Xake 2012-05-09 19:09:35 UTC
Created attachment 311277 [details, diff]
version of above patch without cruft

Sorry, got some debug-cruft into the former.
Comment 78 Jaco Kroon 2012-05-15 15:10:14 UTC
Hi,

I added a /bin/bash directly after the eend to try and troubleshoot this and found a few things.

Firstly, /dev/.lvm that is being used for locking_dir doesn't exist, so file-based locking will always fail.  If one actually issues an "mkdir" /dev/.lvm and then issue the equivalent pvscan --config 'global { locking_dir="/dev/.lvm" }' then the sequence of commands actually works.

However, I cannot get it to work at all using by manually invoking the lvm_commands and printf stuff by hand.  It does work when actually performing a bootup sequence (with 95-r1 at least).

Is there any particular reason to not invoke pvscan, vgscan and vgchange directly?

It seems the common consensus is that on a udev system pvscan and vgscan should not be required - however, there are also legit concerns regarding people that does NOT use udev.

Adding --ignorelockingfailure to pv and vg scan works.  The comments re locking_dir in startup makes sense.

My recommendation would thus be to add the pvscan and vgscan with --ignorelockingfailure for the pvscan and vgscan in the suggested patch by Xake.  That should also cover the non-udev case somewhat decently (or at least, not worse than what it was <.95).

Thanks to all who trouble-shooted on this - you saved me HOURS of effort.
Comment 79 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-05-27 07:05:48 UTC
Please test 2.02.95-r2.
Comment 80 Christer Ekholm 2012-05-27 16:51:55 UTC
(In reply to comment #79)
> Please test 2.02.95-r2.

Works for me.
Comment 81 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-05-27 17:56:14 UTC
By testing, I would also appreciate it if somebody with /var on LVM, but NOT root or /usr on LVM could test booting with the new version.
Comment 82 ninuje 2012-05-28 20:44:10 UTC
(In reply to comment #81)
> By testing, I would also appreciate it if somebody with /var on LVM, but NOT
> root or /usr on LVM could test booting with the new version.

Works for me (root on raid10, /var & /home & /usr/portage on LVM over raid10).

(~x86, no initramfs, openrc-0.10.2, baselayout-2.1-r1, lvm2-2.02.95-r2, and mdadm 3.2.3-r1 [because 3.2.4/3.2.5 is horribly broken with v1.2 superblocks, cf. #416081])
Comment 83 Paweł Rumian 2012-05-29 10:35:17 UTC
lvm2-2.02.95-r2 works fine for me on ~amd64 with sys-fs/udev-171-r6 (no intramfs).

Root on raid1, but both /usr and /var on LVM.
Comment 84 Mark Nowiasz 2012-05-29 17:56:53 UTC
(In reply to comment #81)
> By testing, I would also appreciate it if somebody with /var on LVM, but NOT
> root or /usr on LVM could test booting with the new version.

Works for me (/var, /var/tmp, /usr, and more on lvm).
Comment 85 Frédéric Barthelery 2012-06-03 13:13:35 UTC
Works for me. /home on lvm
Comment 86 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2012-06-17 18:39:21 UTC
Thanks for the testing all