crouton 是一个通用的在 Chrome OS 系统里以 chroot 方式运行普通 Linux 系统的环境，这里我就不做介绍了，由于要测试一下我之前修改的 PPTV Kodi（XBMC） 插件，直接通过 crouton 启动 Ubuntu 14.04 trusty 系统，跟往常一样打开 Kodi 却发现没有任何反应。系统没有直接给出任何报错信息，通过命令可以看到 kodi.bin 进程在运行但一直没有看到 Kodi 媒体系统界面，查看 Kodi 的日志文件 ~/.kodi/temp/kodi.log 也看不到有用的错误信息。

接下来发现更加奇怪的是似乎 crouton 系统里所有和音频相关的程序都是启动了没有任何反应，包含 XFCE 自带的 Audio Mixer，例如我之前用的好好的 SuperTux 2 小游戏（一款类似超级马里奥的 Linux 游戏）也运行不了，通过给 SuperTux 2 启动命令加调试输出的参数可以看到：

(trusty)zzm@localhost:~$ supertux2 --verbose
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:236 PhysfsWriteDir: /home/zzm/.supertux2
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:237 PhysfsSearchPath:
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:241   /home/zzm/.supertux2
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:241   /usr/share/games/supertux2
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'config' finished after 0.001 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'tinygettext' finished after 0.094 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'controller' finished after 0.001 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'commandline' finished after 0 seconds
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:61 no support for late swap tearing vsync: No OpenGL context has been made current
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:64 no support for vsync: No OpenGL context has been made current
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:132 Using GLEW 1.10.0
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/video/gl/gl_renderer.cpp:133 GLEW_ARB_texture_non_power_of_two: 1
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:291 window  Window: Size(1280, 712) Fullscreen: Size(0, 0)@0 Area: Size(0, 0)
[INFO] /build/supertux-e4GX8V/supertux-0.4.0/src/supertux/main.cpp:305 Component 'video' finished after 0.074 seconds

从上面的输出可以看到 SuperTux 已经可以正确加载视频组件了，但似乎到了音频时就直接卡住没反应了，这时我想起看看 crouton 系统的 PulseAudio 音频功能是否工作正常：

(trusty)zzm@localhost:~$ ps ax | grep pulseaudio
 2034 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
11585 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
11944 pts/2    Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
11991 pts/2    Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
12055 pts/2    Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
13094 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
13301 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
13388 pts/2    S+     0:00 grep --color=auto pulseaudio
27624 ?        S      0:00 /usr/bin/pulseaudio --start --log-target=syslog
27630 ?        S      0:00 /bin/sh /usr/bin/start-pulseaudio-x11
27640 ?        Ss     0:00 /usr/bin/pulseaudio --start --log-target=syslog
27641 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog
27645 ?        Sl     0:00 /usr/bin/pulseaudio --start --log-target=syslog

这下才发现 Ubuntu 的 PulseAudio 音频服务已经不正常了，系统里已经启动了多个 pulseaudio 进程，但都是直接卡住无法退出的状态，我们可以看看系统日志的输出：

2016-03-26T00:44:51.253228+08:00 ERR pulseaudio[13959]: cras_client: Unknown server_state version.
2016-03-26T00:47:17.599107+08:00 ERR pulseaudio[14281]: cras_client: Unknown server_state version.

看到 cras_client 就明白了这个是之前大概了解过的 Chrome OS 音频客户端，看看 crouton 官方 Wiki 里关于音频系统的说明：

https://github.com/dnschneid/crouton/wiki/Audio

开始就说的是 crouton 系统里音频工作机制：

Audio in crouton should work out of the box, with sound control synchronized between Chrome OS and crouton. By default, audio is forwarded to Chromium OS Audio Server (CRAS), and you will be able to play audio from both Chromium OS and crouton at the same time, without problem.

也就是 crouton 系统里的音频是以 ALSA 插件方式直接通过 Chrome OS 自带的 CRAS (Chromium OS audio server) 服务器实现的，这样存在的问题就是 Chrome OS 主系统自动升级之后可能和 crouton 里已经安装的 CRAS 插件不兼容了，这样 PulseAudio 音频服务就会启动失败。

