On Wed, Jan 16, 2013 at 10:04 AM, Luis Fernando Alen <luis.alen at izap.com.br>wrote: > Andy, > > Actually I'm not trying to build a whole new kernel. I'm just trying to > apply the patched module into my actual kernel. > > Does this patch really requires a kernel rebuild, or you mean building a > new one will save me from the trouble of applying the module into the > running kernel? > Perhaps I'm missing some key information here, but you should not need to rebuild anything at all. You only need to modify the ramdisk to load the xen_blkfront module with sda_is_xvda=1 . There are various ways to do this; adding xen_blkfront.sda_is_xvda=1 to the kernel command line in grub.conf is probably the most expedient. Hope this helps. Andy > > Luis Alen > www.izap.com.br > Ligue com tarifa local de todo o Brasil 4020.3000 > > > > On Wed, Jan 16, 2013 at 10:57 AM, Nico Kadel-Garcia <nkadel at gmail.com>wrote: > >> >> >> On Tue, Jan 15, 2013 at 8:39 PM, Luis Fernando Alen < >> luis.alen at izap.com.br> wrote: >> >>> Thank you, Andy. >>> >>> I tried to apply the patch you guys mentioned by compiling the module >>> following instructions at >>> http://wiki.centos.org/HowTos/BuildingKernelModules#head-d2e4c05886f94c701e4ae74387d41d8c40c25d01, >>> but it didn't work. >>> >>> I've been struggling with it for the last 8 hours and no luck so far. >>> >>> I really don't know what's wrong. I'm not a linux kernel developer and >>> I'm most likely failing because of something stupid. >>> >>> I know this must not the right place to ask for help on such matters, >>> but if you guys could shed some light here, I'd really appreciate that. >>> >>> Well, if you're up to it, here's the situation: >>> >>> Looks like the module compilation worked (no errors or warnings occurred >>> when I followed the instructions at the centos wiki), but I'm unable to >>> load the new module to my running kernel. >>> >> >> If you're building a new kernel, you should really give it a new name and >> fully install it as a distinct kernel. The safest way to do this is to work >> from the SRPM, put the patch in *there* and update the "Release:" >> number in the kenrel.spec file This will avoid precisely the issues you >> described. >> >> Do you need a walkt hrough on rebuilding a package from SRPM's? >> >> >>> I even copied the compiled and patched module to >>> /lib/modules/2.6.32-279.19.1.el6.x86_64/kernel/drivers/block/ (overwrote >>> the original) and /lib/modules/2.6.32-279.19.1.el6.x86_64/extra and >>> rebooted the instance... >>> >>> Also, dmesg does not complain about a thing... >>> >>> *# modinfo >>> /lib/modules/2.6.32-279.19.1.el6.x86_64/kernel/drivers/block/xen-blkfront.ko >>> * >>> *filename: >>> /lib/modules/2.6.32-279.19.1.el6.x86_64/kernel/drivers/block/xen-blkfront.ko >>> * >>> *alias: xenblk* >>> *alias: xen:vbd* >>> *alias: block-major-202-** >>> *license: GPL* >>> *description: Xen virtual block device frontend* >>> *srcversion: B00B4183E470515A96DA320* >>> *depends: * >>> *vermagic: 2.6.32-279.19.1.el6.x86_64 SMP mod_unload modversions * >>> *parm: sda_is_xvda:sdX in guest config translates to xvdX, >>> not xvd(X+4) (bool)* >>> * >>> * >>> *# uname -r* >>> *2.6.32-279.19.1.el6.x86_64* >>> >>> I also tried to remove the module and insert the patched one with >>> insmod, but modprobe and rmmod are unable to unload it. They say it's in >>> use. >>> >>> *# lsmod |grep blkfront* >>> *xen_blkfront 15495 1 * >>> >>> I don't know what this "1" stands for, but if I were to guess, I'd say >>> it's something unremovable... >>> >>> Please let me know if you need any other information. >>> >>> Thanks, >>> >>> >>> >>> >>> >>> Luis Alen >>> www.izap.com.br >>> Ligue com tarifa local de todo o Brasil 4020.3000 >>> >>> >>> >>> On Tue, Jan 15, 2013 at 4:13 PM, Andy Grimm <agrimm at gmail.com> wrote: >>> >>>> See https://bugzilla.redhat.com/show_bug.cgi?id=729586 >>>> >>>> On Tue, Jan 15, 2013 at 1:10 PM, Luis Fernando Alen < >>>> luis.alen at izap.com.br> wrote: >>>> >>>>> Hello, list. >>>>> >>>>> Yesterday I was pleased to see that Centos has released official >>>>> images at the aws marketplace. Nice job. >>>>> >>>>> Today I started playing with the Centos 6.3 image ( >>>>> https://aws.amazon.com/marketplace/pp/B00A6L6F9I, on which I plan to >>>>> deploy a gluster cluster in production soon) and noticed a weird thing. >>>>> >>>>> EBS Volumes attached to sd<X> are translated to xvd<Y> at the OS >>>>> level. However, after a few research and IRC chat, I figured out that it's >>>>> not weird, it's actually a normal and expected behavior (thanks for your >>>>> help, z00dax). >>>>> >>>>> sdX is actually mapped to xvdX+4. There is a consistent offset of 4. >>>>> Suppose you attach an ebs volume to /dev/sdf. It'll be translated to xvdj >>>>> at the OS level. sdg to xvdk, sdh to xvdl and so on. >>>>> >>>>> Allright. After having figured the mystery out, it became easy to work >>>>> on automations that deal with ebs volumes and file systems, such as volumes >>>>> created, attached and mounted on the fly, snapshots that freeze file >>>>> systems and so on... >>>>> >>>>> However, I really do think to myself: Wouldn't it be cleaner if the >>>>> image use simple translation (sdX to xvdX)? If I'm not wrong, Rightscale >>>>> uses this on their Centos images and it's much simpler. There's no extra >>>>> work needed to deal with that 4 offset when you want to automate things. >>>>> >>>>> Is there a reasonable reason for the 4 offset which makes it >>>>> unchangeable? >>>>> >>>>> It's just a thought. I think it's worth considering it.. >>>>> >>>>> Luis Alen >>>>> www.izap.com.br >>>>> Ligue com tarifa local de todo o Brasil 4020.3000 >>>>> >>>>> >>>>> _______________________________________________ >>>>> CentOS-virt mailing list >>>>> CentOS-virt at centos.org >>>>> http://lists.centos.org/mailman/listinfo/centos-virt >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> CentOS-virt mailing list >>>> CentOS-virt at centos.org >>>> http://lists.centos.org/mailman/listinfo/centos-virt >>>> >>>> >>> >>> _______________________________________________ >>> CentOS-virt mailing list >>> CentOS-virt at centos.org >>> http://lists.centos.org/mailman/listinfo/centos-virt >>> >>> >> >> _______________________________________________ >> CentOS-virt mailing list >> CentOS-virt at centos.org >> http://lists.centos.org/mailman/listinfo/centos-virt >> >> > > _______________________________________________ > CentOS-virt mailing list > CentOS-virt at centos.org > http://lists.centos.org/mailman/listinfo/centos-virt > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-virt/attachments/20130116/68e86b63/attachment-0006.html>