[arch-general] Installation: after first reboot ext3 superblock mount time in future

[Roman Kyrylych]

2008/3/30, Gerhard Brauer <gerhard.brauer at web.de>:
> Hello,
>
>  i've done a bit more testing.
>  First i think it's not a bug in any package. It's only a mismatch
>  between clock set on install machine and the timezone which is later set
>  during config.
>
>  1. I guess there is absolut no problem on machines where the hardware
>  clock is set to UTC by default.
>
>  2. If the clock is set to localtime there is a mismatch directly after
>  booting the kernel. The time is read from bios and then the timezone is
>  UTC per default what is a wrong time. Ex.
>  My localtime is 13:46 (= machines hardwareclock) but this time is
>  CEST(UTC+2)
>  So date on the machine itself shows:
>  Sun Mar 30 13:46 UTC 2008 but it must be
>  Sun Mar 30 11:46 UTC 2008 or
>  Sun Mar 30 13:46 CEST 2008
>
>  Solutions:
>  a) set the time by hand (KISS, maybe put a hint on installation guide?)
>  date -s "13:46 CEST" result in:
>  Sun Mar 30 11:46 UTC 2008
>  which is the now correct UTC time.
>  b) put tzdata package on ISO, so the user could use tzselect. Hint could
>  also be given in instalation guide. Or we make it more comfortable
>  (handholding the user) and put this as a menu in installer("Set your
>  timezone"). The $TZ env var could then also used by the installer to
>  initial set TIMEZONE in rc.conf as we do it with KEYMAP. As a side
>  effect we could reduce a lot of postings in forums where users not set
>  this correctly. But that need perhaps discussion, i feel it a little bit
>  to handholding.
>
>  Personally i will use a) in the future.
>  As a solution which maybe should be discussed i would prefer b), tzdata
>  on ISO and a entry in installer menu.
>
>  What do you think? Other ideas?

Aha, it seems now I've got it.
It looks like the issue silently reappeared after it was fixed
- because tzdata was splitted from glibc and then not included on install CD,
thus effectively making the fix useless.

In my opinion a separate km-like utility is needed
instead of hardcoding the fix in installer
(if you see the code - you'll understand why it's ugly hack),
because timezone selection should be done before
any read-write mounting to avoid the issue
(e.g. when using install CD to recover the system
- when instaler is not run and the hardcoded fix is not working).
I blame myself for failing to do this for a looong time. :-(
I didn't know (or forgot) about tzselect (*facepalm*) - thanks for
pointing me that.

-- 
Roman Kyrylych (Роман Кирилич)