[Bug 753932] New: DST (Europe) - Time correctly changes at midnight, but its reset to previous setting on reboot
https://bugzilla.novell.com/show_bug.cgi?id=753932 https://bugzilla.novell.com/show_bug.cgi?id=753932#c0 Summary: DST (Europe) - Time correctly changes at midnight, but its reset to previous setting on reboot Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: openSUSE 12.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening@forge.provo.novell.com ReportedBy: jorge.adriano@gmail.com QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 It's always been this way for me in openSUSE. At midnight the time on my clock will correctly fast forward one hour. I finish work, shutdown. When I reboot the next day the clock is back to pre-DST, i.e. one hour late. Reproducible: Always Steps to Reproduce: 1. Go back to the 24th of March and wait for midnight I guess 2. Shutdown computer 3. Reboot Actual Results: Wrong time Expected Results: Correct time -- 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#c1 --- Comment #1 from jorge aires <jorge.adriano@gmail.com> 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#c kk zhang <kkzhang@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kkzhang@novell.com AssignedTo|bnc-team-screening@forge.pr |nld10-bugs-qa@forge.provo.n |ovo.novell.com |ovell.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#c2 --- Comment #2 from jorge aires <jorge.adriano@gmail.com> 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#c Andreas Jaeger <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|nld10-bugs-qa@forge.provo.n |werner@suse.com |ovell.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#c3 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |aj@suse.com Resolution| |WORKSFORME --- Comment #3 from Dr. Werner Fink <werner@suse.com> 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#c4 --- Comment #4 from jorge aires <jorge.adriano@gmail.com> 2012-06-22 13:50:33 UTC --- (In reply to comment #3)
(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.
Thank you for your answer. I appreciate your clarifications, and the link you provided, which I did look into briefly. I have to be honest and say that right now I don't have the time to devote to understand all the technicalities involved. This is what I can tell you: - I never touched the BIOS of this laptop nor my previous ones. - I never intentionally changed the settings of my CMOS clock. - The only time I may have provided any input regarding time was during the installation procedure, to indicate my timezone. - In YaST, date and time, "Hardware Clock Set to UTC" was not ticked. So my conclusion can only be that this situation Either, - had nothing to do with any input I provided, and in which case, I shouldn't be having to be fiddling around with it. (I'm guessing this wasn't the case) Or, - was the result of some input I provided during installation, in which case I would claim the interface is misleading, since if this situation is to be expected then the instructions should be made more clear, and a warning should be provided. Of course another possibility is that everything is very clear and I'm always messing up during installation because I don't bother to read whatever information I am provided during the process. Maybe. I don't think that is the case. Could be wrong though. -- 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 <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME | --- Comment #5 from Dr. Werner Fink <werner@suse.com> 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#c6 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsuchome@suse.com, | |werner@suse.com Component|Basesystem |Installation AssignedTo|werner@suse.com |bnc-team-screening@forge.pr | |ovo.novell.com QAContact|qa-bugs@suse.de |jsrain@suse.com --- Comment #6 from Dr. Werner Fink <werner@suse.com> 2012-06-22 14:08:49 UTC --- Said, reopened and moved to Installation. IMHO there is missed a mkinitrd during yast2-country or any later access of the clock setup. Also at boot the user should be warned about a possible DST/NT or NT/DST switch that he/she should correct the CMSO clock as the system does not know if e.g. a Windows[tm] has already done 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#c Andreas Jaeger <aj@suse.com> 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#c7 --- Comment #7 from jorge aires <jorge.adriano@gmail.com> 2012-06-22 19:23:13 UTC --- (In reply to comment #5)
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
Thanks for your explanation. It's quite clear. Don't get me wrong, I understand that things are the way they are, and there's nothing we can do about that. All I meant is that this complexity should be hidden from users in general, who shouldn't have to face it. If the CMOS clock is UTC by default, and that's what the clock of the linux kernel expects, that's how things should work unless the user goes out of his way to specify some other settings. My guess (and I may be wrong!) is that during installation, at some step, we're asked for what appears to be a timezone, which sets the clock to local time. And, if I am right, and this is what causes all the problems, it really shouldn't be this easy to mess the settings up. -- 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 <jsuchome@suse.com> 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 <jsuchome@suse.com> 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#c9 --- Comment #9 from Jiří Suchomel <jsuchome@suse.com> 2012-07-13 06:22:49 UTC --- Please attach y2logs, /etc/sysconfig/clock and /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#c10 --- Comment #10 from jorge aires <jorge.adriano@gmail.com> 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#c11 --- Comment #11 from jorge aires <jorge.adriano@gmail.com> 2012-07-13 11:02:41 UTC --- Created an attachment (id=498539) --> (http://bugzilla.novell.com/attachment.cgi?id=498539) /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#c12 --- Comment #12 from jorge aires <jorge.adriano@gmail.com> 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#c Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #498539|application/octet-stream |text/plain mime type| | -- 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 <werner@suse.com> 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#c14 --- Comment #14 from jorge aires <jorge.adriano@gmail.com> 2012-07-13 11:34:26 UTC --- (In reply to comment #13)
(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.
HWCLOCK="--localtime" 58692 blocks
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.
Yes, they do, they both result in ccd8194aec8408361f290fd775e8904e -- 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 <werner@suse.com> 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#c16 --- Comment #16 from Jiří Suchomel <jsuchome@suse.com> 2012-09-20 11:29:37 UTC --- What's the status here? Did Werner's comments helped you? BTW, if you do not have /etc/adjtime, create empty one with lines 0.0 0 0.0 0 LOCAL -- 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 <jorge.adriano@gmail.com> 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#c18 --- Comment #18 from jorge aires <jorge.adriano@gmail.com> 2012-10-29 11:15:28 UTC --- OK so it happened again. And I still don't know what to do. As you may know clocks just went back an hour around here in Europe (at least where I am). And as always my clock changed automatically. However, next time I booted the time was wrong. Went to YaST->Time. The box for "time set to UTC" was not selected. So I did click on the box and changed it. Then I used ntpdate as root to set my clock. Next time I booted, time was wrong again. So, I have no idea what to change, or where to change it. All I know is that, - Time changes automatically when it is supposed to - Changes are lost on reboot - I'm supposed to use UTC - The only reference I found to UTC is in YaST->Time - Selecting it didn't help, time is still reverted on reboot - This happened in previous versions of openSUSE with other computers - I haven't touched my 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#c19 --- Comment #19 from jorge aires <jorge.adriano@gmail.com> 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#c20 --- Comment #20 from Jiří Suchomel <jsuchome@suse.com> 2012-10-29 11:29:57 UTC --- (In reply to comment #18)
- The only reference I found to UTC is in YaST->Time - Selecting it didn't help, time is still reverted on reboot - I haven't touched my BIOS
Well, here might be the problem. YaST->Time does not set UTC for your. It only says the system, what are you using in BIOS. If you have UTC in BIOS, YaST should have UTC check, if you have local time in BIOS, YaST should know about it (from you). Local time saving might not work if /etc/localtime does not exist yet, so you might need to create it manually (this should be already fixed in some yast2 module). -- 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 <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|jorge.adriano@gmail.com | --- Comment #21 from Andreas Jaeger <aj@suse.com> 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#c22 --- Comment #22 from jorge aires <jorge.adriano@gmail.com> 2012-10-29 12:20:24 UTC --- (In reply to comment #20)
(In reply to comment #18)
- The only reference I found to UTC is in YaST->Time - Selecting it didn't help, time is still reverted on reboot - I haven't touched my BIOS
Well, here might be the problem. YaST->Time does not set UTC for your. It only says the system, what are you using in BIOS. If you have UTC in BIOS, YaST should have UTC check, if you have local time in BIOS, YaST should know about it (from you).
Right, I thought this could be the case. However in the BIOS setup I cannot find any reference to UTC nor localtime. There's system date and system time and that's it. Also note I have never touch the BIOS, and I'm guessing the default is UTC.
Local time saving might not work if /etc/localtime does not exist yet, so you might need to create it manually (this should be already fixed in some yast2 module).
-- 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 <werner@suse.com> 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#c24 Jiří Suchomel <jsuchome@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |jorge.adriano@gmail.com --- Comment #24 from Jiří Suchomel <jsuchome@suse.com> 2012-10-30 09:22:35 UTC --- Jorge, could you try Werner's advices? -- 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 <jorge.adriano@gmail.com> 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#c26 --- Comment #26 from jorge aires <jorge.adriano@gmail.com> 2012-10-30 15:44:53 UTC --- Now from your comments it appears to be the case that system time changes alone do not result in hw clock changes (considering that there exists hwclock --systohc for that effect). This means there should be an offset stored somewhere. And what seems to be happening is that this offset is always reset to 0 on reboot. Or am I missing something here? -- 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 <aj@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|jorge.adriano@gmail.com | --- Comment #27 from Andreas Jaeger <aj@suse.com> 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#c28 --- Comment #28 from jorge aires <jorge.adriano@gmail.com> 2012-10-30 19:51:12 UTC --- (In reply to comment #27)
Please remember to remove the NEEDINFO if you want others to look at this.
Hi Andreas, not sure what you mean. It's marked as REOPENED now, not NEEDINFO. In fact I thought you'd change it, as per your last comment... -- 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 <aj@suse.com> 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#c30 Jiří Suchomel <jsuchome@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |werner@suse.com --- Comment #30 from Jiří Suchomel <jsuchome@suse.com> 2012-10-31 11:35:16 UTC --- Werner, could you trach what's wrong here? -- 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 <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- InfoProvider|werner@suse.com |jorge.adriano@gmail.com --- Comment #31 from Dr. Werner Fink <werner@suse.com> 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#c32 --- Comment #32 from jorge aires <jorge.adriano@gmail.com> 2012-10-31 17:56:43 UTC --- (In reply to comment #29)
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.
Got it. Sorry for the confusion! -- 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 <jorge.adriano@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|jorge.adriano@gmail.com | --- Comment #33 from jorge aires <jorge.adriano@gmail.com> 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#c34 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |coolo@suse.com, | |fcrozat@suse.com, | |lnussel@suse.com --- Comment #34 from Dr. Werner Fink <werner@suse.com> 2012-11-05 13:40:52 UTC --- (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. 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#c35 --- Comment #35 from jorge aires <jorge.adriano@gmail.com> 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#c36 --- Comment #36 from Dr. Werner Fink <werner@suse.com> 2012-11-05 15:25:48 UTC --- To check the DST switches the command /usr/sbin/zdump -v Europe/Lisbon | sed -rn '/2012 UTC/,$p' | less can be used, then the daylight time switches are seen between two sequently lines with isdst=1 and isdst=0 or reverse. -- 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 <werner@suse.com> 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#c38 --- Comment #38 from jorge aires <jorge.adriano@gmail.com> 2012-11-05 15:53:04 UTC --- (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? -- 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 <jorge.adriano@gmail.com> 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#c40 --- Comment #40 from Dr. Werner Fink <werner@suse.com> 2012-11-05 16:08:06 UTC --- (In reply to comment #38) Without a running ntpd the system time will not be written back and indeed this is intended. 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#c41 --- Comment #41 from jorge aires <jorge.adriano@gmail.com> 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#c42 --- Comment #42 from Dr. Werner Fink <werner@suse.com> 2012-11-06 07:56:25 UTC --- (In reply to comment #41)
Well then the question becomes, shouldn't ntpd be running and why isn't it.
To use ntpd it has to be configured, that is a time server has to added to /etc/ntp.conf which may require a password and a 24/7 network connection. Also the ntpd could be used to access a local DCF clock which has also configured.
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?
AFAIK the SysVint boot script /etc/init.d/boot.clock has been disabled by Ludwig due to the feature request fate #312407 ... IMHO the wrong decision. Next is that this boot script will not work with systemd as systemd simply mask the clock service. I've no idea if systemd provides a configurable systohc option at shutdown/reboot. Next problenm is that systemd does the clock handling at its own in the binary /lib/systemd/systemd and in /lib/systemd/systemd-timedated. -- 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 <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |lnussel@suse.com AssignedTo|werner@suse.com |fcrozat@suse.com --- Comment #44 from Dr. Werner Fink <werner@suse.com> 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#c45 --- Comment #45 from Frederic Crozat <fcrozat@suse.com> 2012-11-28 10:16:31 UTC --- (In reply to comment #44)
@Frederic: How does systemd handle the clock at shutdown/reboot.
systemd relies on the kernel to sync the hardware clock, when ntp is running (ie the 11 minutes mode) So, maybe we should add a "hwclock-save" service at shutdown, to save the clock, if we aren't in ntp mode. Opinions welcome. -- 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 <fcrozat@suse.com> 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#c47 --- Comment #47 from Frederic Crozat <fcrozat@suse.com> 2012-11-28 10:25:24 UTC --- hmm, systemd used to save clock but it was removed, see http://cgit.freedesktop.org/systemd/systemd/commit/?id=da2617378523e007ec0c6... -- 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 <werner@suse.com> 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#c50 --- Comment #50 from Frederic Crozat <fcrozat@suse.com> 2012-11-28 10:45:39 UTC --- (In reply to comment #49)
(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?
Yes, I was about to suggest something like that. -- 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 <werner@suse.com> 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#c52 --- Comment #52 from Frederic Crozat <fcrozat@suse.com> 2012-11-28 11:54:34 UTC --- (In reply to comment #51)
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?
systemd will execute all executable from this directory, just before doing the system shutdown. However, be careful, "All filesystems, swaps, loop devices, DM devices detached" so / will be ro. -- 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 <werner@suse.com> 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#c54 --- Comment #54 from Frederic Crozat <fcrozat@suse.com> 2012-11-28 12:31:54 UTC --- (In reply to comment #53)
OK ... good to know ...what is about /sys and /proc. Can I access those file systems?
I just checked on 12.2 : /proc and /sys are still mounted.. -- 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 <werner@suse.com> 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#c56 --- Comment #56 from Frederic Crozat <fcrozat@suse.com> 2012-11-28 14:01:07 UTC --- (In reply to comment #55)
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?
for timedated, /etc/sysconfig/clock is only read in Factory, not in 12.1 nor 12.2. And only TIMEZONE value is read from there. /etc/adjtime is the only file used for the offsets. -- 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 <lnussel@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|lnussel@suse.com | --- Comment #57 from Ludwig Nussel <lnussel@suse.com> 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#c58 --- Comment #58 from Frederic Crozat <fcrozat@suse.com> 2012-12-10 15:12:22 UTC --- those dbus-services will only be run if something is triggering them (and by default, nothing will). -- 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 <fcrozat@suse.com> 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#c59 Dr. Werner Fink <werner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |fcrozat@suse.com --- Comment #59 from Dr. Werner Fink <werner@suse.com> 2014-01-15 11:49:31 UTC --- 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? -- 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 <fcrozat@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|fcrozat@suse.com | --- Comment #60 from Frederic Crozat <fcrozat@suse.com> 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.
participants (1)
-
bugzilla_noreply＠novell.com