kexec-tools version: kexec-tools-2.0.0-2.fc10.i386 When running on a virtual machine that uses virtio-blk for the disks, mkdumprd doesn't include virtio-blk on the image it generates. It tries to detect which modules should be used for the devices backing LVM volumes, but it fails to find the data on sysfs. This is what it does, currently: + vecho 'Looking for driver for device vda2' + NONL= + '[' 'Looking for driver for device vda2' == -n ']' + '[' -n '' ']' ++ echo vda2 ++ sed 's/\//\!/g' + device=vda2 ++ findone -type d /sys/block -name vda2 ++ echo nash-find -type d /sys/block -name vda2 ++ /sbin/nash --force --quiet ++ /bin/awk '{ print $1; exit; }' + sysfs= + '[' -z '' ']' + return From the way findstoragedriverinsys() works, and the usage of '-type d', it looks like the current code is broken because it assumes the /sys/block contents won't be symlinks. BTW, latest mkinitrd contains new code to handle this (and other different cases). I don't know how fixes that should go to both mkinitrd and mkdumprd are being handled today, but duplicating code doesn't seem to be the way to go.
Sorry, we don't currently support kexec/kdump on DomU guests, and I don't think we have any plans to at the moment. If you need to capture vmcores from guest images, xendump is the solution I think you need
This is not on Xen guests, but on KVM guests. Supporting kdump inside KVM guests is a desirable feature. The upstream kernel even had some fix added some time ago to make kdump work inside KVM guests.
I'm not saying that its not a desireable feature, just that its not something I was planning on supporting anytime soon. Getting kdump to work properly with xen was effectively impossible in domU environments. If kexec can work with kvm thats great, but I've not tried it at all. Can you start booting a kernel on rawhide via kexec through a sysrq-c properly yet? I can add this, but it doesn't seem over worthwhile to spend much time on if the kexec infrastructure doesn't work yet. And propgating changes to mkinitrd & mkdumprd isn't at all linked at the moment. mkinitrd still uses nash while we use busybox, so while theres alot of code that could be shared, theres alot that cant. Let me know if kexec works on rawhide, and I'll update the mkdumprd script. thanks.
(In reply to comment #3) > I'm not saying that its not a desireable feature, just that its not something I > was planning on supporting anytime soon. Getting kdump to work properly with > xen was effectively impossible in domU environments. If kexec can work with > kvm thats great, but I've not tried it at all. Can you start booting a kernel > on rawhide via kexec through a sysrq-c properly yet? Yes, sysrq-c boots a kdump kernel properly here, using 2.6.27.5-101.fc10, on a x86_64, and it seems to have properly collected a crash dump. I can also boot a kdump kernel properly when inside a KVM guest, but then it fails to mount the root filesystem. > I can add this, but it > doesn't seem over worthwhile to spend much time on if the kexec infrastructure > doesn't work yet. > > And propgating changes to mkinitrd & mkdumprd isn't at all linked at the > moment. mkinitrd still uses nash while we use busybox, so while theres alot of > code that could be shared, theres alot that cant. I see. I can't complain much about mkdumprd anyway, if linux distributions are still working to avoid duplicating work on the initrd generation code. But I still hope mkdumprd and mkinitrd will share code in the future. > > Let me know if kexec works on rawhide, and I'll update the mkdumprd script. > thanks. It works, here. If it didn't, I was going to open another bug report for that and then make this bug depend on it. ;)
Additional info: the virtio-pci module also needs to be included, for systems using virtio. Latest mkinitrd detects this automatically and includes virtio-pci on the initrd, so probably mkdumprd could use the same technique.
You know, I'm looking over this report, and starting to think this is very simmilar to another report I have, bz 456001. Would you mind please trying the patch that I have there in comment 22? It might not work 100%, but its pretty close. If you can help me finish it up, I'll check it in. Thanks!
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
ping, any update?
closing due to inactivity