>
> On Mon, Oct 15, 2012 at 9:18 AM, <John.Florian@xxxxxxxx> wrote:
> >> Post the full dmesg output of the boot. There should be a section in
> >> there about loading the module signing key with a key listed. If that
> >> didn't succeed, it will produce that error message when a module is
> >> loaded, but it will still load.
> >
> > Okay, the entire dmesg output follows, but given what you just said, I
> > suspect this is the important bit:
> >
> > [ 3.643056] MODSIGN: Problem loading in-kernel X.509 certificate (-129)
>
> Actually, the important bit is the few lines above that:
>
> > [ 3.591826] Loading module verification certificates
> > [ 3.601372] Cert Valid From: 2012-10-08 16:52:26
> > [ 3.610300] Cert Valid To: 2112-09-14 16:52:26
> > [ 3.618967] Now: 2003-01-01 00:02:42
> > [ 3.626830] X.509: Cert c6fb6e1f2b79b50ab078f4d6b9fc9b2204a692a7 is not
> > yet valid
> > [ 3.643056] MODSIGN: Problem loading in-kernel X.509 certificate (-129)
> > [ 3.654414] registered taskstats version 1
> > [ 3.664906] Magic number: 3:0:0
> > [ 3.673116] rtc_cmos 00:04: setting system clock to 2003-01-01 00:02:44
> > UTC (1041379364)
>
> Your RTC thinks it's 2003. Why it does, I have no idea but that is the
> problem. The cert embedded in the kernel is valid from the dates
> listed and since your machine is telling the kernel we're back in the
> past it won't load.
>
> If you can get your machine to join us in this decade, the message
> should go away. If for some reason it really just wants to stay in
> 2003, the error message is just irritating. Nothing is going to be
> prevented from working.
Oh, well that seems obvious now. I'm not sure how I missed that; likely I'm overly dependent on grep. Thank you for the detailed explanation.
The RTC issue is a long standing one I've fought for some time with little success. I have a large number of PC/104 class systems that refuse to have their hardware clock become sync'd with the kernel's clock, despite variously using ntpd, chronyd, custom calls to hwclock and the stuff in the old initscripts. I've not yet looked into how systemd has replaced those parts that were in initscripts. While most of these systems never get shutdown properly -- their deployed design requirement is to simply be powered off -- I've come to believe the problem is somehow buggy hardware, although *some* units of the same make/model do sync. Sigh! :-(
--
John Florian
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
