Description of problem: See Bug #822200 - this needs to be resolved both in glibc and system-config-date.
Yes, with a minor caveat:
Oops. Not as minor as (empty string) :-). Anyway, I'll have to think if and if yes how I want to support separate /usr without initramfs mounting it.
Fedora no longer supports /usr without initramfs mounting it, so why would s-c-d? Is there any use case you can think of?
See also: Bug 863676 - /etc/localtime link overwritten with incorrect timezone file during firstboot
*** Bug 863676 has been marked as a duplicate of this bug. ***
*** Bug 859214 has been marked as a duplicate of this bug. ***
read/write /etc/localtime as symbolic link (#824033) only fall back to using /etc/sysconfig/clock if it is present http://git.fedorahosted.org/cgit/system-config-date.git/commit/?id=bf4da651992bc62f5249527aa438d2dab031b924 Thanks, Nils.
Nils, please transfer Blocks: and Whiteboard, when duping. Thanks.
system-config-date-1.10.0-1.fc18,python-slip-0.2.21-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/system-config-date-1.10.0-1.fc18,python-slip-0.2.21-1.fc18
(In reply to comment #9) > system-config-date-1.10.0-1.fc18,python-slip-0.2.21-1.fc18 has been > submitted as an update for Fedora 18. > https://admin.fedoraproject.org/updates/system-config-date-1.10.0-1.fc18, > python-slip-0.2.21-1.fc18 Works great. After firstboot/s-c-d runs, /etc/localtime is still a link to the timezone file I configured during installation. The date command shows the expected time and timezone. Thanks. The timestamp on the link changed. Is that expected? /etc/localtime Oct 22 10:38 /etc/localtime Oct 22 11:03 /etc/sysconfig/clock was absent. karma to follow. Tested with: $ qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC6/Fedora-18-Beta-TC6-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse Updated to stable after installing and before rebooting from the installer.
Package system-config-date-1.10.0-1.fc18, python-slip-0.2.21-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing system-config-date-1.10.0-1.fc18 python-slip-0.2.21-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16696/system-config-date-1.10.0-1.fc18,python-slip-0.2.21-1.fc18 then log in and leave karma (feedback).
The link created by system-config-date is an absolute path. The installer creates a relative path (example copied from Bug 863676): [root@localhost xfr]# ls -lF /etc/localtime lrwxrwxrwx. 1 root root 41 Oct 6 07:51 /etc/localtime -> ../usr/share/zoneinfo/America/Los_Angeles $ less -N anaconda-18.19-1/pyanaconda/timezone.py ... 51 # we want to create a relative symlink 52 tz_file = "/usr/share/zoneinfo/" + timezone.timezone 53 rooted_tz_file = os.path.normpath(root + tz_file) 54 relative_path = os.path.normpath("../" + tz_file) 55 link_path = os.path.normpath(root + "/etc/localtime") ...
(In reply to comment #12) > The link created by system-config-date is an absolute path. > > The installer creates a relative path (example copied from Bug 863676): That change was introduced here: Use ksdata.timezone and timezone module instead of anaconda.timezone http://git.fedorahosted.org/cgit/anaconda.git/commit/pyanaconda/timezone.py?id=73db213960514beb254eb9298955d41831ede3bc Posted to anaconda-patches here: [master] Rebased patches removing scdate usage https://lists.fedorahosted.org/pipermail/anaconda-patches/2012-August/000723.html
Package system-config-date-1.10.1-1.fc18, python-slip-0.2.21-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing system-config-date-1.10.1-1.fc18 python-slip-0.2.21-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16696/system-config-date-1.10.1-1.fc18,python-slip-0.2.21-1.fc18 then log in and leave karma (feedback).
Package system-config-date-1.10.2-1.fc18, python-slip-0.2.21-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing system-config-date-1.10.2-1.fc18 python-slip-0.2.21-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16696/system-config-date-1.10.2-1.fc18,python-slip-0.2.21-1.fc18 then log in and leave karma (feedback).
(In reply to comment #12) > The link created by system-config-date is an absolute path. > > The installer creates a relative path (example copied from Bug 863676): > > [root@localhost xfr]# ls -lF /etc/localtime > lrwxrwxrwx. 1 root root 41 Oct 6 07:51 /etc/localtime -> > ../usr/share/zoneinfo/America/Los_Angeles Gnome control center also creates a relative path. Verified with: control-center-1:3.6.1-1.fc18.x86_64 systemd-0:194-1.fc18.x86_64 Fedora-18-Beta-TC6-x86_64-DVD.iso updated to stable. Command-line: $ qemu-kvm -m 2048 -hda f18-test-1.img -cdrom ~/xfr/fedora/F18/F18-Beta/TC6/Fedora-18-Beta-TC6-x86_64-DVD.iso -usb -vga qxl -boot menu=on -usbdevice mouse
(In reply to comment #12) > The link created by system-config-date is an absolute path. Is that a problem?
(In reply to comment #17) > (In reply to comment #12) > > The link created by system-config-date is an absolute path. > > Is that a problem? During firstboot, s-c-d is overwriting, for no apparent reason, the /etc/localtime link created by the installer. That is a problem in itself. As for why it is a relative link, this is the best I could find: [systemd-devel] [PATCH 1/2] timedated: gather timezone from /etc/localtime sym target http://lists.freedesktop.org/archives/systemd-devel/2012-August/006329.html "man 5 localtime" shows a relative link, although the text says it can be either absolute or relative. The bottom line is that what s-c-d does is inconsistent with what the installer and systemd do. That has the potential for causing bugs ...
(In reply to comment #18) ... > "man 5 localtime" shows a relative link, although the text says it can be > either absolute or relative. Here's a link: http://www.freedesktop.org/software/systemd/man/localtime.html Name localtime — Local time zone configuration file Synopsis /etc/localtime -> ../usr/share/zoneinfo/… ...
(In reply to comment #18) ... > During firstboot, s-c-d is overwriting, for no apparent reason, the > /etc/localtime link created by the installer. That is a problem in itself. ... During firstboot, the s-c-d "Time Zone" tab is not displayed, so why would s-c-d change any files associated with it?
Created attachment 635080 [details] screenshot showing timestamps on /etc/adjtime, /etc/localtime before and after running firstboot/s-c-d (In reply to comment #20) > (In reply to comment #18) > ... > > During firstboot, s-c-d is overwriting, for no apparent reason, the > > /etc/localtime link created by the installer. That is a problem in itself. > ... > > During firstboot, the s-c-d "Time Zone" tab is not displayed, so why would > s-c-d change any files associated with it? From the timestamps, s-c-d also appears to be writing to /etc/adjtime during firstboot.
systemd has a command-line utility, timedatectl, that can set the timezone. Afer it is run, /etc/localtime links to a relative path: $ sudo timedatectl set-timezone 'America/Los_Angeles' NB: You may need to set selinux to permissive mode to get the command to actually work: $ sudo setenforce permissive man page: http://www.freedesktop.org/software/systemd/man/timedatectl.html Name timedatectl — Control the system time and date Synopsis timedatectl [OPTIONS...] {COMMAND} Description timedatectl may be used to query and change the system clock and its settings. ... Tested with: selinux-policy-3.11.1-46.fc18.noarch selinux-policy-devel-3.11.1-46.fc18.noarch selinux-policy-targeted-3.11.1-46.fc18.noarch systemd-195-2.fc18.x86_64
(In reply to comment #18) > The bottom line is that what s-c-d does is inconsistent with what the > installer and systemd do. That has the potential for causing bugs ... It doesn't really matter whether the link is relative or absolute. Relative is just a tiny bit nicer since installing Fedora into a subdirectory somehwere will result in a link that actually points to the zoneinfo inside the subdirectory rather than into the host OS.
(In reply to comment #23) > (In reply to comment #18) > > > The bottom line is that what s-c-d does is inconsistent with what the > > installer and systemd do. That has the potential for causing bugs ... > > It doesn't really matter whether the link is relative or absolute. Relative > is just a tiny bit nicer since installing Fedora into a subdirectory > somehwere will result in a link that actually points to the zoneinfo inside > the subdirectory rather than into the host OS. Thanks, Lennart. Is there a use-case where the user would not be chrooted to the subdirectory?
Update was pushed stable, closing.
system-config-date-1.10.5-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/system-config-date-1.10.5-1.fc16
system-config-date-1.10.5-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/system-config-date-1.10.5-1.fc17
system-config-date-1.10.5-1.fc16, python-slip-0.2.24-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
system-config-date-1.10.5-1.fc17, python-slip-0.2.24-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.