-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
В Sat, 31 Aug 2013 20:46:35 +0200
"Carlos E. R."
People that double boot, specially when the other system is Windows, who insists on the CMOS clock being localtime, often trash the adjtime file contents. As a result, the clock shifts several hours on every boot (maybe not an integer number of hours).
I do not understand what is to trash there. The first two lines are legacy that nobody relies upon anyway. What this thread is about is the third line which is never changed by hwclock itself unless you explicitly instruct it to do so.
The cure on those cases was to set the system clock manually, transfer contents to cmos clock, and then erase the adjtime file, in the knowledge that rebooting would set it up correctly.
I do not understand why you need to remove /etc/adjtime helps here. Either LOCAL/UTC was set correctly or not. If it was no correctly set then most likely because /etc/sysconfig/clock was not set correctly and it will be recreated with wrong value again.
Now instead I'll have (often it is me who guides these people) to tell them a procedure to recreate the file correctly, for people that do not even know if the cmos is running local or utc time or why that is important.
If people do not know whether they are running local or UTC, how are you going to trust their /etc/sysconfig/clock then? It is user decision in the first place, whether it is stored in /etc/sysconfig/clock or /etc/adjtime is not important. The right procedure to fix dual boot with Windows is to go to YaST and set local time instead of UTC. Which will store the correct value in /etc/adjtime. Where is the problem? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlIizRkACgkQR6LMutpd94yTMwCeIlMPzmS3Vlt7JnCSV23aXFJV cdcAn2BYanolCtoCzhNBlrkLi4DFj+1Q =nMDH -----END PGP SIGNATURE-----