解决方法也就简单了，用最新的 crouton 脚本更新一下已经安装的 Linux 系统一般就能搞定了（请自行把下面的 trusty 换成你安装的 crouton 系统名称）：

chronos@localhost ~/Downloads $ sudo sh ./crouton -n trusty -u

提示

鉴于国内不少 Chromebook 用户没有路由器直接翻墙的条件，而 crouton 系统里又是不能直接使用 Chrome OS 的代理的，这样很多用户会在 crouton 脚本从 chromium.googlesource.com 网站下载音频程序这一步遇到被墙阻挡而更新失败的问题。

这里我安利一下我修改过的 crouton 脚本，和官方脚本的唯一区别就是通过 HTTP（HTTPS） 代理从 chromium.googlesource.com 网站下载音频程序，我已经放到 Gist 上，需要的朋友可以从此 Gist 链接 下载。

更新成功之后会看到 crouton 其实已经在输出信息的最后对这个问题做了说明,只能怪自己当初安装 crouton 系统的时候就没注意到这点了 -_-#：

Audio from the chroot will now be forwarded to CRAS (Chromium OS audio server),
through an ALSA plugin.

Future Chromium OS upgrades may break compatibility with the installed version
of CRAS. Should this happen, simply update your chroot.

另外需要说明的是如果你的 crouton 系统里安装了不止一个图形系统 target （例如我同时安装了 xorg 和 xiwi 这两个 target，默认的 xorg 是为了更好的性能，xiwi 则是为了可以直接在 Chrome OS 系统里以窗口形式运行 Linux 图形程序），那么 crouton 系统自动更新之后默认的图形系统可能会被改回来，这是你只要修改对应 crouton 系统的 xmethod 配置文件 （例如我的是： /usr/local/chroots/trusty/etc/crouton/xmethod） 就可以重新配置默认的图形系统了。

Chromebook 重新开机之后进入时间设置可以看到这样的报错信息：

Chromebook无法设置系统时间错误

之前遇到这种情况我都是傻傻的再设置下系统时间，最近准备专门看下系统时间不能正确同步的原因。

目前用户最常用的时间同步方法一般是通过广域网上的 NTP 时间服务器进行（Linux 下对应 ntpdate 命令），另一种是直接通过连接 HTTPS（TLS）服务器获取时间戳来同步时间（Linux 下对应 tlsdate 命令），这种方式相比 NTP 协议的主要优势就是更加安全了（NTP 协议可是诞生于上个世纪八九十年代的，协议本身没有任何加密认证之类的处理），另外还有一种是通过 HTTP 协议连接 Web 服务器时间来同步时间（对应 htpdate 命令，这个也算是非常通用了，具体见我之前的一篇博文 [树莓派上使用htpdate同步时间]）。

Chrome OS 默认使用的就是 TLS 方式进行时间同步，这个可以通过登录到 Chrome OS Linux Shell 中查看运行进程进行确认：

chronos@localhost / $ ps ax | grep tlsdate | grep -v grep
13799 ?        S      0:00 tlsdated -v -- /usr/bin/tlsdate -v -C /usr/share/chromeos-ca-certificates -l
13800 ?        S      0:00 logger -t tlsdate
13801 ?        S      0:00 tlsdated -v -- /usr/bin/tlsdate -v -C /usr/share/chromeos-ca-certificates -l

可以看到 Chrome OS 自带的 tlsdated 服务运行 tlsdate 程序进行时间同步，查看 tlsdate 的日志文件 /var/log/tlsdate.log 检查为什么会时间同步出错：

