Bug 6175 - Installer creates some files before TZ or clock are set correctly
Installer creates some files before TZ or clock are set correctly
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
9
i386 Linux
low Severity low
: ---
: ---
Assigned To: Radek Vykydal
Fedora Extras Quality Assurance
: Reopened
: 7553 9455 11407 12155 52095 60672 74374 97339 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-10-20 23:53 EDT by c.coghill
Modified: 2013-01-09 22:37 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-16 15:36:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Fix for TUI (2.77 KB, patch)
2003-01-17 08:54 EST, David Balažic
no flags Details | Diff
Patch for file anaconda-8.0.92/textw/timezone_text.py (2.78 KB, patch)
2003-02-12 04:07 EST, David Balažic
no flags Details | Diff

  None (edit)
Description c.coghill 1999-10-20 23:53:47 EDT
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.
Comment 1 Michael K. Johnson 1999-11-18 13:56:59 EST
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.
Comment 2 Anonymous 1999-11-25 10:04:59 EST
I have seen the same message when using linuxconf in 6.1 and also in 5.2
distribution. My timezone is Israel
Comment 3 Dale Lovelace 1999-12-03 13:25:59 EST
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!
Comment 4 Michael K. Johnson 1999-12-03 14:59:59 EST
*** Bug 7553 has been marked as a duplicate of this bug. ***
Comment 5 Michael K. Johnson 1999-12-03 15:01:59 EST
This appears to be a bug in the installer, not in linuxconf.
Comment 6 Jay Turner 2000-02-21 16:34:59 EST
This issue is resolved in the latest beta.
Comment 7 David Balažic 2002-11-20 15:56:34 EST
Bug never resolved. Still there in RHL 8.0
Comment 8 Jeremy Katz 2002-12-13 17:59:04 EST
*** Bug 11407 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Katz 2002-12-13 17:59:10 EST
*** Bug 9455 has been marked as a duplicate of this bug. ***
Comment 10 Jeremy Katz 2002-12-13 17:59:43 EST
*** Bug 52095 has been marked as a duplicate of this bug. ***
Comment 11 Jeremy Katz 2002-12-13 17:59:51 EST
*** Bug 60672 has been marked as a duplicate of this bug. ***
Comment 12 Jeremy Katz 2002-12-13 18:00:03 EST
*** Bug 74374 has been marked as a duplicate of this bug. ***
Comment 13 Jeremy Katz 2002-12-13 18:06:50 EST
Fixed in CVS
Comment 14 Michael Fulbright 2002-12-20 12:38:25 EST
Time tracking values updated
Comment 15 David Balažic 2002-12-29 12:48:26 EST
Where can I test or at least look at the fix ?
Comment 16 David Balažic 2003-01-13 10:34:12 EST
This is fixed in phoebe for GUI install, but not in TUI.
Comment 17 David Balažic 2003-01-17 08:54:03 EST
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.
Comment 18 David Balažic 2003-01-30 11:42:45 EST
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.
Comment 19 David Balažic 2003-02-12 04:07:00 EST
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
Comment 20 Hans de Goede 2003-02-27 06:29:22 EST
*** Bug 12155 has been marked as a duplicate of this bug. ***
Comment 21 Jay Turner 2003-04-14 13:52:43 EDT
Knocking this back to assigned.
Comment 22 David Balažic 2003-05-20 11:54:15 EDT
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 ?
Comment 23 Jeremy Katz 2003-08-06 16:29:23 EDT
*** Bug 97339 has been marked as a duplicate of this bug. ***
Comment 24 Hans de Goede 2004-07-21 15:29:12 EDT
Afaik still there in FC3, what is the plan (WONTFIX) ?
Comment 25 David Balažic 2004-07-22 02:58:44 EDT
:rolleyes:
Comment 26 Elson, Del 2005-03-13 18:15:14 EST
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.
Comment 28 Matthew Miller 2006-04-13 23:49:31 EDT
Trivia fun-fact: this is one of _two_ remaining four-digit bugs (not counting
bugzilla-bugs.)
Comment 29 Matthew Miller 2006-04-13 23:53:33 EDT
Has nothing to do with Linuxconf. Changing summary.
Comment 30 petrosyan 2008-03-26 14:58:42 EDT
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?
Comment 31 Hans de Goede 2008-03-26 15:40:19 EDT
(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.
Comment 32 petrosyan 2008-04-02 21:12:26 EDT
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?
Comment 33 petrosyan 2008-05-04 00:18:09 EDT
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.
Comment 34 Matthew Miller 2008-05-04 00:59:21 EDT
I think this one needs manual confirmation at the very least.
Comment 35 David Balažic 2008-05-04 09:11:43 EDT
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.
Comment 36 David Balažic 2008-05-04 09:12:20 EDT
Oops, but=bug
Comment 37 Bug Zapper 2008-05-13 21:54:30 EDT
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
Comment 38 Jesse Keating 2008-10-03 18:43:04 EDT
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?
Comment 39 Chris Lumens 2008-12-10 14:45:45 EST
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.
Comment 40 David Balažic 2008-12-11 05:44:41 EST
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
Comment 41 David Balažic 2008-12-11 10:17:22 EST
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
Comment 42 David Balažic 2008-12-11 10:18:14 EST
This was in VMWare.
But if it works for you ...
Comment 43 Elson, Del 2008-12-11 18:56:34 EST
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.
Comment 44 Jesse Keating 2008-12-11 19:43:22 EST
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.
Comment 45 David Balažic 2008-12-12 03:21:11 EST
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.
Comment 46 Radek Vykydal 2009-02-03 11:54:20 EST
Should be fixed in 11.5.0.13.

Note You need to log in before you can comment on or make changes to this bug.