https://bugzilla.kernel.org/show_bug.cgi?id=60758 --- Comment #54 from Akemi Yagi <toracat@xxxxxxxxxx> --- (In reply to Lin Feng from comment #53) > though it's somthing about virtio driver(my guest uses virtio as the storage > driver), looking into this commit it is mainly about C code changes, not > module compiling or not. Also I have checked the modules compiled, in both > cases(with and without this commit) we get virtio_blk.ko module. But the > difference is that with this commit virtio_blk.ko isn't packed into the > initramfs. > > However between both cases there is no environmental changes, with exactly > the same config, same dracut, same gcc, everything...So I don't know why > dracut doesn't pack the virtio_blk.ko into the initramfs, and more kidding I > find that it packed the floppy.ko instead. > (In my case as a workround we can compile virtio moduels into kernel or use > other disk bus driver such as IDE or USB instead) > > But one thing I don't understand can someone tell me why, Will dracut look > through the kernel tree(C codes) to find some useful information to pack the > final initramfs? Thank you for this extensive analysis. I, too, was having the same problem on my KVM guest that uses virtio (host=RHEL 6.5 and guest=CentOS 6.5). Just to reconfirm your findings, I created initramfs with a '--add-drivers virtio_blk' option and the kernel booted just fine. It would indeed be great if we could find out why dracut fails to pick up some particular modules. -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