chronos@localhost / $ cat /var/log/tlsdate.log
2015-11-10T01:55:05.881307+08:00 NOTICE tlsdate[3050]: V: tlsdate version 0.0.5
2015-11-10T01:55:05.881395+08:00 NOTICE tlsdate[3050]: V: We were called with the following arguments:
2015-11-10T01:55:05.881445+08:00 NOTICE tlsdate[3050]: V: validate SSL certificates host = clients3.google.com:443
2015-11-10T01:55:05.888424+08:00 NOTICE tlsdate[3050]: V: time is currently 1447091705.888190273
2015-11-10T01:55:05.888485+08:00 NOTICE tlsdate[3050]: V: time is greater than RECENT_COMPILE_DATE
2015-11-10T01:55:05.895243+08:00 NOTICE tlsdate[3050]: V: using TLSv1_client_method()
2015-11-10T01:55:05.896043+08:00 NOTICE tlsdate[3050]: V: opening socket to clients3.google.com:443
2015-11-10T01:55:08.881106+08:00 INFO tlsdated[3049]: [event:action_tlsdate_timeout] tlsdate timed out
2015-11-10T01:55:08.881361+08:00 NOTICE tlsdate[3050]: [event:action_tlsdate_timeout] tlsdate timed out
2015-11-10T01:55:08.883912+08:00 INFO tlsdated[3049]: [event:handle_child_death] tlsdate reaped => pid:3841 uid:234 status:9 code:2
2015-11-10T01:55:08.884132+08:00 NOTICE tlsdate[3050]: [event:handle_child_death] tlsdate reaped => pid:3841 uid:234 status:9 code:2
2015-11-10T01:57:13.153015+08:00 NOTICE tlsdate[3050]: SSL connection failed

这下直接就明白了，tlsdate 连接 clients3.google.com HTTPS 端口进行同步，但由于众所周知的大陆 GFW 系统原罪，我们国内的 Chromebook 用户是无法同步成功的（除非已经通过 VPN 之类的进行全局翻墙了）。

解决起来也就很简单了，下面直接列出几种解决方法：

1、通过 VPN 进行全局翻墙：

这是比较方便的解决办法，直接所有流量都走 VPN 就不存在问题了，只是我不太喜欢全局翻墙的方式，会影响国内网站的访问速度；不过如果你有支持隧道分流的 Cisco AnyConnect 之类的 VPN 账户，那也完全可以用这种简单的方式；

2、修改 tlsdate 连接的服务器地址：

这种方法需要先开启 Chromebook 的开发者模式，将 tlsdate 连接的 HTTPS 服务器地址改为任何一个国内可访问的信任服务器地址，Chrome OS 下 tlsdated 服务的配置文件路径为：/etc/tlsdate/tlsdated.conf，默认内容如下：

base-path                          /var/cache/tlsdated
dry-run                            no
jitter                             0
max-tries                          10
min-steady-state-interval          86400
should-load-disk                   yes
should-netlink                     yes
should-save-disk                   yes
should-sync-hwclock                yes
steady-state-interval              86400
subprocess-tries                   10
subprocess-wait-between-tries      3
verbose                            yes
wait-between-tries                 10

# Host configuration.
source
	host clients3.google.com
	port 443
	proxy dynamic
end

# Try it without the proxy.
source
	host clients3.google.com
	port 443
	proxy none
end

修改此 tlsdated 服务配置文件需要 root 身份，切换到 root 用户后执行下面的命令可以将 Chrome OS 的根文件系统改为可写的状态（默认只读的配置文件无法修改），执行完成之后必须重启才能生效：

chronos@localhost ~ $ sudo su -
Password:
localhost ~ # cd /usr/share/vboot/bin/
localhost bin # ./make_dev_ssd.sh --remove_rootfs_verification --partitions 4
Kernel B: Disabled rootfs verification.
Backup of Kernel B is stored in: /mnt/stateful_partition/backups/kernel_B_20151110_020745.bin
Kernel B: Re-signed with developer keys successfully.
Successfully re-signed 1 of 1 kernel(s)  on device /dev/mmcblk0.

重启之后我们就可以很 happy 的将 tlsdated.conf 配置文件中默认的 clients3.google.com 改为其它服务器地址了，我是直接改为 www.net.cn 万网的主页地址，修改完成之后直接运行 restart tlsdated 命令重启 tlsdated 服务就可以马上看到效果了，Chromebook 系统时间已经正常同步过来了。

3、为 tlsdate 指定时间同步代理服务器：

相信你也看到上面的 tlsdated.conf 配置文件中的 proxy 参数了，没错 tlsdate 也直接支持通过代理服务器连接 HTTPS 服务器同步时间，如果你信不过其它的服务器，坚持要用 Google 的服务器进行时间同步，那也可以将配置文件中的 proxy 参数由 none 改为代理服务器地址，代理服务器地址的写法也比较简单，例如如果要用 Shadowsocks 的 SOCKS5 代理，则写法如下（假设 Shadowsocks 使用的本地代理端口是 8050）：

