On Mon, Apr 23, 2012 at 01:34:04PM -0600, Jerry James wrote: > I haven't been able to boot the last 3 Rawhide kernels, > kernel-3.4.0-0.rc3.gitX.1.fc18.x86_64, where X = 2, 3, 4. The kernel > with X = 1 boots fine. When I try to boot the other 3, I get dropped > into a debug shell with dracut complaining about being unable to find > various devices. Today I got around to trying to figure out why. > Manually running "new-kernel-pkg --package kernel --mkinitrd --dracut > --depmod --update 3.4.0-0.rc3.git4.1.fc18.x86_64" spewed a large > number of lines like this: > > WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/psnap.ko > needs unknown symbol llc_sap_close > WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/psnap.ko > needs unknown symbol llc_sap_open > WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/stp.ko > needs unknown symbol llc_sap_close > WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/stp.ko > needs unknown symbol llc_sap_open > WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/802/garp.ko > needs unknown symbol llc_mac_hdr_init > WARNING: /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/kernel/net/bridge/bridge.ko > needs unknown symbol llc_mac_hdr_init > > In the working kernel (X = 1), these symbols are provided by > /lib/modules/3.4.0-0.rc3.git1.1.fc18.x86_64/kernel/net/llc/llc.ko. On > the broken kernels, the llc directory is still there, but it is empty. > What happened to the llc module? The pps_core module > (kernel/drivers/pps/pps_core.ko) has also gone missing in the more > recent kernels, accounting for still more unknown symbols. I ran "rpm > -V" on the recent kernel packages and just got the expected: > > .......T. /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/modules.devname > .......T. /lib/modules/3.4.0-0.rc3.git4.1.fc18.x86_64/modules.softdep > > Have I done something wrong, or are the recent kernels busted? I built libguestfs today, which as part of the Koji build will boot and run the current kernel. It *didn't* fail, indicating that the kernel is good. Here are the build logs if you want to look further: http://kojipkgs.fedoraproject.org/packages/libguestfs/1.17.33/1.fc18/data/logs/x86_64/ (It might just be a problem confined to 802.x and bridge devices, which we don't test.) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
