FS#13102 - fix, need to copy initial /etc/localtime
Attached to Project:
Release Engineering
Opened by Gerardo Exequiel Pozzi (djgera) - Monday, 02 February 2009, 22:02 GMT
Last edited by Dieter Plaetinck (Dieter_be) - Saturday, 14 February 2009, 13:04 GMT
Opened by Gerardo Exequiel Pozzi (djgera) - Monday, 02 February 2009, 22:02 GMT
Last edited by Dieter Plaetinck (Dieter_be) - Saturday, 14 February 2009, 13:04 GMT
|
Details
Hi
When new arch system is installed the file /etc/localtime don't exists, this implies that in my timezone (-300/-200[DST]) the first system boot fsck see time in the future and then run, and need a reboot. I patched the setup script to copy the /etc/localtime, that created at setup phase to the $DESTDIR/etc/localtime. This resolves these issue. |
This task depends upon
Closed by Dieter Plaetinck (Dieter_be)
Saturday, 14 February 2009, 13:04 GMT
Reason for closing: Fixed
Additional comments about closing: confirmed by myself and http://www.archlinux.org/pipermail/arch- releng/2009-February/000327.html
Saturday, 14 February 2009, 13:04 GMT
Reason for closing: Fixed
Additional comments about closing: confirmed by myself and http://www.archlinux.org/pipermail/arch- releng/2009-February/000327.html
ftr: /etc/localtime is not included in any package. it's a symlink to a timezonefile. I'm not sure who/what makes this symlink, maybe tzselect?
----------
if [ "$TIMEZONE" != "" -a -e "/usr/share/zoneinfo/$TIMEZONE" ]; then
/bin/rm -f /etc/localtime
/bin/cp "/usr/share/zoneinfo/$TIMEZONE" /etc/localtime
fi
------------
So the /etc/localtime should always exist.
The fsck run must come during initrd run. I mentioned that in some other reports (tz skript in old installer was more broken like our current IMHO). I see a lot better handling like the current installer do it. If set your time correctly in the installer the problem should not occur (remount partition with a time in the future).
Ahh, above code from rc.sysinit is started AFTER the fsck-part in rc.sysinit. So copying /etc/localtime to /mnt/etc/localtime could solve the problem. But this must be tested....
Why fsck during initrd run? I think this really belongs to init's jobs (eg /etc/rc.sysinit)
> Hmm, /etc/localtime should be initialized from rc.sysinit if the file don't exist. But only if TIMEZONE is set in rc.conf: (...)
> So copying /etc/localtime to /mnt/etc/localtime could solve the problem. But this must be tested....
Heh, if we fix #13101 we should always have $TIMEZONE set correctly on the target system after finishing the installation (and if not, the user messed up when editing the config), so if we fix that, does that mean this is no longer a problem?
No, we need to copy/create the /mnt/etc/localtime. Gerado's patch do the right thing IMHO. I've tested it shorten (but with CET i have not
the fsck problems currently).
From rc.sysinit the patch makes sense:
-----
# Set clock early to fix some bugs with filesystem checks
# Clock is set again later to match rc.conf
if [ -f /etc/localtime ]; then
/sbin/hwclock $HWCLOCK_PARAMS --noadjfile
fi
------
After that comes the fsck part. And if /etc/localtime don't exist (first boot after install) the time isn't set correctly, and so fsck
assumes "last mount in the future" (depending on your time/timezone).
Above rc.sysinit part what i have posted comes after the fsck part (so /etc/localtime is created lately after th fsck).
+1 for applying the patch.
(And #13101, but the rc.conf should always checked and edited by the user....)