> On Mar 8, 2018, at 10:57 PM, Charles E. Blair <c-bl...@illinois.edu> wrote: > > I have been getting messages > >> superblock mount time in future, >> probably due to hardware clock >> incorrectly set. > > I tried using hwclock to > fix this, but don't know what I'm > doing. I created the batch file: > > date > datetest > hwclock >> datetest > > and ran it to get the output: > > Fri Mar 9 00:49:11 CST 2018 > 2018-03-09 00:49:58.592967-0600 > > Any advice on a simple fix > is welcome.
There are (at least) two clocks in a Debian system. The first is the “hardware clock”, which keeps time independent of whatever software is running on the computer. It has a small battery that keeps it running even when the machine is powered down. Think of it as a digital wristwatch that the computer can read. When you run the “hwclock” command, it reads the hardware clock and reports on what it read. The second is the “system clock”, which is a software construct that is updated by the OS based on periodic interrupts. When you run the “date” command, it reads the system clock and reports on what it read. When the system boots, Debian reads the hardware clock and uses it to set the system clock. When the system shuts down, the OS reads the system clock and writes it to the hardware clock for safe keeping until the next reboot. In most Debian systems, the hardware clock is set to the UTC (Co-ordinated Universal Time) timezone, as is the system clock. The “date” and “hwclock” commands covert to the local system timezone for printing. They each tell you what timezone they are using but they use a different notation. “date” gives the 3-char abbreviation (in your case “CST” = US Central Standard Time). “hwclock” gives the timezone as hours offset from UTC (in your case, also CST because CST is 6 hours off from UTC). As Michael pointed out, your hardware clock could be set to the local timezone (this is normal for a Windows/Debian dual-boot situation). The /etc/adjtime file has a flag that tells whether the hardware clock is set to local or UTC timezone. If everything is working according to specs, this should *not* cause the problem you are seeing. But the very fact that you are having this problem shows that everything is not working according to specs. Based on your experiment, we can say that your hardware clock is running about 47 seconds ahead of your system clock. This can be corrected by running the command (as root) “hwclock ––systohc”. If that gets rid of your problem, great! If not, or if it goes away for a while then returns, your hardware clock may be drifting (i.e. running faster or slower than real time). In that case, you will need to do “hwclock ––systohc ––update-drift” a few times each a day or two apart. If you have Internet access, you should probably install the “ntp” package, which will keep your system clock synchronized to standard time from your local national standards agency. Also, read the hwclock(8) man page. It will tell you all the details that I’m sliding over here. Hope it helps! Rick
