Hide Forgot
Description of problem: Log in to iSCSI target. Version-Release number of selected component: lvm2-2.02.98-12.fc19 Additional info: reporter: libreport-2.1.6 backtrace_rating: 4 cmdline: /usr/sbin/lvmetad crash_function: dm_malloc_aux executable: /usr/sbin/lvmetad kernel: 3.10.9-200.fc19.x86_64 runlevel: N 5 uid: 0 Truncated backtrace: Thread no. 1 (9 frames) #3 dm_malloc_aux at mm/dbg_malloc.c:269 #4 _new_chunk at mm/pool-fast.c:281 #5 dm_pool_alloc_aligned at mm/pool-fast.c:101 #6 dm_pool_alloc at mm/pool-fast.c:85 #7 dm_pool_zalloc at mm/pool.c:72 #8 dm_config_create at libdm-config.c:102 #9 dm_config_from_string at libdm-config.c:181 #10 client_thread at daemon-server.c:382 #12 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Created attachment 790262 [details] File: backtrace
Created attachment 790263 [details] File: cgroup
Created attachment 790264 [details] File: core_backtrace
Created attachment 790265 [details] File: dso_list
Created attachment 790266 [details] File: environ
Created attachment 790267 [details] File: exploitable
Created attachment 790268 [details] File: limits
Created attachment 790269 [details] File: maps
Created attachment 790270 [details] File: open_fds
Created attachment 790271 [details] File: proc_pid_status
Created attachment 790272 [details] File: var_log_messages
Log in to iSCSI target. LUNs on target contain VM disks, which use LVM. reporter: libreport-2.1.6 backtrace_rating: 4 cmdline: /usr/sbin/lvmetad crash_function: dm_malloc_aux executable: /usr/sbin/lvmetad kernel: 3.10.9-200.fc19.x86_64 package: lvm2-2.02.98-12.fc19 reason: Process /usr/sbin/lvmetad was killed by signal 11 (SIGSEGV) runlevel: N 5 uid: 0
(In reply to Ian Pilcher from comment #12) > Log in to iSCSI target. LUNs on target contain VM disks, which use LVM. > Please, post the output of lvmdump -l (this will include lvmetad dump so we'll see what's cached in lvmetad daemon). If I understand correctly, your setup is: on host side: iSCSI connected LUN -> LVM (then the LVs used as VM disk) on guest side: LVM If that is true, please, consider using devices/global_filter to completely filter out the guest side LVM volumes so they don't interfere with host side LVM. Anyway, even without filtering, it should not segfault, of course. That "lvmdump -l" should help us a bit - please, attach it to this report. Thanks.
Created attachment 797372 [details] Output of lvmdump -l (In reply to Peter Rajnoha from comment #13) > Please, post the output of lvmdump -l (this will include lvmetad dump so > we'll see what's cached in lvmetad daemon). Done. > If I understand correctly, your setup is: > on host side: iSCSI connected LUN -> LVM (then the LVs used as VM disk) > on guest side: LVM That is correct. > If that is true, please, consider using devices/global_filter to completely > filter out the guest side LVM volumes so they don't interfere with host side > LVM. That was actually my first thought. Unfortunately, I can't come up with a filter with will ignore /dev/sdc (for example) when it's an iSCSI LUN but still use it when it's a USB drive. (Yes, I've been known to use LVM on external drives.)
(In reply to Ian Pilcher from comment #14) > Created attachment 797372 [details] > Output of lvmdump -l > > (In reply to Peter Rajnoha from comment #13) > > Please, post the output of lvmdump -l (this will include lvmetad dump so > > we'll see what's cached in lvmetad daemon). > > Done. Thanks, I'll have a look... > > > If that is true, please, consider using devices/global_filter to completely > > filter out the guest side LVM volumes so they don't interfere with host side > > LVM. > > That was actually my first thought. Unfortunately, I can't come up with a > filter with will ignore /dev/sdc (for example) when it's an iSCSI LUN but > still use it when it's a USB drive. (Yes, I've been known to use LVM on > external drives.) The best is to accept only known PVs and reject any other - maybe try to use a match against /dev/disk/by-* entries - these include some constant name schemes or IDs that do not change upon reboot/connection (e.g. vendor, model names or WWN in case of iSCSI). If you're using lvmetad (global/use_lvmetad=1 in lvm.conf), be sure to use devices/global_filter instead of devices/filter setting.
Upstream fix in b5aad86710be57833879ac0e8609021828949682.
*** Bug 1003278 has been marked as a duplicate of this bug. ***
(In reply to Petr Rockai from comment #16) > Upstream fix in b5aad86710be57833879ac0e8609021828949682. Any chance of a build with this fix included?
(In reply to Ian Pilcher from comment #18) > (In reply to Petr Rockai from comment #16) > > Upstream fix in b5aad86710be57833879ac0e8609021828949682. > > Any chance of a build with this fix included? There are more patches queued for F19. I'd need to find some time to backport them, but I hope this Friday or during next week definitely.
*** Bug 997656 has been marked as a duplicate of this bug. ***
lvm2-2.02.98-13.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lvm2-2.02.98-13.fc19
Package lvm2-2.02.98-13.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lvm2-2.02.98-13.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20436/lvm2-2.02.98-13.fc19 then log in and leave karma (feedback).
lvm2-2.02.98-13.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.