Talk:Release notes/13.2.0

Clock

After installing 13.2.0 on a XO-1.5, the clock was set with:

sudo date --set="2013-10-17 7:10"

All appears well except that Gnome displays UTC rather than local time. The offset from Greenwich shown by the location under the calendar is right. How can local time be specified? --Peasthope 15:45, 17 October 2013 (UTC)

To set the time zone, start Terminal, paste this:

sudo yum install -y system-config-date

then in the Gnome menu select Applications -> Other -> System-Config-Date (Set Date & Time), select the Time Zone tab, select the city, leave System clock uses UTC set, click OK, see the Gnome clock change, click Cancel.

Alternatively, identify and copy an appropriate timezone file from /usr/share/zoneinfo to /etc/localtime:

sudo cp /usr/share/zoneinfo/Iceland /etc/localtime

Using date is slow and cumbersome. To set the time more easily, start Terminal, paste this:

sudo yum install -y ntpdate && sudo ntpdate pool.ntp.org

Your other question was moved to Talk:Releases. --Quozl 02:54, 18 October 2013 (UTC)

Good, thanks. Subsequently I read <trac>12085</trac>. Chrony will automate correction for clock drift at the cost of another background process. Will stay with your instructions until there is a consensus recommending the extra automation, ... Peasthope 15:08, 18 October 2013 (UTC)

The discussion in <trac>12085</trac> is for a future release, as the decision has scale implications for any deployment. My advice above was intended for a skilled user or developer, and is not suitable for deployment in this exact form. We have no plans right now for a future release. --Quozl 21:42, 18 October 2013 (UTC)

Release 13.2.0

No significant complaints. Nice work. Thanks, ... Peasthope 15:17, 18 October 2013 (UTC)

GVFS

UnixAos is installed as an application on this system. I start it with a script invoked in the terminal emulator. The following messages from syslogd appear and the application proceeds mostly as in other systems. Appears that gvfs is involved in the messages. I've never used gvfs elsewhere and there are no messages from syslogd when UnixAos runs on other systems. Do the messages indicate a problem? All I know about gvfs is in http://en.wikipedia.org/wiki/GVFS. How necessary is it in this system? If gvfs is removed, how badly will the system be impaired? Thanks for any reply.
Regards, ... Peasthope 21:56, 8 December 2013 (UTC)

[olpc@xo-53-1d-bb ~]$ ~/myaos
Host is xo-53-1d-bb.
HostInitial is x.
umounting /dev/GreenSDHC prior to fsck.
Message from syslogd@xo-53-1d-bb at Dec  8 10:47:22 ...
kernel:[  857.040019] Process gvfsd-trash (pid: 877, ti=e122a000 task=e11e8040 task.ti=e122a000)
Message from syslogd@xo-53-1d-bb at Dec  8 10:47:22 ...
kernel:[  857.040019] Stack:
Message from syslogd@xo-53-1d-bb at Dec  8 10:47:22 ...
kernel:[  857.040019] Call Trace:
Message from syslogd@xo-53-1d-bb at Dec  8 10:47:22 ...
kernel:[  857.040019] Code: ff ff ff 48 14 8b 40 08 a8 08 74 05 e8 b4 e3 24 00 89 d8 e8 4c 09 00 00 83 7b 2c 00 0f 84 b4 00 00 00 8b 43 1c 8b 88 f0 01 00 00 <8b> b1 18 01 00 00 85 f6 74 4d 8b 03 ba 01 00 00 00 66 25 00 f0 
Message from syslogd@xo-53-1d-bb at Dec  8 10:47:22 ...
kernel:[  857.040019] EIP: [<b04f33a7>] ext4_evict_inode+0x5d/0x3f1 SS:ESP 0068:e122bf40
fsck from util-linux 2.22.2
e2fsck 1.42.5 (29-Jul-2012)
GreenSDHC: clean, 1518/245280 files, 214701/979456 blocks
Filesystem in /dev/GreenSDHC passed fsck. Proceed with mounting.

There was not enough information in your problem report, so I shall speculate. The filesystem on your SDHC card may have a metadata inconsistency, which was detected by the kernel function ext4_evict_node, which was incidentally triggered by gvfs, removing gvfs is not recommended, further details on the error may be available from dmesg, you should check the filesystem thoroughly or recreate it. Or you may need to upgrade the kernel. Reproduce the problem on Fedora 18 on a PC and then contact the Fedora community. --Quozl 06:41, 9 December 2013 (UTC)