https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c1 --- Comment #1 from jorge aires 2012-03-25 15:05:52 UTC --- Hardware clock is NOT set to UTC. Also while I do have dual booting, I did NOT boot to windows. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c2 --- Comment #2 from jorge aires 2012-03-28 01:08:58 UTC --- I've set the time correctly a number of times now, as root of course, and it is always reset to pre-dst after reboot. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c3 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aj@suse.com Resolution| |WORKSFORME --- Comment #3 from Dr. Werner Fink 2012-06-22 11:39:27 UTC --- (In reply to comment #1) Use UTC in CMOS clock as this is the international standard. Please note that every Linux kernel uses UTC within its system clock. The user space localtime is defined with /etc/localtime system wide or with the TZ variable for one user. If you really depend on local time in CMOS the initrd has to know about it otherwise the kernel has the wrong clock. If you're using local time in CMOS *you* have to correct the CMOS clock at DST switch. Compare with http://en.opensuse.org/SDB:Configuring_the_clock @Andreas: I'm not willingly to support local time in CMOS anymore. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c5 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #5 from Dr. Werner Fink 2012-06-22 14:04:24 UTC --- To be short: The clock of linux kernel has to be in UTC The linux kernel reads its initial clock value from CMOS If CMOS is not in UTC the kernel has to told about to be able to switch back to real UTC This is done before the root file system from the first disk is touched otherwise the file system is not in a clean state due wrong time stamps Last two points are done in the initial ram disk which is also used to check and mount the root file system and start the initial program (systemd/sysvinit) it might be technical and sounds complicated but this is how it is and if you run into trouble at installation time this has to be fixed in the installation routines -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |yast2-maintainers@suse.de |ovo.novell.com | -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c8 Jiří Suchomel changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|REOPENED |NEEDINFO InfoProvider| |jorge.adriano@gmail.com AssignedTo|yast2-maintainers@suse.de |jsuchome@suse.com --- Comment #8 from Jiří Suchomel 2012-06-26 13:56:38 UTC --- Don't you have YaST logs from that installation time? It sounds strange that mkinitrd call would be missing... -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c10 --- Comment #10 from jorge aires 2012-07-13 11:01:42 UTC --- Hi, sorry I had missed your previous post. Going to attach the logs. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c12 --- Comment #12 from jorge aires 2012-07-13 11:07:33 UTC --- I have no such thing as /etc/adjtime -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c13 --- Comment #13 from Dr. Werner Fink 2012-07-13 11:28:30 UTC --- (In reply to comment #12) For 12.1 you do not need this but for 12.2+ you do. You may also provide the outout of the comamnd zcat /boot/initrd | cpio -i --to-stdout etc/sysconfig/clock which should show id your initrd is uptodate and in sync with your /etc/sysconfig/clock on the disk. Beside this the two commands: md5sum /etc/localtime zcat /boot/initrd | cpio -i --to-stdout etc/localtime | md5sum should result into the same MD5 check sum. If not your system is broken by default. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c15 --- Comment #15 from Dr. Werner Fink 2012-07-13 11:55:57 UTC --- If you're really use localtime in CMOS then you should check the file /etc/localtime if it is valid for your time zone: for z in $(find /usr/share/zoneinfo/ -type f) ; do if cmp /etc/localtime $z &> /dev/null ; then echo $z break fi done Please note that your CMOS clock if in localtime has to have the correct DST time. That is if the Daylight Saving Time is ON you should have corrected the CMOS clock *before* you boot the system up. The same is true if the Daylight Saving Time is OFF you should have corrected the CMOS clock *before* you boot the system comes up. This because the CMOS clock does not know about Daylight Saving Time (DST). You should aware that the clock should be corrected *before* the file systems are checked and mounted to have valid time stamps in use. If you do not want switch the CMOS clock twice a year you should use UTC, the Universal Time Coordinated reference. Then all goes automatically. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c17 --- Comment #17 from jorge aires 2012-09-30 20:17:35 UTC --- Sorry just noticed your message. Well /etc/localtime is a binary for me. I don't have adjtime, I can create it with that content then. Right now in YaST -> Time and Date, the option saying HC set to UTC is _not_ ticked. Clock appears to have the correct date. Most probably I'll have to correct it when it changes. But again the problem was not me having to correct it. The problem was that it would auto-correct itself, at the appropriate time. Then I would reboot and it would be wrong. And then I would try to change it myself and it would be lost after each reboot. (I think this was with UTC on) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c19 --- Comment #19 from jorge aires 2012-10-29 11:18:13 UTC --- Also the report is marked as NEEDINFO but I honestly don't know what info is missing as I've tried to proved everything that was asked. Regarding Werner Fink's comment, I don't really _want_ to use localtime. I'm more than happy using whatever works. If only I know how to set it that way. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c21 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|jorge.adriano@gmail.com | --- Comment #21 from Andreas Jaeger 2012-10-29 11:50:28 UTC --- Let's reset the NEEDINFO since you don't know what information to provide. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c23 --- Comment #23 from Dr. Werner Fink 2012-10-29 12:36:44 UTC --- (In reply to comment #22)

