[Solved] Localtime vs hardware clock: How to prevent PCLOS from writing to CMOS?

[jtwdyp]

Hello. For starters I should mention that I did some searching in the forum for a solution to my CMOS problem. I don't like any OS to change my bios time under any circumstances. I set it {usually to match my cell phone} manually from the bios utility. But I've been known to adjust it to an incorrect time or date to fool some dos or windows program from time to time. And I don't like it to change it self back. I'll do that from the bios screen when I'm ready to.

In any case from my forum searches I learned two methods to:

A) set my timezone

B) tell PCLOS NOT to use UTC.

C) tell it to use (or not to) an NTP server.

But I can't find anything that says how to:

D) stop PCLOS from preserving the system time in the hardware clock (CMOS) on shutdown.  

I learned that Old Polack recommends (with a characteristically detailed step by step description) the use of:

PCC -> System -> Manage date and time: to set up A, B, & C.

Likewise I learned that I could likely edit /etc/timezone & /etc/sysconfig/clock, and also either copy or symlink /etc/localtime with the appropriate file in /usr/share/zoneinfo to have the same effect.

But I note that until I first used O_P's recommended method the first time, /etc/sysconfig/clock didn't exist... So (lacking a complete example of it's format, and other values) that only left me the PCC method. Which was for a while somewhat problematic for me because for a couple of days the PCC wasn't working... that is I'd get a blue bar over the center of any/all desktops that kinda resembled:

                         [ Control (PCLinuxOS) Center ]

that persisted until logout, without ever developing into a usable control center... I noticed the synaptic description of the package "drakconf" looked like the source for it but reinstalling it didn't help. That's when I decided to listen to music while I searched for answers to that problem only to discover that somehow my XFCE/kde/e17 multi-desktop PCLOS installation was now missing kaffeine, (which I know was there previously) So I did a quick "apt-get install kaffeine" and then for the heck of it tried to open the PCC one last time before starting to search for a fix for the broken gui tool. Only to my surprise it now was working. Thus I fixed A,B,&C. But how reinstalling kaffeine could fix PCC is beyond me... ;-)

But actually I'm more interested in D) stopping the time (correct or not) from being preserved in the bios clock...  

IE: if I chose to set the bios clock to fool some old pre-2k dos game somesuch thing, into running. And then booted PCLOS I'd actually like it to update the system time it uses from some NTP server to my correct EST time & date.  But to skip the hwclock write so that when/if I return to windows, I'd like my bios timefix to still be in place...

How can I prevent PCLinuxOS from altering the bios clock's time setting?

-- 
|  ~^~   ~^~
|  <?>   <?>       Joe (theWordy) Philbrook
|      ^                J(tWdy)P
|    \___/         <<jtwdyp@ttlc.net>>

[MBantz]

Edit the /etc/init.d/halt

Compare the fedora section on this page to avoid writing to cmos:

http://www.mythtv.org/wiki/ACPI_Wakeup

I assume you just remark out the hwclock command,

cheers,
MBantz

[kjpetrie]

The line is:

Code:

[ -x /sbin/hwclock ] && action "Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS

in /etc/init.d/halt.
Just add a # to the beginning of that line. You'll have to edit the file as root.

If you do that you'll have to set up pclos' time on every boot, as it uses the hardware clock to set the system clock on start up. I suspect you'll be removing the # before long!

I'm also not sure how the system will react to finding files with dates in the future. You might get a kernel panic (Linux equivalent of BSOD).

[menotu]

So I did a quick "apt-get install kaffeine"

Just a quick heads up - I believe the forum normally advises users that its always best to install/update apps using Synaptic and not the command line.

[MBantz]

Hi menotu,

I have never seen any difference between using apt-get and Synaptic, I have used apt-get from the command-line and Synaptic as a developer for a long time with no issues at all. Actually apt-get is the only way of installing/testing packages when building RPM's.

Perhaps rpm -ivh <package> could have some differences from Synaptic, but that is another discussion,

cheers,
MBantz

[menotu]

Hi MBantz,

Thanks for your heads up 

