Description of problem: During firstboot, the /etc/localtime link that was configured during installation is overwritten with a timezone file. The timezone file is for ET, not the timezone configured during installation. Version-Release number of selected component (if applicable): firstboot-18.4-1.fc18.x86_64 system-config-date-1.9.68-1.fc18.noarch How reproducible: Always. Steps to Reproduce: 1. Begin a clean install. 2. During installation, select the timezone America/Los_Angeles. 3. Reboot. 4. When the firstboot dialog is first displayed, switch to a console and login. 5. # ls -lF /etc/localtime # zdump /etc/localtime 6. Complete firstboot. 7. At the gdm login, switch to a console. 8. # ls -lF /etc/localtime # zdump /etc/localtime Actual results: /etc/localtime is a timezone file for ET. Expected results: /etc/localtime is a link to ../usr/share/zoneinfo/America/Los_Angeles. Additional info: $ cat typescript-2 Script started on Sat 06 Oct 2012 08:01:30 AM PDT [root@localhost xfr]# rpm -q firstboot system-config-date firstboot-18.4-1.fc18.x86_64 system-config-date-1.9.68-1.fc18.noarch [root@localhost xfr]# ls -lF /etc/localtime lrwxrwxrwx. 1 root root 41 Oct 6 07:51 /etc/localtime -> ../usr/share/zoneinfo/America/Los_Angeles [root@localhost xfr]# zdump /etc/localtime /etc/localtime Sat Oct 6 08:02:02 2012 PDT < firstboot was run here > [root@localhost xfr]# ls -lF /etc/localtime -rw-r--r--. 4 root root 3519 Sep 17 08:37 /etc/localtime [root@localhost xfr]# zdump /etc/localtime /etc/localtime Sat Oct 6 11:03:17 2012 EDT [root@localhost xfr]# exit Script done on Sat 06 Oct 2012 11:04:04 AM EDT See also: Bug 824033 - RFE: Make /etc/localtime a symlink
Created attachment 624244 [details] strace log showing firstboot replacing /etc/localtime By attaching strace to the firstboot process, I was able to catch firstboot replacing /etc/localtime. There is an apparent 4-hour time-reversal after the rename ... 10:46:08.012429 lstat("/etc/localtime.mHiyeD", 0x7fff20f2fe20) = -1 ENOENT (No such file or directory) 10:46:08.012498 link("/usr/share/zoneinfo/US/Eastern", "/etc/localtime.mHiyeD") = 0 10:46:08.012622 rename("/etc/localtime.mHiyeD", "/etc/localtime") = 0 06:46:08.012715 access("/var/spool/postfix/etc/localtime", F_OK) = -1 ENOENT (No such file or directory) Tested with: $ sudo strace -f -tt -p 480 2> strace1.log firstboot-18.4-1.fc18.x86_64 system-config-date-1.9.68-1.fc18.noarch
Proposing as an F18 Final blocker under: 16. All known bugs that can cause corruption of user data must be fixed or documented at Common F18 bugs This bug overwrites the timezone configured by the user during installation. 18. All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in common use The user cannot change the timezone from gnome control center: Bug 864603 - systemd[1]: SELinux policy denies access. Fedora 18 Final Release Criteria https://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria Verified with a clean, default install from: Fedora-18-Beta-TC3-x86_64-Live-Desktop.iso Command-line: $ qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC3/Fedora-18-Beta-TC3-x86_64-Live-Desktop.iso -usb -vga qxl -boot menu=on
The timezone screen in firstboot is directly imported from system-config-date. s-c-date then does all the work. Reassigning.
See also: Bug 864603 - systemd[1]: SELinux policy denies access. (cannot change timezone from gnome control center)
Proposing as an F18 Beta NTH: 1. Causes loss of user configuration (/etc/localtime is overwritten) 2. Cannot be fixed with an update (installer and firstboot run once) Work-arounds: 1. Manually create a link to a timezone file: $ cd /etc $ sudo ln -sf ../usr/share/zoneinfo/America/Los_Angeles localtime 2. With Bug 864603[1]: $ sudo setenforce permissive < set timezone from gnome control center > $ sudo setenforce enforcing 3. Without Bug 864603: < set timezone from gnome control center > [1] Bug 864603 - systemd[1]: SELinux policy denies access. (cannot change timezone from gnome control center)
Discussed at 2012-10-11 NTH review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-11/f18beta-blocker-review-3.1.2012-10-11-16.04.log.txt . Accepted as NTH - this isn't really a hugely important function, but it's very visible, confusing and annoying, and can't be fixed with an update. In general, it looks like s-c-d needs some serious fixing for the new world order (chrony not ntpd by default, systemd handling of chrony/ntpd starting...)
I really feel like this should be a blocker - effectively ignoring timezone configuration is buggy, unprofessional, and quite annoying. If we are not going to fix this then better to disable the tz spoke in F18 anaconda IMHO, and let users configure themselves post-install - at least I am able to do that now from gnome control-center. :)
Wait, why is firstboot still doing anything related time/date?
Ah yeah ntp setup.
Yeah I see if I run system-config-date then the timezone tab canvas shows New York irrespective of the current timezone. Maybe s-c-d just ignores symlinks? I actually prefer /etc/localtime being a symlink since then it will follow tzdata updates.
*** This bug has been marked as a duplicate of bug 824033 ***
(In reply to comment #11) > > *** This bug has been marked as a duplicate of bug 824033 *** This bug is F18Beta-accepted, AcceptedNTH[1]. Does that status get transferred to bug 824033? There is now no bug related to this problem listed at: Fedora 18 Beta Blocker Bugs http://qa.fedoraproject.org/blockerbugs/milestone/18/beta/buglist [1] Comment 6
Thanks Steve, fixed.
*** Bug 856995 has been marked as a duplicate of this bug. ***