As far as I can tell the unknown module key isn't a problem, but I get a number of warnings for it during boot. Is there really a problem here? If there isn't, can these be suppressed?
Here is an example warning: Nov 12 00:03:43 bruno kernel: [ 40.835401] Request for unknown module key 'Fedora kernel signing key: 2f230f4662d4290a932538bd964f802eaa42f49a' err -11
On Wed, Nov 14, 2012 at 01:11:05PM -0600, Bruno Wolff III wrote:
As far as I can tell the unknown module key isn't a problem, but I get a number of warnings for it during boot. Is there really a problem here? If there isn't, can these be suppressed?
Here is an example warning: Nov 12 00:03:43 bruno kernel: [ 40.835401] Request for unknown module key 'Fedora kernel signing key: 2f230f4662d4290a932538bd964f802eaa42f49a' err -11
Are you loading modules from one kernel build into a different kernel build? That is basically saying "the key this module is signed with isn't in the kernel's keyring". But that specific key looks like the one that should be built into the kernel during build, so it should be there. Or you're doing what I asked earlier, which would be odd.
Post dmesg output please.
josh
On Wed, Nov 14, 2012 at 14:16:59 -0500, Josh Boyer jwboyer@redhat.com wrote:
Are you loading modules from one kernel build into a different kernel build? That is basically saying "the key this module is signed with isn't in the kernel's keyring". But that specific key looks like the one that should be built into the kernel during build, so it should be there. Or you're doing what I asked earlier, which would be odd.
I don't belive so. I create a new package for the dahdi-linux package for each kernel version. I also get multiple warnings each boot and dahdi-linux is the only module I build locally.
Post dmesg output please.
Attached.
On Wed, Nov 14, 2012 at 01:26:06PM -0600, Bruno Wolff III wrote:
On Wed, Nov 14, 2012 at 14:16:59 -0500, Josh Boyer jwboyer@redhat.com wrote:
Are you loading modules from one kernel build into a different kernel build? That is basically saying "the key this module is signed with isn't in the kernel's keyring". But that specific key looks like the one that should be built into the kernel during build, so it should be there. Or you're doing what I asked earlier, which would be odd.
I don't belive so. I create a new package for the dahdi-linux package for each kernel version. I also get multiple warnings each boot and dahdi-linux is the only module I build locally.
Post dmesg output please.
Attached.
[ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 3.7.0-0.rc5.git0.2.fc19.i686.PAE (mockbuild@) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Mon Nov 12 00:08:40 UTC 2012
You rebuilt your kernel? Or where did you get this? That build isn't in koji.
[ 1.585098] Loading module verification certificates [ 1.591334] MODSIGN: Loaded cert 'Fedora kernel signing key: 0f1c4e72b9f2048a386af55c6c935cbd11d4be3c'
This is the key that is built into the kernel you have, and it's successfully loaded.
[ 37.820234] Request for unknown module key 'Fedora kernel signing key: 2f230f4662d4290a932538bd964f802eaa42f49a' err -11
That is the key the modules you have are signed with. Clearly not the same key.
So either something is resigning all the modules you have for this kernel, or you have modules from a different kernel in this kernel's location, or something similarly weird.
I don't see any similar issues using the latest rawhide build in a VM, so this is very curious. Is the dahdi-linux rebuild doing signing?
josh
On Wed, Nov 14, 2012 at 15:04:51 -0500, Josh Boyer jwboyer@redhat.com wrote:
[ 0.000000] Linux version 3.7.0-0.rc5.git0.2.fc19.i686.PAE (mockbuild@) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Mon Nov 12 00:08:40 UTC 2012
You rebuilt your kernel? Or where did you get this? That build isn't in koji.
That one is from the new no-debug repo. I was seeing the same bug with ones from the normal rawhide repo as well.
I don't see any similar issues using the latest rawhide build in a VM, so this is very curious. Is the dahdi-linux rebuild doing signing?
Not that I am aware of. The build script pre-dates the signing stuff. I'll try a plain rawhide kernel without the dahdi module and see if I see those warnings. If not I'll also retest with a rebuilt dahdi-linux and see if they still show up. I can't do remote reboots, so I won't be able to test this until tonight.
On Wed, Nov 14, 2012 at 03:25:23PM -0600, Bruno Wolff III wrote:
On Wed, Nov 14, 2012 at 15:04:51 -0500, Josh Boyer jwboyer@redhat.com wrote:
[ 0.000000] Linux version 3.7.0-0.rc5.git0.2.fc19.i686.PAE (mockbuild@) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Mon Nov 12 00:08:40 UTC 2012
You rebuilt your kernel? Or where did you get this? That build isn't in koji.
That one is from the new no-debug repo. I was seeing the same bug with ones from the normal rawhide repo as well.
I don't see any similar issues using the latest rawhide build in a VM, so this is very curious. Is the dahdi-linux rebuild doing signing?
Not that I am aware of. The build script pre-dates the signing stuff. I'll try a plain rawhide kernel without the dahdi module and see if I see those warnings. If not I'll also retest with a rebuilt dahdi-linux and see if they still show up. I can't do remote reboots, so I won't be able to test this until tonight.
Ugh. Don't bother. It isn't dahdi-linux doing it.
I looked closer and noticed you're using the PAE kernel, so I grabbed that locally and booted it and saw the same problem. The issue is that the modules for the PAE kernel are getting signed by the normal i686 kernel key. The i686 kernel+modules are fine.
I'll look at this more tonight and see if I can't get it fixed.
josh
On Wed, Nov 14, 2012 at 05:58:37PM -0500, Josh Boyer wrote:
On Wed, Nov 14, 2012 at 03:25:23PM -0600, Bruno Wolff III wrote:
On Wed, Nov 14, 2012 at 15:04:51 -0500, Josh Boyer jwboyer@redhat.com wrote:
[ 0.000000] Linux version 3.7.0-0.rc5.git0.2.fc19.i686.PAE (mockbuild@) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Mon Nov 12 00:08:40 UTC 2012
You rebuilt your kernel? Or where did you get this? That build isn't in koji.
That one is from the new no-debug repo. I was seeing the same bug with ones from the normal rawhide repo as well.
I don't see any similar issues using the latest rawhide build in a VM, so this is very curious. Is the dahdi-linux rebuild doing signing?
Not that I am aware of. The build script pre-dates the signing stuff. I'll try a plain rawhide kernel without the dahdi module and see if I see those warnings. If not I'll also retest with a rebuilt dahdi-linux and see if they still show up. I can't do remote reboots, so I won't be able to test this until tonight.
Ugh. Don't bother. It isn't dahdi-linux doing it.
I looked closer and noticed you're using the PAE kernel, so I grabbed that locally and booted it and saw the same problem. The issue is that the modules for the PAE kernel are getting signed by the normal i686 kernel key. The i686 kernel+modules are fine.
I'll look at this more tonight and see if I can't get it fixed.
OK. I think I fixed this in F18/rawhide. I started another build for rawhide with the fix included, but I'm not sure if it will make the compose for tomorrow's repo.
I'm on PTO tomorrow, so if it isn't fixed for some reason just let me know and I'll get back to it first thing.
josh
On Wed, Nov 14, 2012 at 21:58:37 -0500, Josh Boyer jwboyer@redhat.com wrote:
OK. I think I fixed this in F18/rawhide. I started another build for rawhide with the fix included, but I'm not sure if it will make the compose for tomorrow's repo.
The release name you picked conflicted with the current nodebug kernel. Maybe the nodebug repository should add a string suggesting nodebug to their kernels instead of bumping the release number?
I may not get done testing tonight as I got to get to sleep soon. But I'll let you know when I get the new build tested.
On Wed, Nov 14, 2012 at 22:30:07 -0600, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Nov 14, 2012 at 21:58:37 -0500, Josh Boyer jwboyer@redhat.com wrote:
OK. I think I fixed this in F18/rawhide. I started another build for rawhide with the fix included, but I'm not sure if it will make the compose for tomorrow's repo.
The release name you picked conflicted with the current nodebug kernel. Maybe the nodebug repository should add a string suggesting nodebug to their kernels instead of bumping the release number?
I may not get done testing tonight as I got to get to sleep soon. But I'll let you know when I get the new build tested.
I have tried this both with and without dahdi-linux and I am not seeing the warning messages any more. Thanks.
On Fri, Nov 16, 2012 at 07:34:35AM -0600, Bruno Wolff III wrote:
On Wed, Nov 14, 2012 at 22:30:07 -0600, Bruno Wolff III bruno@wolff.to wrote:
On Wed, Nov 14, 2012 at 21:58:37 -0500, Josh Boyer jwboyer@redhat.com wrote:
OK. I think I fixed this in F18/rawhide. I started another build for rawhide with the fix included, but I'm not sure if it will make the compose for tomorrow's repo.
The release name you picked conflicted with the current nodebug kernel. Maybe the nodebug repository should add a string suggesting nodebug to their kernels instead of bumping the release number?
I may not get done testing tonight as I got to get to sleep soon. But I'll let you know when I get the new build tested.
I have tried this both with and without dahdi-linux and I am not seeing the warning messages any more. Thanks.
Great. Thank you for reporting and testing!
I find it somewhat telling on the state of 32-bit kernel usage in both rawhide and F18 that nobody noticed this for so long. It's been broken for a while. Scary.
josh
kernel@lists.fedoraproject.org