Since being a forum member I have read countless posts saying its unwise to NOT use Synaptic which was the reason for my post - but, I bow to your far superior knowledge (well, Linux knowledge anyway   

[MBantz]

No problems menotu, hope to see you as packager one day soon ;-)

The issue in the forum about apt-get is when updating your system, there are apt-get parameters you should avoid, and you need a special sequence of apt-get calls when updating. Synaptic handle all these issues, so that's the main reason for primarily new users to avoid apt-get I believe,

myself, I coulden't exist in a gui-only world :-) happy as a clam here :-)

cheers,
MBantz

[muungwana]

Hi menotu,

I have never seen any difference between using apt-get and Synaptic, I have used apt-get from the command-line and Synaptic as a developer for a long time with no issues at all.
cheers,
MBantz

synaptic uses "apt-get dist-upgrade" when updating the system. From the terminal, a user can use "apt-get dist-upgrade" or "apt-get upgrade". The former will have no effect while the latter will bork an install sooner or later when used consistently .

[jaydot]

MBantz, usual practise is to use synaptic as one can then be sure that the package downloaded has been tailored to pclinuxos and that all dependencies are met.  those people who feel conversant with linux are free to do as they please, but anyone unsure, or new to the game is advised to follow procedure.

[travisN000]

synaptic uses "apt-get dist-upgrade" when updating the system. From the terminal, a user can use "apt-get dist-upgrade" or "apt-get upgrade". The former will have no effect while the latter will bork an install sooner or later when used consistently .

..just to further clarify these two commands (there is a commmon misconception that they are the same):

apt-get upgrade - only upgrades packages that are installed; it WILL NOT ADD NEW DEPENDENCIES if the updated package needs them..  this is why this command should be avoided 99.9% of the time.

apt-get dist-update - upgrades all installed package, and installs any new dependencies; this is what synaptic does (..the correct way to upgrade 99.9% of the time)/

[menotu]

Well I must say, all those posts were very helpful, and dare I say it? very APT !!!

[MBantz]

Well, we are a little off-topic, but moderators are here now :-)

Jaydot,

apt-get uses the PCLinux repositories only, no mixing from outside. To be more precise, it uses the sources.list file in /etc/apt

My recommendation is that new users only use Synaptic, but when you get more experienced and want to help out packaging, you will need to know apt-get to get things done. Let's call it an expert tool, fine with me,

having packaged the latest pkgutils with additions for the filemanager thunar for building in LXDE, XFCE and KDE I hope I'm right on this point :-)

cheers,
MBantz

[jtwdyp]

MBantz, kjpetrie, Thanks for the quick heads up on how to stop the clock from syncing...


=> But kjpetrie did expound:

If you do that you'll have to set up pclos' time on every boot, as it uses the hardware clock to set the system clock on start up. I suspect you'll be removing the # before long!

I'm also not sure how the system will react to finding files with dates in the future. You might get a kernel panic (Linux equivalent of BSOD).

But if I'm only making this change to the one file (/etc/init.d/halt) Would not the boot up sequence remain the same? I mean if the bios date was off enough to cause problems, they would happen long before halt was called. Wouldn't they?

Speaking of which, I've been multi-booting for years. And what do you think happens if one Linux uses UTC, And another sets bios to LOCALTIME???

The closest thing to kernel panic I ever got was something about superblock dates being in the future "fsck forced"...

And if I use an NTP server to automatically update the system clock, there shouldn't be any need for me to tweak "PCLOS' time"  on any boot unless my Internet connection is down... So I doubt the "#" will be much of an issue for me. Still thanks for the kind advice.


And thank you also, Menotu, MBantz, muungwana, jaydot, travisn000 for the advice and clarifications about using synaptic rather than apt-get.

Especially travisn000's explanation of the actual diff between the two seemingly similar apt-get upgrade/dist-upgrade commands. I've known for a long time that there was a diff But I never quite understood what it was. THANKS!

