| 1 |
Am 06.02.2012 19:39, schrieb meino.cramer@×××.de: |
| 2 |
> Michael Mol <mikemol@×××××.com> [12-02-06 19:20]: |
| 3 |
>> On Mon, Feb 6, 2012 at 12:51 PM, <meino.cramer@×××.de> wrote: |
| 4 |
>>> Hi, |
| 5 |
>>> |
| 6 |
>>> to get the correct system time I use ntp-client in the boot process. |
| 7 |
>>> Furthermore in /etc/conf.d/hwclock I set: |
| 8 |
>>> |
| 9 |
>>> # Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also known as |
| 10 |
>>> # Greenwich Mean Time). If that clock is set to the local time, then |
| 11 |
>>> # set CLOCK to "local". Note that if you dual boot with Windows, then |
| 12 |
>>> # you should set it to "local". |
| 13 |
>>> clock="UTC" |
| 14 |
>>> |
| 15 |
>>> # If you want to set the Hardware Clock to the current System Time |
| 16 |
>>> # (software clock) during shutdown, then say "YES" here. |
| 17 |
>>> # You normally don't need to do this if you run a ntp daemon. |
| 18 |
>>> clock_systohc="YES" |
| 19 |
>>> |
| 20 |
>>> # If you want to set the system time to the current hardware clock |
| 21 |
>>> # during bootup, then say "YES" here. You do not need this if you are |
| 22 |
>>> # running a modern kernel with CONFIG_RTC_HCTOSYS set to y. |
| 23 |
>>> # Also, be aware that if you set this to "NO", the system time will |
| 24 |
>>> # never be saved to the hardware clock unless you set |
| 25 |
>>> # clock_systohc="YES" above. |
| 26 |
>>> clock_hctosys="NO" |
| 27 |
>>> |
| 28 |
>>> # If you wish to pass any other arguments to hwclock during bootup, |
| 29 |
>>> # you may do so here. Alpha users may wish to use --arc or --srm here. |
| 30 |
>>> clock_args="" |
| 31 |
>>> |
| 32 |
>>> In the kernel config file I had set: |
| 33 |
>>> |
| 34 |
>>> CONFIG_RTC_HCTOSYS=y |
| 35 |
>>> CONFIG_RTC_HCTOSYS_DEVICE="rtc0" |
| 36 |
>>> |
| 37 |
>>> I would exspect that after a reboot of the system which system time is |
| 38 |
>>> correctly set via ntp-client that the hwclock and system time only |
| 39 |
>>> differ in a small amount of time. |
| 40 |
>>> |
| 41 |
>>> But: |
| 42 |
>>> solfire:/home/mccramer>hwclock |
| 43 |
>>> Mon Feb 6 19:05:11 2012 -0.172569 seconds |
| 44 |
>>> solfire:/home/mccramer>date |
| 45 |
>>> Mon Feb 6 18:49:37 CET 2012 |
| 46 |
>>> solfire:/home/mccramer> |
| 47 |
>> |
| 48 |
>> I don't know the CET tz, but I can see that the minutes don't match |
| 49 |
>> up. I assume you rand the two commands within seconds of each other. |
| 50 |
>> Is this true immediately after bootup, or does it take a while to get |
| 51 |
>> that far off? It could be that your hardware clock is drifting, and |
| 52 |
>> the system won't reset it until it goes to shutdown. |
| 53 |
>> |
| 54 |
>> -- |
| 55 |
>> :wq |
| 56 |
>> |
| 57 |
> |
| 58 |
> Hi Michael, |
| 59 |
> thank you for your reply. |
| 60 |
> I set the configuration as mentioned above and booted twice with about |
| 61 |
> five minutes wait. |
| 62 |
> The commands were executed within seconds, yes. |
| 63 |
> All hardware clocks drifts, but this is not the problem. |
| 64 |
> The problem is that the hardware clock is not set to the system time |
| 65 |
> in contradiction to what I think the comments in the config are |
| 66 |
> saying. |
| 67 |
> |
| 68 |
> How can I fix that? |
| 69 |
> |
| 70 |
> Thank you very much in advance for any help! |
| 71 |
> Best regards, |
| 72 |
> mcc |
| 73 |
> |
| 74 |
> |
| 75 |
> |
| 76 |
|
| 77 |
Is your RTC driver compiled into the kernel? The "httosys" function of |
| 78 |
the kernel takes place before any modules can be loaded and will fail if |
| 79 |
your CMOS clock driver is a module. |
| 80 |
|
| 81 |
Activating clock_hctosys in /etc/conf.d/hwclock should solve this as it |
| 82 |
takes place later in the boot process. |
| 83 |
|
| 84 |
Regards, |
| 85 |
Florian Philipp |
Archives