Bug#48866: Time-Zone still wrong
At 08:41 AM 2/2/00 +0900, Taketoshi Sano wrote:
>In <[🔎] NDBBLJECCLJCBKMIKBPBCEABFAAA.firstname.lastname@example.org>,
> at Date: Tue, 1 Feb 2000 09:52:17 -0800,
> on Subject: RE: Bug#48866: Time-Zone still wrong,
> "Ross Boylan" <email@example.com> writes:
>> I'm concerned there is more to the problem than this. As I reported,
>> manually changed /etc/default/rcS to UTC=no my system clock was reset
>Have you "manually changed" it in boot-floppies alternative console (Alt+F2)
>during initial install stage (boot from root floppy) ?
Neither my recollection nor my notes permit me to be absolutely sure, but I
think I made the change after the initial install and reboot.
>I think the problem of "reseting the hardware (cmos) clock on shutdown,
>and adjust /etc/adjtime" is another problem than this "boot-floppies can
>not change /etc/default/rcS when specified to use localtime in CMOS clock"
>> That was with 2.2.4 boot-floppies. Was this just an artifact of
>> changing the setting after the initial install?
>In initial install, /etc/default/rcS is set by dbootstrap in boot-floppies.
>This is done by asking user with the prompt of "Use UTC in CMOS clock ?"
>If user answer "yes", then /etc/default/rcS is left untouched, and if user
>answer "No", then it is changed from "UTC=yes" to "UTC=no".
Except it wasn't doing that (the original bug). I think I saw the
discussion of the fix after the 2.2.5 release, so I've assumed 2.2.5 still
has the problem but 2.2.6 will fix it. Correct?
>This part is the work for boot-floppies.
>Then, after rebooting the installed system, system clock and hareware (CMOS)
>clock is controlled by /etc/init.d/hwclock.sh using /sbin/hwclock from
Does /etc/default/rcS play any role after the initial install?
>This script (/etc/init.d/hwclock.sh) takes the part of "reseting the clock"
>problem, and boot-floppies can not do for that.
>> Also, if someone could combine this and bug 53808, that would be great.
>> now convinced that the two refer to the same problem (I submitted 53808).
>If 53808 is for the problem of "resetting the clock on reboot", then
>it may be different problem. I think 48866 is initially reported for
>the problem of "b-f (boot-floppies) can not change the setting in
I think I reported the resetting the clock problem against both bugs. It
is an example of "mission creep." I thought this was simply another symptom
of the same underlying problem, and perhaps a clue why the earlier efforts
to fix the problem failed (namely that setting UTC to no caused other
problems, namely the resetting the clock).
The resetting problem may be a separate issue. It also may have gone away
with all the other changes, or I may have done something odd to cause it.
Of course, if the rcS file is set correctly to begin with, there will be no
occasion for the normal user to switch it (unless they get rid of MS after
awhile and decide to change their use of the clock ....).
So maybe a good solution would be to declare that 48866 refers to the
original problem behind both bug reports, namely that saying "CMOS clock is
not UTC" during the initial install does not have the desired effect.
And 53808 refers to the problem "when I edit my rcS file from UTC=yes to
UTC=no, the actual time on the system clock changes on reboot." When the
editing occurs is uncertain.
I do not immediately have the time to attempt a new install, but I hope
this helps some. Thanks for working on this.
> Taketoshi Sano: