> Rafael Reilova writes:
> > On Fri, 21 May 1999, Richard Gooch wrote:
> > > The only place I'm aware that the kernel needs to know the timezone is
> > > this case with suspend/resume. So aside from this, I don't see a need
> > > for the kernel to know the timezone. Hm. Although I vaguely remember
> >
> > The other case which has been claimed is to set the mount/fsck timestamps
> > on the filesystems at boot, but it is mostly a special case, ie,
> >
[...]
> >
> > Now if the root filesystem is corrupted, then after fsck is run,
> > time will probably be messed up in it, but that is an abnormal
> > condition. The other posibility is to run hwclock before fsck, but
> > that is not safe. If you have everything in a single partition then
> > that's another story ;-)
>
> What's unsafe about running hwclock before fsck? Since root is mounted
> ro, what damage can be done?
Wrong choice of words on my part, it's not unsafe, but you might get
kernel panic on a suficiently corrupted FS... But of course in that case
you're better of running fsck manually from a boot floppy *after* correcly
running hwclock anyways; so yes, run hwclock prior to fsck and forget it ;)
> > IMHO, a simple command parameter giving the offset in hours
> > (half-hours?) from UTC to the kernel is fine, but I really hope
> > nobody is considering adding daylight savings, leap seconds, and all
> > that userland craziness to the kernel 8)
>
> At most half-hours (Adelaide, South Australia has a half-hour
> timezone). But I think this is a bad idea. I remember all the trouble
> we had with our Convex C220 where the OS and the SPU (Service
In any case, lets keep this in perspective, it is only for those people
that need to keep their RTC non-UTC to run less-capable OS'es. These
people are likely to run linux off std. distributions. I quickly checked
a Debian2.1 and a Redhat6.0 system at work, and both fsck root *prior* to
hwclock. Most of these installs are also done into a single partition, so
the wrong time is potentially propagated to more files.
So it seems the bug is in the distributions' boot scripts and (mostly) not
a kernel issue.
> Duplication of data is inherently fragile. It's to be avoided if at
> all possible. The fsck case doesn't seem to justify the risk.
All too true!
Cheers,
-Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/