You are not logged in.
Thank you.
My current remedy is the following. Create a file /etc/elogind/system-sleep/ntp.sh
with the following contents:
#!/bin/sh
case $1 in
pre)
/etc/init.d/ntpsec stop
/bin/sleep 1
;;
post)
/usr/sbin/ntpd -gq
/etc/init.d/ntpsec start
;;
esac
This seems to set the correct time on resume.
BTW I believe this problem is related to this particular hardware and not to devuan. I have 8 machines with different hardware at home, all running the same system, and this one is the only machine that cannot set/update the hardware clock. I am just not sure how debian managed to work around this.
Does the board have a separate coin cell battery? Put a new one in if it does. CR2032 is the most common.
TC
Thanks. I could but not sure this will fix the problem. I can see that the BIOS is keeping the time correctly. I unplugged it from the wall outlet for a night, and it had a correct UTC time in the BIOS when it booted in the morning.
Greetings,
I have a chimaera system which I updated to testing. It is running a linux-image-6.1.0-9-amd64 kernel. This is a fairly old machine with i3-4130T cpu and asrock tx-97x board. I always suspected that the board was somewhat defective. I had to tweak a lot of things in the BIOS to get it running without locking up randomly.
I noticed that system time is off after resume, it is usually set to the time when the machine suspended. I think I traced this to it being unable to read the hardware clock:
# hwclock --get --directisa
# hwclock --get
hwclock: select() to /dev/rtc0 to wait for clock tick timed out
# cat /proc/interrupts|grep -i rtc
8: 0 0 0 0 IO-APIC 8-edge rtc0
The first command simply exits, and the second one gives a select() error. I am guessing select() system call is waiting for an rtc interrupt which it never receives.
This machine used to run debian with the same kernel, and the time was set correctly after a resume. I don't know if hwclock command could read the rtc because I had no reason to investigate.
So I have two questions;
(1) Any ideas about the time problem above?
(2) Does elogind support suspend/resume hooks as described here: https://wiki.gentoo.org/wiki/Elogind#Su … ok_scripts and if yes, what is the location of those scripts? This would allow me to use ntpdate on resume to set a correct clock, and to restart ntpd, which at the moment refuses to function with such a large clock drift.
Thanks.
Thanks.
I think something starts dhclient if I have
allow-hotplug eth0
iface eth0 inet dhcp
in /etc/network/interfaces, I am guessing one of init scripts runs ifup which starts dhclient.
Removing the runit service prevents dhclient from starting twice.
I think I found the problem a few minutes after posting. Apparently the system starts dhclient when I have what I have in /etc/network/interfaces; however there is a dhclient service (under runit) in /etc/service. After I removed it, things went back to normal.
I ran into a problem after installing on all four of my machines that I converted from debian, would appreciate some advice.
I installed Chimaera from a cdrom, and updated to testing. I chose to use runit as init. This is /etc/apt/sources.list that I used:
deb http://deb.devuan.org/merged testing main contrib non-free
deb-src http://deb.devuan.org/merged testing main contrib non-free
then I ran apt-get update; apt-get dist-upgrade.
I don't use NetworkManager which is disabled (chmod 644 /etc/init.d/network-manager - this took a mental effort after many years on systemd :) ). The /etc/network/interfaces file has
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp
root@kot:/home/user# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 70:85:c2:74:eb:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 84535sec preferred_lft 84535sec
inet6 fe80::7285:c2ff:fe74:eb5d/64 scope link
valid_lft forever preferred_lft forever
You can see that the interface is up with a valid IP, but
syslog is filling up with messages from dhclient:
2023-05-18T20:29:53.150541-05:00 kot dhclient[23535]: Failed to get interface index: No such device
2023-05-18T20:29:53.150548-05:00 kot dhclient[23535]:
2023-05-18T20:29:53.150551-05:00 kot dhclient[23535]: If you think you have received this message due to a bug rather
2023-05-18T20:29:53.150554-05:00 kot dhclient[23535]: than a configuration issue please read the section on submitting
2023-05-18T20:29:53.150557-05:00 kot dhclient[23535]: bugs on either our web page at www.isc.org or in the README file
2023-05-18T20:29:53.150560-05:00 kot dhclient[23535]: before submitting a bug. These pages explain the proper
2023-05-18T20:29:53.150563-05:00 kot dhclient[23535]: process and the information we find helpful for debugging.
2023-05-18T20:29:53.150566-05:00 kot dhclient[23535]:
2023-05-18T20:29:53.150569-05:00 kot dhclient[23535]: exiting.
(also, the strange thing is that /var/log/syslog was rotated to syslog.1 but /var/log/syslog is now empty, and the log continues to go into syslog.1).
If anyone knows what could be the problem, either with the logger or dhclient, please post, thanks.