There is no boot failure or anything like that I just can't make any changes to lvm2 volumes. Problem was not noticed until a backup that used snapshots ran and failed. This happened on every x86 system I tried and none of the amd64 systems I tried. # lvcreate --name=test --size=1G vg Failed to read int token. Error parsing metadata for VG vg. Cannot process volume group vg # lvcreate --name=test --size=1G --snapshot /dev/vg/home Failed to read int token. Error parsing metadata for VG vg. Cannot process volume group vg lvm.conf is unmodified but brought current. Reproducible: Always Steps to Reproduce: 1.upgrade to lvm2-2.02.183 2.attempt to lvcreate a volume (don't know if other changes work, didn't have spare stuff to delete/modify) 3.downgrade back to 2.02.145-r2 and back to normal Actual Results: # lvcreate --name=test --size=1G vg Failed to read int token. Error parsing metadata for VG vg. Cannot process volume group vg Expected Results: Logical volume "test" created.
post your emerge info on the bug report please.
Portage 2.3.62 (python 3.6.5-final-0, default/linux/x86/17.0, gcc-8.2.0, glibc-2.27-r6, 4.19.27-gentoo-r1 i686) ================================================================= System uname: Linux-4.19.27-gentoo-r1-i686-AMD_Athlon-tm-_Processor-with-gentoo-2.6 KiB Mem: 1031640 total, 269584 free KiB Swap: 524284 total, 524284 free Timestamp of repository gentoo: Tue, 02 Apr 2019 12:44:16 +0000 sh dash 0.5.9.1-r3 ld GNU ld (Gentoo 2.30 p5) 2.30.0 app-shells/bash: 4.4_p23-r1::gentoo dev-lang/perl: 5.26.2::gentoo dev-lang/python: 2.7.15::gentoo, 3.6.5::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.38.3-r1::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.69-r4::gentoo sys-devel/automake: 1.16.1-r1::gentoo sys-devel/binutils: 2.30-r4::gentoo sys-devel/gcc: 8.2.0-r6::gentoo sys-devel/gcc-config: 2.0::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers) sys-libs/glibc: 2.27-r6::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 sync-rsync-verify-max-age: 24 sync-rsync-verify-jobs: 1 sync-rsync-verify-metamanifest: no sync-rsync-extra-opts: local location: /usr/portage/local masters: gentoo priority: 0 ACCEPT_KEYWORDS="x86"ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-mtune=athlon-tbird -march=athlon-tbird -O2 -pipe -fstack-protector-all -fPIE -fPIC -s" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /var/service" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-mtune=athlon-tbird -march=athlon-tbird -O2 -pipe -fstack-protector-all -fPIE -fPIC -s" DISTDIR="/usr/portage/distfiles" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -march=i686 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg candy config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync metadata-transfer multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -march=i686 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed,-z,now" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages/insomnia" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="3dnow acpi berkdb bzip2 cacert cdb cli crypt cryptsetup cxx device-mapper dri extensions gkrellm gmp hardened hddtemp hpn iconv leaps_timezone libedit libtirpc lm_sensors logrotate lvm2create_initrd lz4 lzma lzo matrox minizip modern-top ncurses network nls nocd nptl offensive openntpd optimization pam pcre pcre16 pie policykit readline seccomp ssl tls udev unicode usb userlocales vim-syntax x86 xcsecurity zlib" ABI_X86="32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd 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="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="3dnow 3dnowext mmx mmxext" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" L10N="en en_US" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="apm fbdev mga vesa vga v4l" 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: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I have this same problem on an all-stable x86 box.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=53d8205ff9f4533c17a265a88e44363fd9fd66ed commit 53d8205ff9f4533c17a265a88e44363fd9fd66ed Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2019-04-08 18:34:13 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2019-04-08 18:34:27 +0000 sys-fs/lvm2: Bump to version 2.02.184 this should fix udev related issues as well as scan_lvs issues. Bug: https://bugs.gentoo.org/682578 Bug: https://bugs.gentoo.org/682380 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-fs/lvm2/Manifest | 1 + sys-fs/lvm2/lvm2-2.02.184.ebuild | 258 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 259 insertions(+)
Please test =sys-fs/lvm2-2.02.184 and report back success/failure.
Same problem here: # lvs --version LVM version: 2.02.184(2) (2019-03-22) Library version: 1.02.156 (2019-03-22) Driver version: 4.37.0 Configuration: ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --docdir=/usr/share/doc/lvm2-2.02.184 --htmldir=/usr/share/doc/lvm2-2.02.184/html --enable-dmeventd --enable-cmdlib --enable-applib --enable-fsadm --enable-lvmetad --with-mirrors=internal --with-snapshots=internal --with-thin=none --with-cache=none --with-clvmd=none --with-cluster=none --enable-readline --disable-selinux --enable-pkgconfig --with-confdir=/etc --exec-prefix= --sbindir=/sbin --with-staticdir=/sbin --libdir=/lib --with-usrlibdir=/usr/lib --with-default-dm-run-dir=/run --with-default-run-dir=/run/lvm --with-default-locking-dir=/run/lock/lvm --with-default-pid-dir=/run --enable-udev_rules --enable-udev_sync --with-udevdir=/lib/udev/rules.d --disable-lvmlockd-sanlock --disable-udev-systemd-background-jobs --with-systemdsystemunitdir=/lib/systemd/system CLDFLAGS=-Wl,-O1 -Wl,--sort-common,--as-needed,-z,now # lvcreate --name=test --size=1G vg Failed to read int token. Error parsing metadata for VG vg. Cannot process volume group vg
I have the problem in an genkernel-generated initrd on sparc: >> Scanning for and activating Volume Groups Reading all physical volumes. This may take a while... Failed to read int token. Couldn't read volume group metadata. >> Determining root device ... !! Block device /dev/mapper/vg--castor-root is not a valid root device... / # vgchange --version LVM version: 2.02.173(2) (2017-07-20) Library version: 1.02.142 (2017-07-20) Driver version: 4.39.0 Configuration: ./configure --enable-static_link --prefix=/ --disable-dmeventd --enable-cmdlib --enable-applib --disable-lvmetad --with-lvm1=internal --with-clvmd=none --with-cluster=none --disable-readline --disable-selinux --with-mirrors=internal --with-snapshots=internal --with-pool=internal --with-thin=internal --with-cache=internal --with-raid=internal
I'm also able to reproduce the issue on ACCEPT_KEYWORDS="x86". happens with all of 2.02.183, 2.02.184 and 2.02.184-r1 downgrade to 2.02.145-r2 fixes and does not show the issue
I've possibly found the cause for this at https://github.com/lvmteam/lvm2/blob/420af27f088a3808816ba3ab5b47dfa400fef308/libdm/libdm-config.c#L683 older versions (i.e 2.02.145) did not include the error checking [after the // FIXME line..] and further read just fine through invalid timestamps in the metadata.. I've looked at mine - raw reading from the PV, I've gathered "creation_time" timestamps out of range for strtoll() [at least] on 32 Bit: [..] "pv0", 7680 squid { id = "psiyJR-BKEi-tKVT-PziO-IIXD-fbk4-GkpNSl" status = ["READ", "WRITE", "VISIBLE"] flags = [] creation_time = 13812171003490467839 creation_host = "gw" segment_count = 1 segment1 { [..] I've been also able to find such out of range »creation_time« timestamps below /etc/lvm/archive/* in some vgcfgbackup files - starting 20. Feb 2019 and latest one *not* having such long timestamps as of 11. Jan 2017. So I presume, the previous version (i.e 2.02.145) produced invalid/too long timestamps but read over them, while the new version(s) catch those errors and do »return NULL« and thus causing the reported issue ..
A Quick check for this would be to see if grep -r --files-with-match 1970-01-01 /etc/lvm/archive /etc/lvm/backup/ return any similar lines. The comment also shows that the old version did interpret this as 0 thus showing the epoch as date.
I don't find any out of range dates on mine. My 3 affected systems have the creation times of 1554245908, 1554754579, and 1555531502 which all appear reasonable.
I have that creation time on all of my LVs, I guess that's why things do not work anymore.
I am hitting this on x86, but despite the warnings the system still hobbles along. Today I upgraded a 32bit arm system which wasn't so lucky, after seeing the same sorts of error messages, pvs/lvs/vgs returned no drives/volumes/groups. I'm afraid it would not survive a reboot, so I downgraded back to 2.02.145-r2. Maybe we should put 32bit arches back into ~arch or mask until this is sorted.
I've got the same problem (x86), some of timestamps are broken in file in dir "/etc/lvm/{archive,backup}": creation_time = 17587891077119 # 1970-01-01 00:59:59 +0100
I had this problem after upgrading LLMV2 to Version 2.02.183 yesterday. I started to debug the issue and was able to solve it. The issue is triggered by the following line in the lvm metadata stored on the physical device: creation_time = 9363524486239879167 9363524486239879167 is 0x81F1EBE8FFFFFFFF, which is larger than the maximum allows value of int64_t :-( The issue is caused by the following change in the LMV2 source code: *** LVM2.2.02.145/libdm/libdm-config.c 2016-03-04 19:03:29.000000000 +0100 --- LVM2.2.02.183/libdm/libdm-config.c 2018-12-07 15:14:06.000000000 +0100 *************** *** 664,676 **** --- 679,701 ---- switch (p->t) { case TOK_INT: v->type = DM_CFG_INT; + errno = 0; v->v.i = strtoll(p->tb, NULL, 0); /* FIXME: check error */ + if (errno) { + log_error("Failed to read int token."); + return NULL; + } match(TOK_INT); break; case TOK_FLOAT: v->type = DM_CFG_FLOAT; + errno = 0; v->v.f = strtod(p->tb, NULL); /* FIXME: check error */ + if (errno) { + log_error("Failed to read float token."); + return NULL; + } match(TOK_FLOAT); break; I was able to fix this problem by extracting the PV metadata from the raw device and fixing it: dd if=/dev/<pv-device> skip=9 bs=5 of=lvm.metadata The metadata is text, terminated with \0. I removed everything after the trailing \0 with vi. I changed the lines with creation_time = xxx to have plausible values. I took some time stamps from /etc/llvm/archive/*. At first, I thought, I can put the fixed metadata back on the pv-device using dd, but then I get a checksum error. To get the correct metadata back on the pv-device, I finally had to re-create the physical volume. I had no current backup of the data, so I hesitated before doing this. :-O The most important point to care about is, that pvcreate must be given the uuid from the pv metadata. But pvcreate complained about the corrupted metadata on the pv-device. :-( # pvcreate --uuid xxxxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xxxxxx /dev/md5 --norestorefile WARNING: Failed to connect to lvmetad. Falling back to device scanning. Failed to read int token. Couldn't read volume group metadata from /dev/md5. Metadata location on /dev/md5 at 4608 has invalid summary for VG. Failed to read metadata summary from /dev/md5 Failed to scan VG from /dev/md5 Failed to read int token. Couldn't read volume group metadata from /dev/md5. Metadata location on /dev/md5 at 4608 has invalid summary for VG. Failed to read metadata summary from /dev/md5 Failed to scan VG from /dev/md5 # Perhaps pvcreate has a flag to ignore this error, but I decided to wipe out the existing metadata: # dd if=/dev/zero count=2 of=/dev/md5 # After this command, pvcreate succeeded and I was able to restore the fixed metadata: # vgcfgrestore -f lvm.fixed.metadata <VG> # Now pvs found the missing physical volume, again.
It seems that https://sourceware.org/git/?p=lvm2.git;a=commit;f=libdm/libdm-config.c;h=85dbcda1503eef81be11947be8b9abb0b8c41c9c added a workaround in upstream LVM2 repository. Perhaps it is a good idea to apply this change in Gentoo.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5280d91e79ababa0c952b703fb0f1e1146b68207 commit 5280d91e79ababa0c952b703fb0f1e1146b68207 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-06-02 22:31:26 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-06-02 22:31:26 +0000 sys-fs/lvm2: allow reading metadata with invalid creation_time Closes: https://bugs.gentoo.org/682380 Package-Manager: Portage-2.3.67, Repoman-2.3.13 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> ...ading-metadata-with-invalid-creation_time.patch | 72 ++++++ sys-fs/lvm2/lvm2-2.02.184-r4.ebuild | 270 +++++++++++++++++++++ 2 files changed, 342 insertions(+)
Works for me now. Thanks. Suggest switching which version is ~masked on x86.
