After upgrading to sys-fs/lvm2-2.02.171 lvm2 fail to start: > * Setting up the Logical Volume Manager ... > /proc/self/fd/0: unrecognized option '--config' > Error during parsing of command line. > * Failed to setup the LVM > [ !! ] > * ERROR: lvm failed to start
Do we know the actual command invoked here, and what the binary looks like in the filesystem? (There have been major changes to command line argument processing recently, but everything correct that worked before was supposed to continue to work.)
OK, I've located the script that leads to this output and it does look like a case that wasn't tested!
At first sight, the --config argument got silently ignored before - it had no effect - and now instead it gives an error message (with an incorrect prefix of argv[1] instead of argv[0]). 1) We need to fix the prefix on the error message. 2) If we confirm --config has always been incorrect syntax, then gentoo may need to remove it from the top level and apply it to each command separately. 3) It might be possible (but tricky) to support it at the top 'lvm' level in future, or there might be an alternative method added for scripts. We'll work through this properly next week.
Reproducer: echo '#! lvm --config fff \npvscan' | lvm /proc/self/fd/0 --config fff Note how 'fff' is invalid config but does not give an error, implying it's not getting used.
Error message problem opened as upstream bug https://bugzilla.redhat.com/1448609
If you replace the two occurrences of /proc/self/fd/0 with vgs, the script works with >=lvm2-2.02.169 > sed -e 's|/proc/self/fd/0|vgs|g' -i /etc/init.d/lvm I do that in the PKGBUILD, after I grabbed the gentoo lvm and device-mapper scripts from github.
*** Bug 617866 has been marked as a duplicate of this bug. ***
For clarification the syntax is lvm <command> parameters (which can possibly include --config) Or it is lvm file (where file is a command script) however lvm <script> does not work, if the script does not include a shebang, whilst the man page states in contrast: A file containing a simple script with one command per line can also be given on the command line. The script can also be executed directly if the first line is #! followed by the absolute path of lvm. This reads like the shebang is only required if you want to execute the script directly (as in pass it to exexcve). Since lvm <scriptname> fails, I assume that lvm does actually execute /proc/self/fd/0 (by invoking sh), which in turn means, that the output of /proc/self/fd0: error is correct. Compare this to a faulty script starting with a shebang and executing it with sh scriptname, then the scriptname will get printed out as well.
After removing the --config option, I also have the following error: Command does not accept argument: RC_TMPDIR=/run/openrc/tmp This is happening when executing "vgscan --mknodes". Also, it works when I remove --mknodes, and if I replace it by any other command (such as --cache) I have the same error. It seems that it tries to decode the n-th environment variable, n being the number of parameter. In fact, if I put 2 arguments I have the following error instead: Command does not accept argument: LANG=en_US.utf8 The command works on my shell, so the problem is from the lvm script interpreter. Also, what's wrong with using /bin/sh instead of lvm binary to execute the script? Except for the fact that the commands executed are not checked. It works on my system (/bin/sh is bash).
(In reply to Nicolas Porcel from comment #9) > Also, what's wrong with using /bin/sh instead of lvm binary to execute the > script? Except for the fact that the commands executed are not checked. It > works on my system (/bin/sh is bash). The original intent was to only pay the LVM startup cost once: basically start up LVM and do all of 'pvscan && vgscan --mknodes && vgchange --sysinit -a ly' in a single exec of lvm, with lvm.conf overridden (later also added the startup of locking). I'm ok with changing the script instead of modifying LVM, because it was a very niche case: on old systems with lots of disks it saved a LOT of startup time, I think it was ~200 spinning disks in a fiber channel system.
Ran into this today... while there is no fix, shouldn't the affected version be masked? Kinda scary to see all these unknown filesystem, unknown UUID messages on bootup :-) > The original intent was to only pay the LVM startup cost once: basically start up LVM and do all of 'pvscan && vgscan --mknodes && vgchange --sysinit -a ly' in a single exec of lvm I had performance issues with LVM [ init script taking minutes to finish ] a few years ago, IIRC it was because the startup script enabled/disabled each LV individually instead of doing it one go with -a y / -a n Thanks for looking into it @all.
I masked =sys-fs/lvm2-2.02.171 via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bab6535f0943de41a859a305e1a615e92bc4d3ca
(In reply to Thomas Deutschmann from comment #12) > I masked =sys-fs/lvm2-2.02.171 via > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=bab6535f0943de41a859a305e1a615e92bc4d3ca There's a typo in the version number in the commit, it's not masked as of now.
Thanks! Mask adjusted via https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ea117eb82e11d2ff4b1546ff24d57859fb0627e0
2.02.172 in tree now with init script improvements. I've kept in package.mask. Please test CAUTIOUSLY! Breakage in the init script could make your system not boot. [master 9d2680f05f8] sys-fs/lvm2: bump incl. init script fix for bug #617578. Date: Sun Jul 9 15:03:53 2017 -0700 4 files changed, 547 insertions(+) create mode 100644 sys-fs/lvm2/files/lvm.rc-2.02.172 create mode 100644 sys-fs/lvm2/files/lvm2-2.02.172-static-pkgconfig-libs.patch create mode 100644 sys-fs/lvm2/lvm2-2.02.172.ebuild
(In reply to Robin Johnson from comment #15) > 2.02.172 in tree now with init script improvements. > > I've kept in package.mask. > > Please test CAUTIOUSLY! Breakage in the init script could make your system > not boot. I've unmasked it and tried, seems to work fine. But I don't have LVM volumes configured, so that's not that comprehensive a test =)
I already update for =lvm2-2.02.172 and in rebooting the system says message: - "/proc/self/ld/0: unrecognized option '--config'. Same problem. But in initialization not shows errors.
more testing needed everybody!
I installed today sys-fs/lvm2-2.02.173 and works fine. /etc/init/lvm restart gives no errors and I can mount my vg's without problems. Thank you.
Today I did test this on my ~amd64 box, it doesn't work well, but it could be some issue on my side. I have tested: sys-fs/lvm2-2.02.17{1,2,3}. I did upgrade lvm2, rebuild initramfs (using 'genkernel --luks --lvm --disklabel initramfs'), and reboot. All three versions break my initramfs for some reason and sys-fs/lvm2-2.02.171 still breaks real root showing original error message, while .2 and .3 seems to be fine inside real system while using old initramfs/kernel which still boots fine (since initramfs built with new lvm2 is broken). Only error I get in initramfs is: 'Invalid units specification' But there is some weird thing which I think could be related to my setup or missconfiguration, even after upgrade of lvm2 and rebuilding initramfs using genkernel when boot breaks and I choose to use its shell, executing 'lvm version' returns 2.02.88 which is really old version from when this machine is first installed. So newer lvm2 versions break genkernel initramfs, how it is related I have no idea, and why it still says it's 2.02.88. Is there some way to force genkernel to use new lvm2, maybe that will solve the issue? (sys-kernel/genkernel-3.5.1.1)
(In reply to Branko Grubic from comment #20) > Today I did test this on my ~amd64 box, it doesn't work well, but it could > be some issue on my side. Your report below is entirely about the genkernel usage of LVM; but this bug cares about the LVM calls AFTER the pivot to real root is done. > Only error I get in initramfs is: > 'Invalid units specification' Comment out 'units' in your lvm.conf and rebuild the initramfs. > Is there some way to force genkernel to use new lvm2, maybe that will solve > the issue? (sys-kernel/genkernel-3.5.1.1) Requires deeper work to do this; as the genkernel maintainer, I was hoping to integrate dracut into genkernel instead.
=sys-fs/lvm2-2.02.173: Works fine!
Created attachment 488862 [details] lvm.conf lvm.conf
Comment on attachment 488862 [details] lvm.conf I did a new test and had a problems. Error message: "Invalid unit specification". I used genkernel-3.5.1.1, lvm2-2.02.173 and gentoo-sources-4.11.7 Temporary solutions is: I has changed in /etc/lvm/lvm.conf the default value "r" for "h". My system uses luks and lvm.
We've seen the 'units' problem when someone installs a new lvm.conf file then tries to use it with an old version of lvm that doesn't recognise the new value.
I confirm, 2.02.173 works find with systemd, dracut, Linux 4.14.10, both in initramfs and in the system itself. Updating became necessary for me, to be able to boot from a LVM cache device created on current Fedora.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=88839d25fefbdf36300c0e906647d69af3e63a7a commit 88839d25fefbdf36300c0e906647d69af3e63a7a Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2018-08-05 05:48:44 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2018-08-05 05:49:16 +0000 sys-fs/lvm2: drop broken 2.02.17[12] versions Fixed in 2.02.173 & newer. Fixes: https://bugs.gentoo.org/617578 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Package-Manager: Portage-2.3.40, Repoman-2.3.9 sys-fs/lvm2/Manifest | 2 - sys-fs/lvm2/lvm2-2.02.171.ebuild | 299 --------------------------------------- sys-fs/lvm2/lvm2-2.02.172.ebuild | 299 --------------------------------------- 3 files changed, 600 deletions(-)
