Hi, Every time I run Linuxconf and go to activate the changes it gives me a big warning that the filestamps on various files are in the future. Everything seems to work fine, but these (multiple) warnings are annoying and incorrect. Could this be related to us being in New Zealand, and on daylight savings time - we are currently UTC+13, which has caused us problems with certain other OS's that make assumptions about timezones.
It shouldn't have anything to do with it -- it should be comparing GMT to GMT with no reference at all to the local time offset.
I have seen the same message when using linuxconf in 6.1 and also in 5.2 distribution. My timezone is Israel
I have tried changing timezones to several different ones and still can't reproduce this. Could you, as a test, try exiting Linuxconf, see which files it says are in the future, then do a ls -la on those files and compare them to the "date" command's output? Thanks!
*** Bug 7553 has been marked as a duplicate of this bug. ***
This appears to be a bug in the installer, not in linuxconf.
This issue is resolved in the latest beta.
Bug never resolved. Still there in RHL 8.0
*** Bug 11407 has been marked as a duplicate of this bug. ***
*** Bug 9455 has been marked as a duplicate of this bug. ***
*** Bug 52095 has been marked as a duplicate of this bug. ***
*** Bug 60672 has been marked as a duplicate of this bug. ***
*** Bug 74374 has been marked as a duplicate of this bug. ***
Fixed in CVS
Time tracking values updated
Where can I test or at least look at the fix ?
This is fixed in phoebe for GUI install, but not in TUI.
Created attachment 89422 [details] Fix for TUI This is a (possible) fix for TUI mode, which I made by slightly editing the original code. I never tested it, because I don't know how.
Tested this in TUI install of phoebe2 ( 8.0.93 ). My timezone is UTC+1 ( one hour east of Greenwich : Europe/Ljubljana ) It seems almost fixed, but the correct time is set too late. It is set after the root fs is formatted and a few directories are created. I checked on VT2 right before packages were started copying and saw that the dirs dev, lost+found and proc in /mnt/sysimage were already created and had the wrong time ( in future ). After the install finished and the system booted, the situation was the following ( judging by the output of "ls -l /") : /lost+found and /proc had time in future ( the UTC intrepreted CMOS value ) /home and /initrd had the date 2-dec-2002 18:03 /misc had the date 7-jan-2003 12:18 /opt had the time 2-dec-2002 18:03 These are local times. The ( local ) time if installation was 29-jan-2003 21:05 and it was a complete reinstall, with a freshly formatted disk, so this dates from the past are very weird.
Created attachment 90025 [details] Patch for file anaconda-8.0.92/textw/timezone_text.py This is a fixed version of my patch that actually works. Issues: - certain timezones in the list are not present in /usr/share/zoneinfo, so they can not be interpreted - the BACK button in the timezone screen does not work correctly, it goes forward, instead of back
*** Bug 12155 has been marked as a duplicate of this bug. ***
Knocking this back to assigned.
Tested the latest alpha. Same as I reported in comment #18. The correct time is set after the root fs was formatted and a few directories created, so they have the incorrect time. Also some directories, like /home have a date far back in the past ( few months ) , is that a separate issue ?
*** Bug 97339 has been marked as a duplicate of this bug. ***
Afaik still there in FC3, what is the plan (WONTFIX) ?
:rolleyes:
Here is another symptom of this bug: When doing a fresh install of a RHEL 2.1 or RHEL 3.0 system, certain files are timestamped during the install as if the system clock and local time were both GMT. This includes /lib/modules/(kernelversion)/modules.dep. If your real time zone is EAST of GMT (c.f. the original poster's time zone, NZ) then the files will effectively be timestamped (GMT offset) hours in the future. e.g. if my timezone is 10 hours ahead of GMT then then modules.dep will be timestamped 10 hours in the future. When depmod -A runs it looks at the date of the modules.dep file and exits silently if the time stamp is more recent than the timestamp of any module in /lib/modules/(kernelversion). So, if I have a time zone 10 hours ahead of GMT, and I install a new driver within 10 hours of system install time, then the depmod -A command run from within /etc/rc.d/rc.sysinit will do nothing. This means that the driver never becomes available to the kernel. This should be a higher priority than LOW. I guess it's been set to LOW priority because it only affects people east of GMT -- e.g. it doesn't affect anyone in the USA. I'm raising this direct with Red Hat Asia Pacific to see if they can apply some pressure to get this fixed as it affects their clients more than anyone else's.
Trivia fun-fact: this is one of _two_ remaining four-digit bugs (not counting bugzilla-bugs.)
Has nothing to do with Linuxconf. Changing summary.
Last comment on this bug was more than 3 years ago (2005-03-13). Is this bug still present in Fedora 7 or 8 or rawhide?
(In reply to comment #30) > Last comment on this bug was more than 3 years ago (2005-03-13). > > Is this bug still present in Fedora 7 or 8 or rawhide? I'm afraid I have no idea. This would require someone todo a fresh install (not livecd, but a real one) and then check the timestamps on lost+found.
I just did a fresh install of Fedora rawhide and timestamps on /lost+found correspond to the time of installation. So it looks like this bug has been fixed. Can anybody confirm it?
The information we've requested above is required in order to review this problem report further and diagnose/fix the issue if it is still present. Since there have not been any updates to the report since thirty (30) days or more since we requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.
I think this one needs manual confirmation at the very least.
Yes, the but is there in Fedora 9 preview. Both in GUI and TUI setup. But close this bug anyway, because if there is no single person at redhat/fedora project that can test it, then for sure there is noone who could fix it.
Oops, but=bug
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hrm, not sure why this is on the blocker list. Is anybody on this bug able to reproduce the problem with F10 Beta or later versions of Rawhide?
No, I've never seen this in the many installs I've done, and I have never heard of this bug turning up from any of the Fedora QA guys either. Closing.
F10-i686-Live.iso : after installing to hard drive and rebooting: [stein@localhost tmp]$ ls -l /sys/devices/platform/i8042/modalias -r--r--r-- 1 root root 4096 2008-12-11 12:03 /sys/devices/platform/i8042/modalias [stein@localhost tmp]$ date Thu Dec 11 11:42:16 CET 2008 Timezone is Europe/Ljubljana
Fedora-10-i386-disc[12].iso - install: -- lang : default (english) -- keyboard layout : Slovenian -- timezone : Australia/Perth -- BIOS clock : localtime (not UTC) After install, reboot, login: $ ls -l /etc/login.defs /etc/hosts /lib/modules/2.6.27.5-117.fc10.i686/modules.dep -rw-r--r-- 1 root root 187 2008-12-12 00:53 /etc/hosts -rw-r--r-- 1 root root 1524 2008-12-12 00:53 /etc/login.defs -rw-r--r-- 1 root root 344478 2008-12-12 00:28 /lib/modules/2.6.27.5-117.fc10.i686/modules.dep [stein@localhost ~]$ date Thu Dec 11 16:13:16 WST 2008
This was in VMWare. But if it works for you ...
This is clearly still a bug. No point testing it with US timezones because they are all WEST of GMT. This bug only manifests when installing with a timezone EAST of GMT. So it's not a bug for half the world, but it is for the other half. That other half includes India and China, so that's a good number of people.
The question in my mind is doesn't this just depend on what the hwclock is set to? IIRC Fedora assumes that the hwclock is set to UTC.... Since we don't prompt the user for what the current time is during the install, nor do we contact a timeserver, I'm not sure what we're supposed to do other than assume that the hwclock is accurate and go with that.
Elson, you forgot Europe (and Russia) ;-) > Fedora assumes that the hwclock is set to UTC not it does not assume. It asked me whether the hwclock is UTC or not. > assume that the hwclock is accurate It is. The system time is correct. Except before it is set up. Before that it is apparently wrong. (the _kernel_ assumes that hwclock is UTC; on boot; mentioned this to kernel guys ages ago, but they don't seem to care, "user-space should deal with it".) So what we have is : 1.) boot 2.) wrong system time 3.) creating system files (with wrong mtime) 4.) asking the user about correct time (timezone and hwclock state) 5.) setting the correct time Step 3 should me moved after step 5 and the bug is solved.
Should be fixed in 11.5.0.13.