Arch Linux

yup. i get this too.
fully up to date, fresh install as of 10-14-2006

New info.
I just pasted the following:
"/sbin/hwclock --directisa --localtime --hctosys"
above the "status "Mounting Root Read-only" /bin/mount -n -o remount,ro /"
line in rc.sysinit

This is a kludge, for my needs. it works.
A better solution, would likely be to move the entire section for syncing the localtime from the system time, to before the fsck section.

Hmm... haven't noticed this problem, but I will check if it exists for me too.
I have a similar problem with time reported here: http://bugs.archlinux.org/task/5529
Maybe these two bugs can be fixed at once?

I had reported the problem with wrong time after first boot in http://bugs.archlinux.org/task/5444 (should be marked as duplicate of 5529), but imho it's not related to this one.

This is simply caused because the clock is set up too late, after filesystems are mounted and fsck'd, which causes a problem if local time is used.

The other problem could be because zoneinfo is wrong (GMT?) on first boot. I don't think adjtime is related.

> This is simply caused because the clock is set up too late, after filesystems are mounted and fsck'd, which causes a problem if local time is used.

How to setup clock and timezone without mounting / ?

The time stamp on the file system is updated only when it's mounted read-write. Initially the root file system is mounted read only, which gives us the chance to update the clock among other things, then it's remounted read-write.

This can't work right now because rc.sysinit wants to update the symlink /etc/localtime according to what rc.conf says. A minimal workaround would be to update the symlink during shutdown instead of startup.
It also wants to update adjtime. (At least in Debian it's disabled for causing problems more often that not, which agrees with my experience).

Perhaps updating /etc/localtime at boot time is a systematically wrong way to handle the task - I think it was the cause of #5444 as well.

> Perhaps updating /etc/localtime at boot time is a systematically wrong way to handle the task - I think it was the cause of #5444 as well.

Well, yes. I don't see the reason of updating /etc/localtime on _each_ boot.
On install - yes. And then only when user moves with his PC/notebook to another timezone.

Is this bug still valid with testing/initscripts-0.7.3-1 ?

Yes, please keep this open for now.

dimosd, does removing lines that do symlinking of /etc/localtime from rc.sysinit and copying required file in place of /etc/localtime solves the issue?

Here is the patch that solves the issue. Please test it and confirm if it works.
Note that it require symlinking of /etc/localtime to be done by installer, otherwise  bug 5444 /5529 will be valid again.

I'm working on version that wouldn't require changes to the installer (useful for users installing with 0.7.2 installer from FTP or fresh package mirror on CD/HDD).

Here's the second version of patch that fixes the issue while not making  bug 5444 /5529 valid again and not requiring any changes to installer.
Note that this is temporary solution until the fix in official installer will be available (which should happen in 0.8, I hope), the first solution is much cleaner and elegant, while the second version is more like a hack, so it should be changed to first version when installer will be modified to do symlinking /etc/localtime by itself.

Thank you for your patch. There's an issue that comes up if /usr or /var reside on partitions of their own.
I am attaching a commented patch based on your first patch, intended for demonstration. I believe it treats the problem correctly (not necessarily optimally) but it needs the installer to be updated. Perhaps this bug fix can wait until then. Otherwise an updated version of initscripts or util-linux (hwclock) can place a correct /etc/localtime as a one time fix with its installation script (perhaps even during initial installation).

Please also give some thought to whether we should stop updating /etc/localtime according to what $TIMEZONE in rc.conf says and only rely on the installer.

Well, I didn't think about /usr and /var on different partitions, thanks for poiting this out.
I think better solution will be:
1) generate /etc/localtime from installer
2) remove that sed line from util-linux PKGBUILD that changes /etc/adjtime to /var/lib/hwclock/adjtime
3) do not do hwclock --hctosys for the second time, there's no need for it when there is /etc/adjtime
4) initializing /etc/adjtime can safely be done after reading hwclock, anyway there won't be any error when /etc/adjtime doesn't exist
5) replace ln -sf with cp in rc.shutdown, and keep TIMEZONE in rc.conf
So, my first patch should be modified to use /etc/adjtime and cp instead of ln.

1) generate /etc/localtime from installer == cp it, not ln -sf, of course.

Copying /etc/localtime in initscripts' or util-linux' .install file will be good for those who install with old installer but fresh package db (FTP or fresh mirror on CD).

Today initscripts-0.8-1 hit Current. They contain changes made by tpowa, but they _do_not_ fix the issue properly.
1) /etc/localtime will not work when /usr is on different partition than /, so hwclock --hctosys will set wrong time.
2) when user changes TIMEZONE in rc.conf, on next boot first hwclock will set time for old timezone, then after fs check time will be changed.

I _highly_ recommend to fix the issue as in my first patch, with corrections made by dimosd me and me later.

And please fix the installer before making official 0.8 ISOs.

New patch, requires installer to cp zoneinfo file to /etc/localtime
Doesn't violate FHS. Works correctly with /usr and/or /var on different partitions that /.

Oh, forgot to mention that it was fagainst 0.7.2 (I haven't updated system to 0.8 yet), sorry.
Here's a patch against initscripts-0.8-1