Also note I have never touch the BIOS, and I'm guessing the default is UTC.

This guess could be wrong it may default to the local time of the factory or simply is the time burned into the flash CMOS + the time offset upto now. It is up on you to a) set the time in BIOS before booting the system or use b) command `date' to set the system time if not already done and then use the command `hwclock' with option `--utc' (or the third line of /etc/adjtime set to UTC) and the option `--systohc' to write the clock back into the BIOS. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c25 --- Comment #25 from jorge aires 2012-10-30 15:32:36 UTC --- (In reply to comment #23)

(In reply to comment #22)

...

Also note I have never touch the BIOS, and I'm guessing the default is UTC.

This guess could be wrong it may default to the local time of the factory or simply is the time burned into the flash CMOS + the time offset upto now. It is up on you to a) set the time in BIOS before booting the system or use b) command `date' to set the system time if not already done and then use the command `hwclock' with option `--utc' (or the third line of /etc/adjtime set to UTC) and the option `--systohc' to write the clock back into the BIOS.

Sorry, was away. * I made sure the system was set to UTC (first in yast, then also use). I used yast->time and I also use kwclock --utc and then confirmed it really was set to UTC with: zcat /boot/initrd | cpio -i --to-stdout etc/sysconfig/clock * I went to the BIOS and corrected the clock to UTC (which coincidently is also my localtime, being in Portugal). Booted and time was correct. THEN I wanted to check if changes to system time were preserved. So I changed the system time as root (+10 minutes). Rebooted. Changes were lost. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c27 Andreas Jaeger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|jorge.adriano@gmail.com | --- Comment #27 from Andreas Jaeger 2012-10-30 19:32:19 UTC --- Please remember to remove the NEEDINFO if you want others to look at this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c29 --- Comment #29 from Andreas Jaeger 2012-10-31 09:01:12 UTC --- Jorge, I removed the NEEDINFO - I just wanted to ask you to do it next time yourself. Once you provided the information, tick the box below the comment box. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c31 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|werner@suse.com |jorge.adriano@gmail.com --- Comment #31 from Dr. Werner Fink 2012-10-31 12:27:48 UTC --- This will lead to NEEDINFO for Jorge ;) ... OK ... let us check the real state of the CMOS clock, please provide the output of the commands tail -n 1 /etc/adjtime hwclock --show --debug then the output of the commands to check the initrd zcat /boot/initrd | \ cpio -i --quiet --to-stdout etc/sysconfig/clock | \ grep HWCLOCK grep HWCLOCK /etc/sysconfig/clock lsinitrd /boot/initrd | grep -E 'clock|adj|localtime' test -e /dev/shm/warpclock || echo no warpclock and final I'd like to test your user space setup, supposes your're using a bash a shell . /etc/sysconfig/clock echo $TIMEZONE cmp /etc/localtime /usr/share/zoneinfo/$TIMEZONE || echo wrong localtime TZ=UTC date TZ=$TIMEZONE date if your shell is a csh, then run eval setenv `sed -rn '/^TIMEZONE=/{s/=/ /p}' /etc/sysconfig/clock` instead of using the line starting with a dot. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c33 jorge aires changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|jorge.adriano@gmail.com | --- Comment #33 from jorge aires 2012-10-31 17:59:41 UTC --- (In reply to comment #31)

This will lead to NEEDINFO for Jorge ;)

OK! (done)

... OK ... let us check the real state of the CMOS clock, please provide the output of the commands

tail -n 1 /etc/adjtime

File doesn't exist.

hwclock --show --debug

