Description of problem: kernel 2.6.17-1.2318_FC6 (i386) panics (see didicam picture) Version-Release number of selected component (if applicable): 2.6.17-1.2318_FC6 How reproducible: install kernel 2.6.17-1.2318_FC6 Steps to Reproduce: 1. reboot 2. 3. Actual results: panic Expected results: ... Additional info: no diffs in initrd's (2.6.17-1.2307, 2.6.17-1.2318) machine amd k8, chipset via K8T800Pro could i debug this / provide more info ?
Created attachment 131599 [details] digicam picture kernel panic
On x86_64 machine I am seeing this with 2.6.17-1.2318_FC6: ..... switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! Call Trace: <ffffffff8026e86e>{dump_stack+18} <ffffffff8028ffbe>{panic+134} <ffffffff80215555>{do_exit+141} <ffffffff8024c1a2>{debug_mutex_init+0} [<000000000053d678>] and a power switch is the only way out.
The signed modules code is broken. For some reason the modules end up signed with a different key than the one we use at build time.
*** Bug 196905 has been marked as a duplicate of this bug. ***
*** Bug 197014 has been marked as a duplicate of this bug. ***
further datapoint: The FC6 kernel recompiled on FC5 also exhibits this problem, ruling out any toolchain/gpg issues. For now I'm disabling the signed modules patch in tomorrows rawhide. Leave this bug open, as the patch needs fixing at some point.
Created attachment 131747 [details] output from kernel 2.6.17-1.2328.fc6
it means ... from kernel (not enough sleep last night) last line i could see was starting udev.... ... (see digicam picture) .... P.S. - 2328.fc6 ^^^ (tricky ?) "- Disable the signed module patches for now, they need love." i can't love it ....
Just for curiosity, what are the implications (orther than a new way to screw up releases :-) of signed modules? If I build my own kernel modules, will I be unable to load them? If I can build a module that will load anyway, wht is the point of signed modules, since a hacker to do the same thing (I presume the idea is to prevent hackers from installing bogus modules)?
2.6.17-1.2336.fc6 boot & works !
*** Bug 197071 has been marked as a duplicate of this bug. ***
This appears to be due to the dia_update() crypto op changing its prototype, so that the calculation buffer appears displaced from where it ought to be in sha1_update().
should this bug not be closed ? for me it is gone since 2.6.17-1.2336.fc6 and we are now at 2.6.17-1.2510.fc6. sorry - i am not a kernel developer -, but maybe you spent a lot of time on "old" stuff... my "pains" are now at Bugzilla Bug 200638. thx.
> should this bug not be closed ? No, not yet. The fix is not yet applied - module signing is currently disabled.
Should be fixed in todays rawhide.