7

On a Debian server, I'm having problem with hwclock:

$ hwclock --show 
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --debug option to see the details of our search for an access method.

System runs on backports kernel Debian 4.9.18-1~bpo8+1 (2017-04-10).

Here's debug output:

$ hwclock --debug
hwclock from util-linux 2.25.2
hwclock: cannot open /dev/rtc: Device or resource busy
No usable clock interface found.
hwclock: Cannot access the Hardware Clock via any known method.

clocksource:

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Finally, rtc device exists:

$ ls -l /dev/rtc*
lrwxrwxrwx 1 root root      4 Apr 29 16:41 /dev/rtc -> rtc0
crw------- 1 root root 253, 0 Apr 29 16:41 /dev/rtc0
Tombart
  • 2,013
  • 3
  • 27
  • 47

3 Answers3

6

The problem seems to be connected to clocksource, check available_clocksource:

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

Based on answer to "What does “clocksource tsc unstable” mean?" it looks like TSC (Time Stamp Counter) is not very reliable.

By updating /etc/default/grub you can switch to another available clocksource. I'm using HPET.

GRUB_CMDLINE_LINUX_DEFAULT="clocksource=hpet"

and updating grub:

update-grub2

After reboot hwclock works again (just reboot without any modification might have helped as well - it might be just question for how long).

NOTE: Optimal clocksource might depend on your motherboard and CPU model.

Tombart
  • 2,013
  • 3
  • 27
  • 47
1

For me, the fix was just to type "sudo" before the command, as the "can't access" actually means it doesn't have perms to access /dev/rtcX. Running it with sudo fixed it by giving it root perms. Your solution would be just to run sudo hwclock --show instead of hwclock --show

Red050911
  • 11
  • 1
-3

run on a virtual machine.

su - //afswitch root.run hwclock

feko
  • 1