hwclock from util-linux 2.20.1 Using /dev interface to clock. Assuming hardware clock is kept in UTC time. Waiting for clock tick... ...got clock tick Time read from Hardware Clock: 2012/10/31 17:47:47 Hw clock time : 2012/10/31 17:47:47 = 1351705667 seconds since 1969 Wed 31 Oct 2012 17:47:47 WET -0.266340 seconds

then the output of the commands to check the initrd

zcat /boot/initrd | \ cpio -i --quiet --to-stdout etc/sysconfig/clock | \ grep HWCLOCK grep HWCLOCK /etc/sysconfig/clock lsinitrd /boot/initrd | grep -E 'clock|adj|localtime' test -e /dev/shm/warpclock || echo no warpclock

HWCLOCK="-u" HWCLOCK="-u" etc/localtime etc/sysconfig/clock bin/warpclock boot/05-clock.sh no warpclock

and final I'd like to test your user space setup, supposes your're using a bash a shell

. /etc/sysconfig/clock echo $TIMEZONE cmp /etc/localtime /usr/share/zoneinfo/$TIMEZONE || echo wrong localtime TZ=UTC date TZ=$TIMEZONE date

Europe/Lisbon Wed Oct 31 17:50:12 UTC 2012 Wed Oct 31 17:50:12 WET 2012 Hope it helps! -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c35 --- Comment #35 from jorge aires 2012-11-05 15:20:20 UTC --- (In reply to comment #34)

