On Friday, January 19, 2007 @ 6:50 PM, Carlos Robinson wrote:
The Friday 2007-01-19 at 15:03 -0600, Greg Wallace wrote:
So you must have the setting that said your bios clock was set to utc, yet before it was actually set to localtime. They only need to agree.
I'm still confused about this. My BIOS doesn't have the ability to use UTC vs Local.
Ffffssssss.....
No bios has that ability. No one has it. We did not say that. You are confusing what we write.
The bios clock (aka cmos clock aka hardware clock) does not know and does not care if the time it keeps is local or utc or martian. Only the operation system knows about such subtleties. Ok?
Plus, I haven't changed my clock configuration since 8.1 and have never had this problem before, so I guess it's something new with 10.2.
No, it's not new. It has always been the same way, even before 8.x
Switching to UTC caused the long running fscks to go away, so it seems to me that there was a direct correlation between the two. I had never changed from local to utc or vice versa in the past, so something must have changed with 10.2 to cause this connection. This is, of course, pure speculation, but it seems to fit with what was occurring.
Anyway, it's working now so I guess that's all that matters.
Right.
It is an automatic check to make sure no filesystem needs more extensive checking.
Ok. I always thought that the only time an fsck was invoked was when the number of mounts you had done equaled the setting for that. In the past when an fsck occurred it was always accompanied by a message saying something like "number of mounts since last check exceeded. fsck forced",
That's the long check, and the one for ext2 types.
I didn't realize there was more than one kind of fsck. Good information. Thanks.
or something to that effect. Otherwise, I don't ever seeing the words fsck in the log at all. Now it's in the log every time I boot. Maybe it was there before and I just didn't notice it.
And maybe the log handling has been improved and now it is being logged ;-)
Perhaps that's it.
You should really go through every one of those files and either replace the orig with the newer one, or at least deal with all those config files. I see /etc/localtime is one of those files. That was probably your time problem's root. If you are going to update your install, you need to finish it by checking and resolving these config files.
Yeah. I just recently (a few weeks ago) became aware of what it meant to have RPMNEW files. Should I go through them one by one and see if the date of the RPMNEW is later than the date of the RPM (else, the RPMNEW was created in an earlier install and the RPM would actually be the latest version, right?). For those where the RPMNEW is the latest, is it pretty safe to just swap them in for the regular rpm file?
Sometimes yes, sometimes no. :-p
I guess I'd want to do them a few at a time so that if I foul up my system I'll know which one to swap back.
You have to look at the dates, yes, and at what they contain, choose which one is the best one, and activate it. Or, activate the new one with your modifications from the original file. I usually move the original somewhere else so I know what I changed.
Yeah. I'm doing a full system backup and creating a log of which ones I'm changing in case something breaks. Then I'm going to go through one by one and examine them, renaming them to RPMOLD if they have been bypassed by later updates of the file and swapping the RPMNEWs in for the regular RPMs if the date on the RPMNEW is more current. If something fouls up, I can always recover from the backup.
- -- Cheers, Carlos E. R.
Thanks, Greg Wallace -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org