Description of problem: I run `lvchange -a n` on LVs located on an external USB disk and then I disconnected the drive, but I have no idea what caused the crash. Version-Release number of selected component: lvm2-2.02.98-11.fc19 Additional info: reporter: libreport-2.1.6 backtrace_rating: 4 cmdline: /usr/sbin/lvmetad crash_function: buffer_realloc executable: /usr/sbin/lvmetad kernel: 3.10.6-200.fc19.x86_64 runlevel: N 5 uid: 0 Truncated backtrace: Thread no. 1 (4 frames) #4 buffer_realloc at config-util.c:284 #5 buffer_read at daemon-io.c:45 #6 client_thread at daemon-server.c:379 #8 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
Created attachment 787074 [details] File: backtrace
Created attachment 787075 [details] File: cgroup
Created attachment 787076 [details] File: core_backtrace
Created attachment 787077 [details] File: dso_list
Created attachment 787078 [details] File: environ
Created attachment 787079 [details] File: exploitable
Created attachment 787080 [details] File: limits
Created attachment 787081 [details] File: maps
Created attachment 787082 [details] File: open_fds
Created attachment 787083 [details] File: proc_pid_status
Created attachment 787084 [details] File: var_log_messages
(In reply to Cristian Ciupitu from comment #0) > Description of problem: > I run `lvchange -a n` on LVs located on an external USB disk and then I > disconnected the drive, but I have no idea what caused the crash. When the disk is disconnected, there's an event generated and then processed by udev and driven by udev rules (/lib/udev/rules.d and /etc/udev/rules.d). This also fires "pvscan --cache" in /lib/udev/rules./69-dm-lvmetad.rules which updates the lvmetad (the LVM metadata daemon - it holds LVM metadata to avoid disk scanning later on). I think this might be a dup of bug #994172. You can try to update with this build (rpm -F *.rpm) and see if it helps. It adds one patch from upstream code that fixes a bug in memory handling: http://koji.fedoraproject.org/koji/taskinfo?taskID=5820953 (The x86_64 arch build itself: http://koji.fedoraproject.org/koji/taskinfo?taskID=5820954)
Just in case my previous statement was ambiguous, I disconnected the drive using `udisks --detach` or GNOME Disks (can't remember which) and only then I unplugged the cable.
(In reply to Cristian Ciupitu from comment #13) > Just in case my previous statement was ambiguous, I disconnected the > drive using `udisks --detach` or GNOME Disks (can't remember which) and > only then I unplugged the cable. That should be OK. Anyway, I've submitted an update for F19 with the patch from comment #12 (lvm2-2.02.98-12.fc19). If the problem still persists, please, reopen this bug report. Thanks.
lvm2-2.02.98-12.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/lvm2-2.02.98-12.fc19
Package lvm2-2.02.98-12.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-12.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15098/lvm2-2.02.98-12.fc19 then log in and leave karma (feedback).
lvm2-2.02.98-12.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
It still happened with lvm2-2.02.98-12.fc19.x86_64.
Yes, I'm sorry for the problem. There's a new patch upstream which we still need to backport - I'll try to do a new update till the end of this week. Marking this one as dup of existing opened bug #1000894 (the source of the problem is the memory management for metadata handling - the "libdm-config" part of the code responsible for structuring LVM metadata into a tree representation). *** This bug has been marked as a duplicate of bug 1000894 ***