[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Problems with TOD clock data on i386?
Hello. Probably a silly question, but is it safe to assume that the
kernel doesn't update the TOD clock since it can't read it? The only way I
can think to truly test this is to set the time in the BIOS to some time last
week, reboot, let ntpdate set the time, and then drop into BIOS again and
see if the clock is correct.
I'm guessing the BIOS will still show you the time you set the clock to
originally, plus the amount of time that passed between both BIOS sessions.
If it shows the current time, and you didn't boot into another OS between
BIOS sessions, then you're able to set the clock somehow, but can't read
it, which would be even stranger but which might be useful information to
On Jul 16, 1:20am, "John D. Baker" wrote:
} Subject: Re: Problems with TOD clock data on i386?
} On Mon, 16 Jul 2012, John D. Baker wrote:
} > While I'm using ntpd to synchronize the clock (with -g to force large
} > initial adjustment), this seems to come too late for PAM/kerberos to
} > synchronize with my KDC so my pam-enabled 'sudo' requires a local password
} > instead of accepting the realm password for the sudoer trying to
} > authenticate.
} > (This behavior appeared after the KDC changed addresses on my network,
} > but all addressing/name-resolution has been verified correct, so that
} > leads me to consider time offsets.)
} Sorry, I wasn't paying attention. My Kerberos issues are not related to
} timekeeping. I did more invasive upgrades to the machine that is my kdc
} and hosed the credential database.
} The issue of this host having trouble reading/deciphering the TOD clock
} |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
} |\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
} | X No HTML/proprietary data in email. BSD just sits there and works!
} |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
>-- End of excerpt from "John D. Baker"
Main Index |
Thread Index |