Description of problem: I installed Fedora 17 RC4 via the DVD. In firstboot, I selected America / New York as my time zone. I boot into my fresh desktop and it believes I'm in London. *However* the time displayed was the correct Eastern US time. It's just that the control center had london / europe listed as my location and highlighted london on the time zone map. jrb gave me a demo of the initial setup / experience code yesterday and it seemed similarly confused about the location / timezone. Not sure if it's related. Version-Release number of selected component (if applicable): firstboot-17.3-1.fc17.x86_64 control-center-3.4.1-1.fc17.x86_64
Created attachment 615606 [details] .xsession-errors: "datetime-cc-panel-WARNING **: Timezone '' is unhandled, setting Europe/London as default" After a clean F17 net install in a VM, this bug still exists. The time zone was set to America/Los Angeles during installation. The date & time dialog was bypassed in firstboot. .xsession-errors shows this line repeatedly: (gnome-control-center:1164): datetime-cc-panel-WARNING **: Timezone '' is unhandled, setting Europe/London as default On the newly installed F17 system: [joeblow@f17-test-1 ~]$ rpm -q control-center firstboot control-center-3.4.2-1.fc17.x86_64 firstboot-17.3-1.fc17.x86_64 [joeblow@f17-test-1 ~]$ rpm -qf /usr/lib/systemd/systemd-timedated systemd-44-17.fc17.x86_64 [joeblow@f17-test-1 ~]$ ls -lF /etc/localtime -rw-r--r--. 3 root root 2819 Jul 20 09:35 /etc/localtime [joeblow@f17-test-1 ~]$ date; zdump /etc/localtime Fri Sep 21 12:22:33 PDT 2012 /etc/localtime Fri Sep 21 12:22:33 2012 PDT [joeblow@f17-test-1 ~]$ cat /etc/sysconfig/clock # The time zone of the system is defined by the contents of /etc/localtime. # This file is only for evaluation by system-config-date, do not rely on its # contents elsewhere. ZONE="America/Los Angeles" Command-line: $ qemu-kvm -m 1024 -hda f17-test-1.img -cdrom ~/xfr/fedora/F17/Fedora-17-x86_64-netinst.iso -boot menu=on NB: The "Oh no!" message was displayed after firstboot and rebooting. Removing the fprintd package from a console and rebooting allowed a normal login.
Created attachment 615633 [details] /var/log/messages /var/log/messages repeatedly shows: Sep 21 13:28:26 f17-test-1 systemd-timedated[802]: /etc/localtime and /etc/timezone out of sync. [joeblow@f17-test-1 ~]$ ls -lF /etc/timezone ls: cannot access /etc/timezone: No such file or directory
Reproduced in F18 with a clean net install in a VM: control-center-3.5.92-1.fc18.x86_64 firstboot-18.4-1.fc18.x86_64 systemd-188-3.fc18.x86_64 $ qemu-kvm -m 1024 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Alpha/RC3/Fedora-18-Alpha-x86_64-netinst.iso -vga qxl -boot menu=on
This smells like firstboot writing in the wrong location, but Lennart will be able to tell you whether systemd should be reading that obsolete file (/etc/sysconfig/clock), firstboot should be writing another one.
(In reply to comment #4) > This smells like firstboot writing in the wrong location, but Lennart will > be able to tell you whether systemd should be reading that obsolete file > (/etc/sysconfig/clock), firstboot should be writing another one. Comment 1 reports that /etc/localtime is a file, not a symlink. Could that be part of the problem? Cross-reference: Bug 859217 - Please don't write out /etc/sysconfig/clock anymore
After setting the timezone to America/Los_Angeles in clean minimal F18 install from the F18-Alpha-Final DVD and rebooting to the login prompt: Script started on Tue Sep 25 15:19:23 2012 [root@localhost xfr]# ls -lF /etc/localtime lrwxrwxrwx. 1 root root 32 Sep 25 10:53 /etc/localtime -> ../usr/share/zoneinfo/US/Eastern [root@localhost xfr]# cat /etc/sysconfig/clock ZONE="America/Los_Angeles" [root@localhost xfr]# exit Script done on Tue Sep 25 15:19:46 2012 Command-line: $ qemu-kvm -m 1024 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Alpha/RC3/Fedora-18-Alpha-x86_64-DVD.iso -vga qxl -boot menu=on
(In reply to comment #5) > (In reply to comment #4) > > This smells like firstboot writing in the wrong location, but Lennart will > > be able to tell you whether systemd should be reading that obsolete file > > (/etc/sysconfig/clock), firstboot should be writing another one. > > Comment 1 reports that /etc/localtime is a file, not a symlink. Could that > be part of the problem? > > Cross-reference: > Bug 859217 - Please don't write out /etc/sysconfig/clock anymore No, it has to do with systemd not reading /etc/sysconfig/clock, and firstboot/system-config-date not writing /etc/timezone.
Systemd ignores /etc/timezone entirely, it will not be written or read by current systemd. It is all covered by /etc/localtime being a symlink and carrying this information. Systemd does not read /etc/sysconfig/clock, it's a dead file now, and will be deleted. Only /etc/localtime, which is expected to always be a symlink, matters, is read and maintained in current systemd.
Okay, does firstboot need to change here then? If /etc/localtime is a symlink I am guessing firstboot shouldn't write to it, what should firstboot do then? Should this be filed under firstboot?
If firstboot invokes system-config-date[1], then there is already this bug: Bug 824033 - RFE: Make /etc/localtime a symlink [1] Bug 856090, Comment 4 Also: Diving into Firstboot http://roottothehead.blogspot.com/2012/05/diving-into-firstboot.html
See also: Bug 863676 - /etc/localtime link overwritten with incorrect timezone file during firstboot
I am pretty sure this is fixed with more recent F18, closing. Feel free to reopen if still exists.