Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
lvm2-2.02.05 produces "unrecognised segment type mirror" errors at bootup, shutdown and on pvscan. This is using device-mapper-1.02.03. When I downgraded to lvm2-2.01.09, the messages went away. When searching google, I couldn't find any information on this message. The message is being discussed in the following thread: http://forums.gentoo.org/viewtopic-p-3288228.html
can you try upgrading to the latest device-mapper?
(In reply to comment #1) > can you try upgrading to the latest device-mapper? > With device-mapper-1.02.03: toaster ~ # pvscan Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror PV /dev/hda5 VG lvm lvm2 [54.40 GB / 0 free] Total: 1 [54.40 GB] / in use: 1 [54.40 GB] / in no VG: 0 [0 ] With device-mapper-1.02.05: toaster ~ # pvscan Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror Unrecognised segment type mirror PV /dev/hda5 VG lvm lvm2 [54.40 GB / 0 free] Total: 1 [54.40 GB] / in use: 1 [54.40 GB] / in no VG: 0 [0 ] Both times running lvm2-2.02.05. Note: I'm running an x86 system, unmasking device-mapper-1.02.05
(In reply to comment #2) > (In reply to comment #1) > > can you try upgrading to the latest device-mapper? > > > > With device-mapper-1.02.03: > toaster ~ # pvscan > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > PV /dev/hda5 VG lvm lvm2 [54.40 GB / 0 free] > Total: 1 [54.40 GB] / in use: 1 [54.40 GB] / in no VG: 0 [0 ] > > With device-mapper-1.02.05: > toaster ~ # pvscan > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > Unrecognised segment type mirror > PV /dev/hda5 VG lvm lvm2 [54.40 GB / 0 free] > Total: 1 [54.40 GB] / in use: 1 [54.40 GB] / in no VG: 0 [0 ] > > Both times running lvm2-2.02.05. > > Note: I'm running an x86 system, unmasking device-mapper-1.02.05 > Forgot to say, running lvm2-2.01.09 and device-mapper-1.02.03: toaster ~ # pvscan PV /dev/hda5 VG lvm lvm2 [54.40 GB / 0 free] Total: 1 [54.40 GB] / in use: 1 [54.40 GB] / in no VG: 0 [0 ]
(In reply to comment #3) I got a solution: if the use flag 'nomirrors' don't bother you, you can put it on (emerge -pv appears with "+nomirrors") and after recompiling the error message "Unrecognised segment type mirror" don't appear. I really don't know if it is a 'good solution' but the problem seems to be solved! PS excuse me for my english! I forgot: I use lvm2-2.02.05 and device-mapper-1.02.03
(In reply to comment #4) > (In reply to comment #3) > I got a solution: if the use flag 'nomirrors' don't bother you, you can put it > on (emerge -pv appears with "+nomirrors") and after recompiling the error > message "Unrecognised segment type mirror" don't appear. > > I really don't know if it is a 'good solution' but the problem seems to be > solved! > > PS > excuse me for my english! > > I forgot: I use lvm2-2.02.05 and device-mapper-1.02.03 > I agree with this, USE="nomirrors" fixes the problem for me.
I just encountered the same message. I had not enabled the "mirror" mapper target. So I'm guessing that this error occurs when the LVM utils try to do something (perhaps checking for mirrors?) that's not supported by the kernel. Probably the "best" solution would be a patch to LVM.. but short of that, a warning in the ebuild might be in order.
I get these messages too and I have mirror support built into my kernel, so it's not a lack of kernel support that's causing it. I haven't actually tried using the mirror functionality since moving to lvm2-2.02.05 so I don't know if these messages are just an annoyance or if there is actual breakage involved. I only ever use the mirroring as part of doing a 'pvmove' so it's not like I'm using it very often.
This bug kept the LVM2 volumes on a hardened AMD64 production box from getting mounted at all. Considering the time that this bug has been open, I am CC'ing arch teams. Please consider dropping stable keywords on this version of lvm2. For good measure, information of the box that is affected: Portage 2.1 (hardened/amd64, gcc-3.4.5, glibc-2.3.6-r3, 2.6.14-hardened-r8 x86_64) ================================================================= System uname: 2.6.14-hardened-r8 x86_64 AMD Opteron(tm) Processor 246 Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1 sys-devel/binutils: 2.16.1-r2 sys-devel/gcc-config: 1.3.13-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe -march=k8" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/init.d /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -pipe -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://red.linx.net/gentoo-portage" USE="amd64 apache2 bash-completion berkdb bzip2 cracklib crypt gdbm gnutls gpgme hardened imap ipv6 jpeg mbox ncurses pam perl perlsuid pic pie png pop readline ssl syslog unicode zlib elibc_glibc kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY There is one LVM2 volume on this machine: VG #PV #LV #SN Attr VSize VFree vg 1 8 0 wz--n 68.02G 23.02G
amd64 is going to defer to releng on this one. They need it for the livecd, and none of us have the ability to test this stuff.
I just added 2.02.06 to portage and was wondering if it resolved this issue. Can you guys test that version, please?
2.02.06 does not change the behavior on my system. I still get multiple "Unrecognised segment type mirror" messages upon boot. # lvm version LVM version: 2.02.06 (2006-05-12) Library version: 1.02.07 (2006-05-11) Driver version: 4.5.0
a non critical error unfortuantely..yet still works as well as the previous version. At least one person was unable to reproduce the bug. x86 is gone.
we're gone!
amd64 gone
In the interest of completeness I still see this problem if I set the nolvmstatic flag for lvm2, but not if I rebuild without it. amd64 with lvm2-2.02.06 device-mapper-1.02.07 gentoo-sources-2.6.17-r4
hppa gone.
ppc64 stable
Stable on mips.
is this still an issue with 2.02.09?
Yes.
(In reply to comment #15) > In the interest of completeness I still see this problem if I set the > nolvmstatic flag for lvm2, but not if I rebuild without it. That is a good point. Because my boxes run X86/hardened I need USE=nolvmstatic for it to compile properly (otherwise the build fails). Lads, do you want me to file a separate bug for this problem on hardened? (Might want to fix the hardened build problem so you can remove a defunct USE-flag?)
I have no solution, but a little more information on that annoying (but otherwise relatively harmless) bug. The sources are lengthy to read, but here is what I found out: The error message results from the fact that LVM somehow encounters a segment type named "mirror" somewhere (this alone is strange enough, because on my box I do not use any mirroring), but this mirror type has not been registered with LVM. I have also found where this segment type "mirror" actually will be registered: In "/usr/lib/liblvm2mirror.so". This seems to be a plugin-modules for lvm2, and if it was loaded, then the message should go away. But it isn't loaded, and so the message occurs. I also understand why it has not been loaded: I'm not using mirroring, so why should that plugin module be loaded? BTW, in order to display the currently registered mirror types (internal ones and from plugins), execute the "segtypes" command from within the lvm shell. You'll see: No "mirror" type will be displayed. When the "nolvmstatic" USE-flag is *not* set, the message should also go away, because then there will be no plugin-modules which have to be loaded, and thus all availables segment types will be accessible at all times. However, this is certainly not a solution to the problem, which is: Where the heck does lvm find that mysterious segment type in my LVM on-disk data? Nevertheless, I wanted to report what I did find out, in case someone is interested.
I have now examined the LVM2 on-disk data structures of one of my PVs with hexedit. I looked at the positions reported by "pvs -vvv". Interestingly enough, those on-disk data structures turned out to be plain ASCII text - exactly the same text which will be backed up into the /etc/lvm/backup directory if the command "vgcfgbackup" is run. And: Nowhere any trace of a "mirror" entry. LVM must be heavy on drugs still finding some... ;-)
Correction of my last entry: The on-disk data structures are not identical to what gets backed up, but very similar: First the C-struct-like volume-group (or whatever) definitions come, followed by the "version =" and comments stuff. In the backup file things are reversed. The end of the ASCII on-disk-data structures seems to be marked by a single byte with value zero.
wfm ppc gone
is this bug still needed?
(In reply to comment #26) > is this bug still needed? I assume yes. The last time I compiled with mirror target support enabled, the error still occurred (at least for x86). Building a static version will also eliminate the problem. But if using the non-static version with mirror target support enabled... ;-)
Ok then please try 2.02.10 and 2.02.17 to see if upstream has solved the problem.
(In reply to comment #28) > Ok then please try 2.02.10 and 2.02.17 to see if upstream has solved the > problem. Tested both versions. Does still not work without the warning. Seems upstream did nothing about it. And just for your reference, here is my line from package.use which triggers the problem: sys-fs/lvm2 nolvmstatic nolvm1 If the following line is used instead, the problem goes away: sys-fs/lvm2 nolvmstatic nolvm1 nomirrors (But of course, one cannot to this if the mirror target is actually required.) BTW: Is upstream actually aware of the problem? That is, are Gentoo bugzilla reports relayed to upstream at all? Not that we wait forever for upstream fixing that nuisance, and upstream does not even know...
I can try to add some detail to this issue. This *is* a problem if you want to use 'pvmove', which uses a mirror segment internally. There are three options for the --with-mirrors: 'shared', 'internal', or 'none'. The problem occurs with 'shared' (as a result of USE="nolvmstatic -nomirror"). In my archtesting chroot, it still happens with 2.02.17 (you don't need to use LVM to test it -- just install it and run e.g., 'lvscan'). Looking into the source, in lib/commants/toolcontext.c:_init_segtypes, if the mirror module was installed internally, it just gets added. If it was 'shared', it tries to load the library from a list of files specified in lvm.conf as global { segment_libraries = [ "/usr/lib64/liblvm2mirror.so" ] } (which, btw, is not in the default config) (the /lib64/ is because I'm on amd64) However, and this is where I've lost the trail, with that specification in the config file, I see: AT / # lvscan Duplicate segment type mirror: unloading shared library /usr/lib64/liblvm2mirror.so Unrecognised segment type mirror which is rather contradictory! I'll see what else I can find out.
Huh, it looks like a pretty trivial change -- basically, when it loaded a shared library, it added it to the list of segment types, *then* checked if a segment type with that name was already in the list. And, of course, it was, because it had just added it. The attached patch fixes this by reversing the order of the adding and the dupe-checking. I don't get the warning with this patch. However, this doesn't fix the problem of the missing configuration pointing to the various /usr/lib/liblvm2XXX.so. This should probaby be sent to upstream. If nobody else volunteers, I'll hop on the mailing list and do it.
Created an attachment (id=109464) [edit] /tmp/toolcontext.patch patch to re-order adding to list and duplicate checking
dustin: since you volunteered, please take it to upstream.
https://www.redhat.com/archives/lvm-devel/2007-February/msg00001.html
I'm puzzled why it took 10 months for anyone to report this upstream, either by raising it on the lvm-devel mailing list or adding me as a 'Cc' to the bug. It's a pity this bugzilla configuration - unlike the ones used by Fedora, Debian and Ubuntu - appears to have no documented mechanism for automatic notification of new bug reports at the package level. Also why does the status remain at "NEW"? Shared-library segment support is not commonly used, which will be why nobody noticed when the bug got introduced. It was originally intended for the 'lvm1' and 'pool' segment types which only a small subset of users require. A fix will now get included in the next upstream release, 2.02.22. Note that the patch attached to this bug is incomplete - the error path needs changing too - can't delete something that wasn't added.
Created an attachment (id=109564) [edit] Patch from Dave Wysochanski <dwysocha@redhat.com> Patch from Dave Wysochanski <dwysocha@redhat.com> (https://www.redhat.com/archives/lvm-devel/2007-February/msg00002.html)
agk: our actual lvm2 maintainer seems to have been AWOL, and I'm trying to cover the bases. I wasn't aware you had an account on our bugzilla, or I would have CC'd you.
Yep - I've had a bugzilla account here for 2.5 years. As upstream maintainer I take an interest in device-mapper/lvm2-related problems in all the major distributions, and am always willing to consider incorporating changes upstream that make life easier for any particular distro - as well as bug fixes of course Fedora/RHEL has not used dynamically-loaded segment types so far.
closing this is integrated in upstream already.
