Red Hat Bugzilla – Bug 215664
ksign mismatch GPG key for signed kernel modules
Last modified: 2007-11-30 17:11:49 EST
Description of problem: kernel 2.6.18-1.2849.fc6 installs public key D40D77874EB40D76 but the modules are signed with key 4d36eef71c3a3150 so signed modules fail to load. Version-Release number of selected component (if applicable): kernel-2.6.18-1.2849.fc6 How reproducible: Always Steps to Reproduce: 1. boot 2.6.18-1.2849.fc6 2. 3. Actual results: signed kernel modules fail to load because the loaded key is different. Expected results: signed kernel modules succeed to load. Additional info: kernel-2.6.18-1.2798.fc6 succeeds on same root and machine. Will attach serial console logs from bad and good boots.
Created attachment 141211 [details] serial console log from .2849 (fails)
Created attachment 141212 [details] serial console log from .2798 (succeeds)
The last 6 modules which fail to load are ehci-hcd.ko, jbd.ko, ext3.ko, scsi_mod.ko, libata.ko, sata_nv.ko; 3 others have scrolled off the vga console. A typical message is "insmod: error inserting '/lib/jbd.ko': -1 Operation not permitted"; and that does not appear in the serial console log because it comes from insmod, not from the kernel. [Note that "modules/2.6.18-1.2849.fc6/" is missing from the filename. The files are in /lib/modules/2.6.18-1.2849.fc6/... ]
that's really bizarre. objdump -s .module_sig /lib/modules/2.6.18-1.2849.fc6/kernel/drivers/scsi/libata.ko shows me ... Contents of section .module_sig: 0000 883f0305 004554bc 80d40d77 874eb40d .?...ET....w.N.. 0010 76110274 18009f5e c64eae0a 0e14c87b v..t...^.N.....{ 0020 7dd1626e acf5b1ee b44bdb00 9f489259 }.bn.....K...H.Y 0030 3cee007f f90f04d5 d27aff78 895c708d <........z.x.\p. 0040 5c which shows it clearly has the right key. Can you confirm your on-disk modules are the same ? It's really unusual that you're the only person to have hit this. If the signs were bad, it would break for everyone.
Operator error [egg on face]: the old initrd was loaded with the new kernel. The missing "modules/2.6.18-1.2849.fc6/" in "/lib/jbd.ko" is even a clue that the module was being loaded from initrd and not from the regular on-disk root filesystem directory. I had help in not seeing the forest for the trees. There was no message containing the word 'initrd', no explicit warning for initrd not matching the kernel, no name of the initrd in the log. How I erred: The box boots multiple versions of Fedora Core and RHEL from different root filesystems. A common boot partition containing kernels and initrds from all systems has problems because SELinux attributes are incompatible between different systems. A common /boot also tends to accumulate stale files as partitions are erased and re-used. So although I do have a boot partition that contains GRUB itself and a master grub.conf, each kernel and initrd lives in its respective root filesystem. /boot is always a regular directory, and not a mount point. This means that the GRUB changes from "yum update kernel" must be forwarded from the local grub.conf to the master grub.conf; the error occured in forwarding. Perhaps "double GRUB" would avoid this problem: The first GRUB just selects which root, and loads the second GRUB from the beginning of that partition, which then allows choosing only those kernels that reside on that particular root.