But since you took the trouble to explain that so well I think it's best to also stress that "apt-get dist-upgrade" desperately needs to always be paired with having just done a fresh *"apt-get update" {first!} *Note for apt beginners: despite it's name "apt-get update" doesn't "update your system" What it does is like the reload button in synaptic, it updates the LIST of available packages.

I don't like to think what could happen if someone last refreshed the package list last month. But the last time they "updated their system" was two months ago, and then they did an "apt-get dist-upgrade" with the stale package data...

By the way, considering that in my original post I mentioned using apt-get, I don't really think the discussion about why it's a good idea (at least for Linux beginners) to use synaptic instead is really so very far off topic.   ;-{)#

=> Speaking of which, MBantz said:

apt-get uses the PCLinux repositories only, no mixing from outside. To be more precise, it uses the sources.list file in /etc/apt

That I knew, but please correct me if I'm wrong in thinking that synaptic uses the same "sources.list file"?? And for that matter Does not the "reload" button in synaptic update the very same data as an "apt-get update" or do they store that data differently???

-- 
|                                     ---   ---
|     Joe (theWordy) Philbrook        (-)   (-)
|          J(tWdy)P                       ^  
|     <<jtwdyp@ttlc.net>>               /---\   << Yawn >>
|                                       \___/

It must be past my bedtime... Good night all!

[kjpetrie]

Synaptic is just a GUI front-end for apt-get.

WRT to NTP, that can correct the system clock if it is off by a couple of hours. My understanding was you wanted the hardware clock off by several years.


Anyway, you seem to have greater experience of this than me, so I will bow to your knowledge.

[jtwdyp]

=> kjpetrie did say:

Synaptic is just a GUI front-end for apt-get.

So then (assuming there were updates available) If I did a:

Code:

su -c "apt-get update && synaptic"

And then clicked on the "mark updates" button without bothering to click-on the "reload" button, Synaptic would find and mark the same updates as if I did click on the reload button?


=> kjpetrie did say:

WRT to NTP, that can correct the system clock if it is off by a couple of hours. My understanding was you wanted the hardware clock off by several years. 

Actually what I want is the arbitrary option to be the only process that ever writes to my bios clock. I only rarely alter it (and I'm more likely to use that to reprint a collection of word processor documents with embedded "today's date" fields that I don't want to edit than to actually try to get some pre-2k program working... (that would be an extreme case) But if I did modify the bios clock for some such project and wasn't done with it when I had a reason to boot up one of my Linuxes to deal with email or some such thing. (I'd want my temporary time fix to remain in place until I decided the "project" was finished and thus manually reset it to match my cell phone's current time/date display.

But I _was_ thinking that an NTP server could fix the Linux system (soft clock), even in the extreme case of the bios time/date being "years" out of sync... Your comment is making me wonder about that however. My reasoning was that since the Linux system clock is based on a single numeric value of the number of seconds elapsed since { err, ahhh I forget, is it when the guy from Bell Labs invented Unix, or when Linus wrote the first Linux kernel? (Don't look, my "CRS" is showing)} But anyway since it's just one numeric field I would think writing the correct value to it would fix the time date regardless of how far out of sync the bios clock that it had been initially set from was...

Now I'm just plain going to have to find time to test that theory.

But first I'll have to actually select an NTP server in the PCC Like Old Polack described... That is, I really haven't a clue how to do that without using the durned gui... {sigh}



=> kjpetrie did say:

Anyway, you seem to have greater experience of this than me, so I will bow to your knowledge.

Perhaps in that I've been multi-booting longer than I've had a clue how to get any of the Linux distributions to stop messing with my local time setting... (each one seams to have a different method so I'm dependent on finding my notes from the last time I fought with each individual distro.) And every time I install a new one, for the first several boots my bios clock most always winds up altered...

But I'm not so sure I know any more about using NTP than you. Quite the reverse I suspect.

-- 
|   ~^~   ~^~
|   <*>   <*>       Joe (theWordy) Philbrook
|       ^                J(tWdy)P
|     \___/         <<jtwdyp@ttlc.net>>

<< there's nothing like an idiot who thinks he knows everything, of >>
<< course, if I actually knew everything, I'd know I was an idiot.  >>