Bug 471650 - mkdumprd doesn't include virtio-blk module on image when needed
mkdumprd doesn't include virtio-blk module on image when needed
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kexec-tools (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-14 15:47 EST by Eduardo Habkost
Modified: 2009-04-17 06:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-17 06:59:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eduardo Habkost 2008-11-14 15:47:24 EST
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.
Comment 1 Neil Horman 2008-11-14 16:23:31 EST
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
Comment 2 Eduardo Habkost 2008-11-14 16:34:45 EST
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.
Comment 3 Neil Horman 2008-11-14 20:14:31 EST
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.
Comment 4 Eduardo Habkost 2008-11-15 07:33:30 EST
(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.  ;)
Comment 5 Eduardo Habkost 2008-11-18 10:02:51 EST
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.
Comment 6 Neil Horman 2008-11-20 10:33:08 EST
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!
Comment 7 Bug Zapper 2008-11-26 00:23:44 EST
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
Comment 8 Neil Horman 2009-03-23 07:12:32 EDT
ping, any update?
Comment 9 Neil Horman 2009-04-17 06:59:44 EDT
closing due to inactivity

Note You need to log in before you can comment on or make changes to this bug.