A solution is needed for rare hardware which does not has a RTC chip. When init.d/clock tries to run hwclock on such hw, the system time gets screwed (it is set to 1943 something, possibly the -2^31 value of unixtime). In this state, Gentoo boots slowly and with warnings. In case that network is available, it SHOULD be used during the boot (critical service: clock). Reproducible: Always Steps to Reproduce: 1. Get an Ibm 8363 thin client (NetVista 2200), configure to netboot 2. Install gentoo on server to a dir, share it over NFS 3. Power on Actual Results: During the boot a lot of these warnings shows up: "One of the files in /etc/{conf.d,init.d} or /etc/rc.conf has a modification time in the future!". (it is from depscan.sh as it tries to calculate new order after each init script entry) Expected Results: Since this thin client is in a network and can reach other hosts (and the internet too) an NTP based clock initialization would be great. I solved the problem myself with these modifications: /etc/conf.d/clock TIMESERVER="tik.cesnet.cz" /etc/init.d/clock - in start() after the setupopts / before hwclock: if [[ -n ${TIMESERVER} ]]; then ebegin "Setting system clock using NTP [${TIMESERVER}]" ntpdate ${TIMESERVER} &>/dev/null eend $? return 0 fi .. but there is no error checking, it expects to have the network already running. In my network booting process this is guaranteed, because root fs is NFS. If this will be required from disk boot too, the user should compile in network drivers, kernel based auto-configuration and pass ip=dhcp or similar options, to have the net up at boot time. It would be great if the next round of baselayout will contain this functionality, either as I suggested, or in other way if you don't like my code / does not meet your quality requirements.
we already have ntp-client if you wish to use that ... if /dev/rtc is screwed, i think that's the realm of the kernel to have addressed
I used the ntp-client, but the messages are coming from the point after "critical services"* are all up (there is the first reordering in depscan) and they stop appearing as the ntp-client is started. That is only on the end of boot runlevel, so during that time there are 9x "Caching service dependencies" and each one takes ~ 5 secs to complete. From my POV, the dependency calculation is not clock-less proof (not sure if this is core or baselayout, init.d/clock belongs to baselayout ;) -- Another solution would be a rc.conf entry for a primary clock source: "clock"(default) vs. "ntp-client", and this setting could be appended to the critical services in sbin/rc*. Or some virtual thing that assures that the System clock is valid (and the hw/ntp could be the implementations) *) /sbin/rc: CRITICAL_SERVICES="checkroot modules checkfs localmount clock bootmisc"
This is probably fixed by baselayout-2 as the clock service by default now starts first and avoids the clock skew reported.
(In reply to comment #3) > This is probably fixed by baselayout-2 as the clock service by default now > starts first and avoids the clock skew reported. I had some free time and tested baselayout-2. Unfortunately, it does not fix the problem, because my machine has no RTC chip and the time gets initialized to -2^31. In this state, the whole baselayout "fails" - as it ultimately depends on a working system clock (for dependency cache). By "fails" I mean redundant cache regeneration. To get an idea what is the state on the machine few seconds after boot: $ ssh root@ibm8363 Password: ibm8363 ~ # date Fri Feb 5 18:23:25 CET 1943 ibm8363 ~ # ntpdate tik.cesnet.cz 17 Jul 22:26:44 ntpdate[1105]: step time server 195.113.144.201 offset 2033694186.083542 sec ibm8363 ~ # date Tue Jul 17 22:26:47 CEST 2007 As you can see, the system time (seconds since from 1970) is a negative number. I see some workarounds for virtualization in init.d/clock (fakeit=1) where the time coming from kernel is already a valid time. My problem however is that I need to initialize the time from external source (ntp) at boot time, during init.d/clock's start(). BTW: baselayout-2's start-stop-daemon does not like such negative system time. It makes this kind of output: * Starting sshd ... * clock_gettime: Invalid argument [!!] * ERROR: sshd failed to start Same for cron, portmap, nfs.. but all the services are running. If you understand, feel free to change this bug to feature request / close it, as it won't affect others users, probably I am the only one who owns a machine without any RTC chip.
daniel: I had similar problems on my embedded hardware (MyCable XXS1500). Change the kernel to init the RTC to something either at zero or slightly above it. And don't use hwclock ever on such hardware, i've got boxes that hard-lock if hwclock accesses it's normal registers.
Daniel, have you tried compiling your kernel without Enhanced Real Time Clock Support, ie. with CONFIG_RTC unset?
(In reply to comment #6) > Daniel, have you tried compiling your kernel without Enhanced Real Time Clock > Support, ie. with CONFIG_RTC unset? Yes, it already is that way: # CONFIG_RTC is not set Its linux-2.4.32-gentoo-r7 with some netvista 2200 patches which won't convert to 2.6 (to support the strange bootloader in that machine) The RTC-less kernel is not a problem, it works well and the time gets set from NTP. Just that it should happen sooner (in init.d/clock) - before the first dependency scan occurs in the rc scripts.
I guess /dev/rtc does not exist then. Can you confirm? Please post output of "hwclock --debug"
(In reply to comment #8) > I guess /dev/rtc does not exist then. Can you confirm? Yep, there is no /dev/rtc (I have devfs) > Please post output of "hwclock --debug" ibm8363 ~ # hwclock --debug hwclock from util-linux-2.12r hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. Using direct I/O instructions to ISA clock. Last drift adjustment done at 0 seconds after 1969 Last calibration done at 0 seconds after 1969 Hardware clock is on unknown time Assuming hardware clock is kept in local time. Waiting for clock tick... ...got clock tick There is about two seconds pause between last two lines. /etc/adjtime contains 0.0 0 0.0.
Is that really the full output? If so, next please show the output of: hwclock --debug --systohc hwclock --debug
Yes, it is the whole output, the 2 requested commands show: ibm8363 ~ # date # previously set by NTP Sun Jul 22 17:16:12 CEST 2007 ibm8363 ~ # hwclock --debug --systohc hwclock from util-linux-2.12r hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. Using direct I/O instructions to ISA clock. Last drift adjustment done at 0 seconds after 1969 Last calibration done at 0 seconds after 1969 Hardware clock is on unknown time Assuming hardware clock is kept in local time. Waiting for clock tick... ...got clock tick ibm8363 ~ # hwclock --debug hwclock from util-linux-2.12r hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. Using direct I/O instructions to ISA clock. Last drift adjustment done at 0 seconds after 1969 Last calibration done at 0 seconds after 1969 Hardware clock is on unknown time Assuming hardware clock is kept in local time. Waiting for clock tick... ...got clock tick ibm8363 ~ # date Sun Jul 22 17:16:43 CEST 2007 (hwclock is util-linux package, it has no debug use flag option, that is the most I can supply)
This is not a kernel issue: the reporter claims that the device has no clock chip, hence /dev/rtc is never available, and hwclock falls back to ISA-style clock manipulation, which also fails because there is no clock at all. So, I believe this enhancement request still stands: the user would like something like ntp-client available to set the clock using network much earlier in boot.
then the answer is wait for baselayout-2 and in the meantime, remove hwclock from your rc level and critical services