socks5://127.0.0.1:8050

修改完成之后重启 tlsdated 服务不出意外也能看到起作用咯。

刚开始没找到解决办法，SSH Tunnel 的 Google Play Store 评论里也有其它用户反映了这个问题，但作者也一直没有更新此软件，因此想了一个临时的办法就是用 SSH Tunnel 的动态 SOCKS 代理功能 + ProxyDroid 这款 App 的全局代理功能配合实现 Android 的全局翻墙功能。这样需要先关闭 SSH Tunnel 的全局代理功能，然后指定一个动态绑定端口，然后在 ProxyDroid 里指定使用 SSH Tunnel 绑定端口开启全局代理，经过实际测试可以达到效果。

后来想到明明一个 SSH Tunnel App 就可以实现的功能，现在必须安装两个 App 终究是不太好的，而且稍微了解下就清楚了 SSH Tunnel 和 ProxyDroid 的全局代理功能都是通过 redsocks + iptables 配合使用来实现的。

我们先来看看 SSH Tunnel 在启用全局代理选项并连接服务器之后生成的临时 redsocks.conf 配置文件内容：

base {
 log_debug = off;
 log_info = off;
 log = stderr;
 daemon = on;
 redirector = iptables;
}

redsocks {
 local_ip = 127.0.0.1;
 local_port = 8123;
 ip = 127.0.0.1;
 port = 9050;
 type = socks5;
}

这个文件所在路径为：/data/data/org.sshtunnel，开启 root 权限之后安装终端模拟器或者其它文件管理器都可以看到。稍加分析可以看到 redsocks.conf 配置文件是由 SSH Tunnel 中自带的 proxy_socks.sh 脚本自动生成的。

通过查看 redsocks 项目网站上的说明，这个生成的临时 redsocks.conf 似乎也是对的，但是连接成功之后通过 ps 命令却看不到 redsocks 进程，看来就是 redsocks 进程没有正常运行引起的了。

经过多番尝试修改 proxy_socks.sh 脚本以产生不同的配置文件，才发现 SSH Tunnel 自带的 proxy_socks.sh 生成的配置文件在 Android 4.4 上由于日志选项被关闭会导致 redsocks 进程异常退出（具体原因未知）。使用 root 浏览器等工具修改该脚本为以下形式（修改的行已高亮显示出来）：

#!/system/bin/sh

DIR=/data/data/org.sshtunnel

PATH=$DIR:$PATH

case $1 in
 start)

echo "
base {
 log_debug = on;
 log_info = on;
 log = stderr;
 daemon = on;
 redirector = iptables;
}
" >$DIR/redsocks.conf

   echo "
redsocks {
 local_ip = 127.0.0.1;
 local_port = 8123;
 ip = 127.0.0.1;
 port = $2;
 type = socks5;
}
" >>$DIR/redsocks.conf

  $DIR/redsocks -p $DIR/redsocks.pid -c $DIR/redsocks.conf

  ;;
stop)
  kill -9 `cat $DIR/redsocks.pid`

  rm $DIR/redsocks.pid
  rm $DIR/redsocks.conf

  ;;
esac

保存退出之后，重新开启 SSH Tunnel 的全局代理功能并连接 SSH 服务器，这时查看 redsocks 进程：

root@ASUS-A86:/ # busybox ps ax | busybox grep -i redsock
 7808 root       0:00 /data/data/org.sshtunnel/redsocks -p /data/data/org.sshtunnel/redsocks.pid -c /data/data/org.sshtunnel/redsocks.conf
 8211 root       0:00 busybox grep -i redsock

之后你就会发现处于墙外无限制的状态了。

另外还有一种解决办法就是直接把 ProxyDroid 软件中的 redsocks 二进制文件（路径为：/data/data/org.proxydroid）拷贝到 /data/data/org.sshtunnel 目录中直接覆盖，这样就不用修改脚本了，玩的开心 ^_^