Bug 812745

Summary: systemd-nspawn, still errors because /etc/localtime is not a symlink
Product: [openSUSE] openSUSE 12.3 Reporter: Tony Su <tonysu>
Component: BasesystemAssignee: Dirk Mueller <dmueller>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: dmueller, fcrozat, jsuchome, werner
Version: Final   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 12.3   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Tony Su 2013-04-01 15:57:29 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0

The error displays as follows (path modified)

# systemd-nspawn -D /../Fedora18/
Spawning namespace container on /../Fedora18 (console is /dev/pts/7).
/etc/localtime is not a symlink, not updating container timezone.
execv() failed: Permission denied
Container failed with error code 1.

Reproducible: Always

Steps to Reproduce:
1. Setup Fedora 18 file system
2. systemd-nspawn =D <full path to Fedora18 file system

Actual Results:  
Error as described because openSUSE does not implement localtime as a symlink.

Expected Results:  
chroot should launch

I found this mailing list archive post which suggests that this problem was discovered and discussed approx Oct 2012
http://lists.freedesktop.org/archives/systemd-devel/2012-August/006258.html

I found this message which suggests that Lennart Poettering recommended a patch that tests for whether a symlink is implemented or not and was likely submitted but I do not know if it was implemented. If it was implemented, it's not working
http://cgit.freedesktop.org/systemd/systemd/commit/?id=d40361453be0525a0455d549b2b863931b069358

I don't know how many and which operating systems implement localtime symlinks although of course it's likely that all the RH derivitives likely do so... So this is a fairly significant error.

Although the workaround likely is to just create the symlink, am researching exactly what the symlink should be linked to(maybe inspect exactly what is happening on a running Fedora).

Alternative workaround likely is to use traditional chroot instead of systemd-nspawn although am working through some unrelated problems there, too.
Comment 1 Frederic Crozat 2013-04-02 11:34:04 UTC
We do support localtime as a symlink but if you upgraded an old system and didn't change timezone, the symlink isn't created.

There might still be some issue on yast not creating /etc/localtime as a symlink..
Comment 2 Tony Su 2013-04-03 02:04:55 UTC
(In reply to comment #1)
> We do support localtime as a symlink but if you upgraded an old system and
> didn't change timezone, the symlink isn't created.
> 
> There might still be some issue on yast not creating /etc/localtime as a
> symlink..

Will take a closer look at this.

Yes, the Host system is an upgrade 12.2 (fresh) > 12.3.
Comment 3 Tony Su 2013-04-03 16:58:26 UTC
Yes,
/etc/localtime was some kind of encrypted text file.
Replaced it with a symlink to /usr/share/zoneinfo/...
and seems to be working for the main Host system.

Result is no more of the original problem when invoking systemd-nspawn, just some unrelated permissions problem.

But, believe the symlink implementation has its own bug, which seems to be widely reported on Fedora...

During bootup, observed the following error just before booting into Plymouth...

fast TSC calibration failed

Seems to be a non-critical error of some sort, ironically the solution seems to be to configure localtime to point to a file instead of as a symlink...:)

So, however this issue is to be addressed(or not, should this be addressed upstream or in openSUSE especially if the symbolic link method may be imperfect today?), the problem seems to have been definitely identified.
Comment 4 Frederic Crozat 2013-05-22 12:22:38 UTC
reassigning to YaST team. 

Guys, could you make yast time&date module to create /etc/localtime as a symlink instead of a hard copy of the timezone file ? (or use timedated D-Bus api if you can to do the heavy lifting).
Comment 5 Jiří Suchomel 2013-05-24 07:48:01 UTC
YaST does not create /etc/localtime, at least not directly.

Werner, is 'zic' call (done by YaST) reponsible for its creation?
Comment 6 Dr. Werner Fink 2013-05-24 08:14:12 UTC
Indeed ... Currently we have three patches around tzcode-link.diff, tzcode-symlink.patch, and tzcode-zic.diff ... Now with /usr part of the root file system or mounted within initrd below the root file system, the default should become a symbolic link.  That is drop the copy code and make symbolic link to the default and NOT the hard link ... OK maybe timedatectl(1) is able to handle a hard link but I do not know this (guess: it does not).

Adding maintainer of Base:System/timezone to carbon copy list and re-assign
Comment 7 Frederic Crozat 2013-05-24 08:33:54 UTC
I can confirm timedatectl doesn't like hardlink and will use /etc/sysconfig/clock in that case :)
Comment 8 Dr. Werner Fink 2013-11-27 07:44:40 UTC
Why this bug has become assigned to systemd-maintainers?  This bug has to be solved in package timezone ... and maybe this one is a duplicate of bnc #845530
Comment 9 Dirk Mueller 2013-11-27 11:00:39 UTC
/etc/localtime is a symlink now on systemd distros: 

-------------------------------------------------------------------
Mon Apr 29 20:47:33 UTC 2013 - crrodriguez@opensuse.org

- /etc/localtime must be a symlink to /usr/share/zoneinfo/$TIMEZONE
  so systemd-timedated and its command line tool timedatectl
  can work correctly. Yast already does the right thing.