(In reply to comment #33)

I do not see a problem from the side of initrd nor CMOS as CMOS as well as the kernels system clock are in UTC ... that is no DST switch here. Only the rules of /etc/localtime aka /usr/share/zoneinfo/Europe/Lisbon accordingly to DST could be broken simply as Europe/Lisbon ... beside DST ... is UTC±0.

On the other hand I don not know if with systemd the system time will be written back to hardware clock is not a nptd daemon is running in eleven minute mode but only a ntpdate was called.

Not sure if this matters, but just to make it clear, I have tried changing the time in multiple ways, not just ntpdate. The setting is always lost on reboot. I just tried (again) setting the clock, this time using the KDE clock interface. Accepted the root password and the time was set. Rebooted. All was lost.

I guess it won't. Also old systemv boot script /etc/init.d/boot.clock was disabled (not by me and also removed in factory now) there is no way to use this together with FORCE_SYSTOHC in /etc/sysconfig/clock.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c37 --- Comment #37 from Dr. Werner Fink 2012-11-05 15:27:09 UTC --- (In reply to comment #35) Setting the system clock does *not* change the hardware clock. For this you may use the hwclock programm with its option --systohc. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c39 --- Comment #39 from jorge aires 2012-11-05 15:58:46 UTC --- (In reply to comment #38)

(In reply to comment #37)

...

(In reply to comment #35)

Setting the system clock does *not* change the hardware clock. For this you may use the hwclock programm with its option --systohc.

I understand that. I'm saying I change the system date and upon reboot these changes are lost.

Is that how it is supposed to work?

In other words, upon reboot, system time always coincides with the hwclock. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c41 --- Comment #41 from jorge aires 2012-11-05 17:01:04 UTC --- (In reply to comment #40)

(In reply to comment #38)

Without a running ntpd the system time will not be written back and indeed this is intended.

Well then the question becomes, shouldn't ntpd be running and why isn't it. What I am asking really is, in a properly installed desktop system, should changes to the system time done via KDE's clock settings (or using date, or using ntpdate) be lost after reboot? It really doesn't seem to me like the proper behaviour should require for the user to manually change the hardware clock time, either using hwclock --systohc, or by accessing the BIOS. Yet any change to the system clock, not just small changes of a few minutes but also big changes of a few hours, are not preserved after reboot. The system time after reboot always coincides with the hwclock. And given that, when there are any DST changes, what happens is also precisely that the system time does change to reflect them, and then upon reboot again it coincides with the hwclock, I'm inclined to believe this is a manifestation of the same problem.

Only if a ntpd daemon runs for a longer time then kernel is switched in the so called elven minute mode (compare manual page adjtimex(2)) which then writes the system time back to the hardware clock in real time accuracy. Only if the hardware clock if off by more then 900 seconds (15 minutes) this is not done even in the eleven minutes mode as there are timezone with 30 minutes offset.

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c44 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |lnussel@suse.com AssignedTo|werner@suse.com |fcrozat@suse.com --- Comment #44 from Dr. Werner Fink 2012-11-28 09:32:56 UTC --- No it seems to be more a systemd problem as the systohc part at shutdown/reboot seems to be missed. The questions rises if systemd/timedated do read the configuration found in /etc/sysconfig/clock. Next is that fate #312407 was IMHO a bug as now the systohc part never had been done for sysvinit. But now this is part of systemd/timedated or one of the units responsible at shutdown. @Frederic: How does systemd handle the clock at shutdown/reboot. @Ludwig: Why you have done fate #312407 without thinking how the systohc part could be done? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c46 --- Comment #46 from Frederic Crozat 2012-11-28 10:19:29 UTC --- from systemd TODO list : http://cgit.freedesktop.org/systemd/systemd/commit/?id=d2e83c23f5f0cdd3b6ec0... +* introduce ntp.service (or suchlike) as symlink that is used to arbitrate betw + NTP implementations + +* timer units should get the ability to trigger when: + - CLOCK_REALTIME makes jumps (TFD_TIMER_CANCEL_ON_SET) + - DST changes + +* update the kernel's TZ (sys_tz) when DST changes + +* sync down the system time to the RTC when: + - CLOCK_REALTIME makes jumps (the user explicitely requested a time set) + - DST changes && ntp is active && RTC-in-localtime (never do it without ntp + This takes care of syncing ntpdate updates to the RTC, and DST updates for lo + mode, it will never touch the RTC if the no reliale time source is active or + user did not request anything like it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c49 --- Comment #49 from Dr. Werner Fink 2012-11-28 10:36:19 UTC --- (In reply to comment #47) IMHO we should re-add a similar script for shutdown only which a) check for the existence of /etc/adjtime as then know about the reference clock of the RTC, b) the eleven minute mode is active due ntp, *and* c) if this eleven minute mode does really update the RTC. I've around the last version of the boot.clock script and I'd like to use the stop part from it to implement a systemd unit with this. Any opinions, comments, suggestions, and/or hints for/against this? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c51 --- Comment #51 from Dr. Werner Fink 2012-11-28 11:14:01 UTC --- Q: What is /usr/lib/systemd/system-shutdown for? Could it be used for a more flexible script at shutdown. This would avoid the to write out an environment file or use a huge one line bash command line on ExecStart? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c53 --- Comment #53 from Dr. Werner Fink 2012-11-28 12:16:47 UTC --- OK ... good to know ...what is about /sys and /proc. Can I access those file systems? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c55 --- Comment #55 from Dr. Werner Fink 2012-11-28 13:03:45 UTC --- Created an attachment (id=514845) --> (http://bugzilla.novell.com/attachment.cgi?id=514845) hwclock.shutdown -- shutdown script to write the system clock back RTC With this script the /etc/sysconfig/clock is used with its variables to determine if the system clock should be written back to the hardware clock. But do not do this for S390 and XEN clients. The user can overwrite any eleven minutes mode by FORCE_SYSTOHC=yes or avoid the script by SYSTOHC=no. Also the script checks if the offset of the RTC is greater than 900 seconds as in this case the kernel does not touch the RTC even in the eleven minutes mode. I've choosen the /etc/sysconfig/clock from 12.2 ... then only question is how the variable USE_ADJUST is used or could be used to enforce the systemd-timedated to use the two first lines of /etc/adjtime to adjust system clock by the offsets in /etc/adjtime ... or does systemd ignores this silently? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c57 Ludwig Nussel changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|lnussel@suse.com | --- Comment #57 from Ludwig Nussel 2012-12-10 16:02:45 CET --- Introducing such ugly scripts and magic numbers into the boot process again looks backwards to me. IMO those dbus-services that are used nowadays to set the clock on user request should take care of setting the hw clock as well so you don't have to apply magic guessing at each shutdown. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c Frederic Crozat changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|fcrozat@suse.com |systemd-maintainers@suse.de -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c60 Frederic Crozat changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|fcrozat@suse.com | --- Comment #60 from Frederic Crozat 2014-01-15 12:00:45 UTC --- (In reply to comment #59)

How this is solved in systemd 208? Is it possible to use local time in CMOS clock. That is that the system clock will be written back to CMOS?

it isn't, since I didn't close the bug report.. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.