这两年非工作场合下我的主力电脑已经切换到 Chromebook，一直用的是 Dell Chromebook 11 这款小屏幕的笔记本，习惯了 Linux 之后 Chrome OS 用起来还是比较舒心的。

只是当我发现 Google 新推出的 Android Apps on Chrome OS 不再支持 Dell Chromebook 11 之类的老设备时（基本上所有使用赛扬 2955U 处理器的 Chromebook 都被排除了，具体可以参考 Chrome OS Systems Supporting Android Apps），虽然觉得有点不爽，但还是下定决心准备换新的 Chromebook 设备了。

刚好最近看到一款之前关注过的 Acer Chromebook 14 笔记本，确认在 Play 商店支持的设备列表中就有了兴趣了，配置虽然和老的 Dell Chromebook 11 看起来差不了多少，但主要机身也更轻薄了，屏幕也升级到 1080p 了，立马准备拿下。

基本配置

简单列一下配置：

其实除了 eMMC 闪存速度一般之外，其它方面我还是比较满意的，由于内存和闪存都是焊在主板上的，也基本没有升级的可能了，当然如果能像 Dell Chromebook 11 一样能自带读卡器就更好了。

外观

先看看 Acer Chromebook 14 的正面和背面：

这款 Chromebook 直接没有风扇，全金属的机身设计的很轻薄，两面都异常简单。

再看看打开后的 B 面和 C 面：

支持多点触控的触控板占了 C 面很大的面积，由于 Chromebook 对于多点触控现在支持的也非常好了，我用 Chromebook 时基本都不用鼠标了，键盘相比原来的 Dell Chromebook 11 手感也更好了：

充电孔和耳机插孔都在机身右侧，该 Chromebook 的所有接口都在机身左侧，下面的图也可以看看键盘效果：

使用体验

Acer Chromebook 14 拿上手开机之后还是感觉比原来的 Dell Chromebook 11 屏幕改进挺明显的，老一批 Chromebook 备受诟病的屏幕可视角度问题在这里就基本没有了，只是我发现 1080p 的屏幕默认选择的“最优”分辨率是 1536x864。

我把分辨率改为 1920x1080 的话 Chrome OS 的显示体验就比较差了，网页字体、标题栏、工具栏都显得特别小；这种情况下只能将缩放调至 125% 或者 150%，不过即使这样也只是网页显示正常了，标题栏和工具栏并没有跟进缩放。这样的显示效果甚至还不及 Windows 10 高分屏设备上的 Chrome 浏览器，鉴于 Chrome OS 对高分屏的支持也比较天残，我也只能保持默认“最优”分辨率了。

Chrome OS 必备的爬墙激活这里就不说了，激活成功之后一般就可以领取 90 天的 Play Music 和两年 100 GB 的 Google Drive 空间了。无意外的话连上网络就会有系统更新了，更新到最新的 Chrome OS 64 稳定版本，系统就已经自带新的 Play 商店支持了。

在设置中开启 Play 商店之后，如果你的梯子没什么问题的话应该就可以打开 Play 商店安装常用的 App 了，Chrome OS 自带的 Android 容器为 7.1.1 版本，相比原来的 Chrome ARC 运行时来说 App 的兼容性还是有质的提升的。

我专门测试了网易云音乐、手机 QQ 等几个原来 Chrome ARC 无法运行的 App，在新的 Android 容器中运行都没有什么问题，起码 Chromebook 上使用 QQ 除了 crouton 中运行 Wine QQ 之外终于有直接的解决方案了。

按照我平常基本用 Chromebook 浏览网页，偶尔看点 HTML5 视频的使用场景，这款笔记本还是基本能达到标称的 12 小时续航时间的，这也是 Chrome OS 相对 Windows 等系统的一大优势了。

Acer Chromebook 14 这一段时间的总体使用体验还是比较令人满意的，碰到一个未解决的小问题就是原来通过 crouton 安装的 Ubuntu 14.04 系统无法以 xorg 方式正常启动图形界面了，只能以 xiwi 窗口形式启动图形界面，更新 crouton 也没有解决，不过还好这个影响不是很大咯。

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） 就可以重新配置默认的图形系统了。

我的老宏碁 Iconia W700 平板基本配置为：

• Intel Core i3-2375M 处理器;
• 4GB 内存;
• Intel HD Graphics 3000 集成显卡;
• 平板默认分辨率 1920x1080;
• 升级的 256GB SSD.

这款机器用来跑 Chrome OS 绝对是绰绰有余的，有些网友都是用配置比较烂的 Intel Atom CPU 上网本安装 CloudReady 系统的。

CloudReady相关介绍

CloudReady 是 Neverware 公司基于 Google 开源 Chromium OS 系统开发出的操作系统，可以提供基本类似 Google 在 Chromebook 等设备上的官方 Chrome OS 系统的功能，目前提供面向个人的免费版和面向教育结构的收费版本，两种版本的比较请参考 这里，个人版本主要少了技术支持服务之类的，建议直接到 Neverware官网 下载最新的个人版本。

我写这篇文章时 CloudReady 最新个人版本是 45.1.20 版本，虽然还跟不上 Google 官方已经推出的 Chrome OS 47.0 版本，但使用起来还是没什么大碍的哦。

另外目前网上也有一些网友自己编译的 Chromium OS 系统提供下载安装，CloudReady 系统相对来说比较好的地方就是其主要方向在这方面，有一定的技术支持，使用时遇到什么问题也可以到其论坛上提问得到解答。

安装说明

将下载到的 zip 压缩文件解压缩会得到一个 5GB 左右的镜像文件，准备一个容量为 8GB 以上的 U 盘（如果你的电脑有 USB 3.0 接口的话那强烈建议使用 USB 3.0 U 盘，会明显提升 CloudReady 系统速度），使用镜像写入工具直接将解压缩出来的镜像文件写入 U 盘即可（Windows 上可以使用 Win32 Disk Imager 之类的工具，Linux 等系统上可以直接使用 dd 命令写入）。

写入完成之后重启电脑，并将电脑设置为从 USB 启动，这样就可以直接引导并体验 CloudReady 系统了，系统主界面如下：

可以看到 CloudReady 系统界面和 Chrome OS 基本没有任何区别，启动完成之后可以在右下角菜单中选择 “Install CloudReady…” 将 CloudReady 系统直接安装到硬盘。

注意

由于 CloudReady 系统暂时还不支持多系统启动功能，通过 Install CloudReady 功能将 CloudReady 系统安装到硬盘会直接擦除掉硬盘的原有数据，如果需要保留硬盘上的原有系统请注意谨慎操作。

不过我可没有打算把我的平板上的 Win10 系统直接擦除掉用 CloudReady Chrome OS 系统，还是准备直接用 USB 3.0 U 盘体验 Chrome OS，这样也比较方便。

我安装 CloudReady 系统时使用的是 16GB 的 U 盘，但启动起来之类才发现 CloudReady 默认留给 home 用户的空间差不多就 1GB（U 盘多余的空间并没有利用到），对于我这种安装了很多 Chrome 插件和 App 的人来说，开机激活并自动同步所有软件和 Chrome 配置之后就已经开始报空间不足了，所以这里强烈建议在第一次启动之间直接按照下面的步骤先扩容 home 用户空间方便使用。

Chrome OS 的 home 用户空间是专门存放登录用户的配置文件、历史记录、浏览的缓存数据、安装的扩展和 App 等私人数据的单独分区，Chrome OS 上默认唯一可写的专用下载目录也在此空间中，home 用户空间大小可以在 Chrome OS 自带的 文件 App 中查看到。

U 盘用户空间扩容

这一步由于需要直接扩容 U 盘分区，所以最好在 Linux 系统（也可以使用安装了 crouton 的 Chromebook）下操作，在任何一个普通 Linux 系统下插入 U 盘，使用 parted 命令的 p 打印命令可以看到安装了 CloudReady 系统的 U 盘（设备名为：/dev/sda）分区布局如下：

(trusty)root@localhost:/home/zzm# parted
GNU Parted 2.3
使用 /dev/sda
欢迎使用 GNU Parted! 输入 'help'可获得命令列表.
(parted) p
Model: Teclast CoolFlash USB3.0 (scsi)
磁盘 /dev/sda: 15.7GB
Sector size (logical/physical): 512B/512B
分区表：gpt

数字  开始：  End     大小    文件系统  Name        标志
11    32.8kB  8421kB  8389kB            RWFW
 6    8421kB  8422kB  512B              KERN-C
 7    8422kB  8422kB  512B              ROOT-C
 9    8422kB  8423kB  512B              reserved
10    8423kB  8423kB  512B              reserved
 2    10.5MB  27.3MB  16.8MB            KERN-A
 4    27.3MB  44.0MB  16.8MB            KERN-B
 8    44.0MB  1118MB  1074MB  ext4      OEM         msftdata
12    1185MB  1202MB  16.8MB  fat16     EFI-SYSTEM  启动
 5    1202MB  1204MB  2097kB            ROOT-B
 3    1204MB  4387MB  3183MB  ext2      ROOT-A
 1    4387MB  5461MB  1074MB  ext4      STATE       msftdata

从上面的结果我们可以看到用户空间正是 U 盘上序号为 1 的分区（文件系统类型为：ext4，实际对应设备为：/dev/sda1），只不过刚好在分区表上是最后一个，不过其实这也是非常好的地方，这样我们可以直接对序号为 1 的分区进行扩容而不影响其它分区。

下面使用 parted 的 resizepart 命令对序号为 1 的分区进行扩容并验证：

提示

老版本的 parted 并不支持 resizepart 命令，如果你在 parted 中运行 resizepart 提示不支持的话那就需要升级 parted 软件包了。

(parted) resizepart 1 -1
(parted) p
Model: Teclast CoolFlash USB3.0 (scsi)
磁盘 /dev/sda: 15.7GB
Sector size (logical/physical): 512B/512B
分区表：gpt

数字  开始：  End     大小    文件系统  Name        标志
11    32.8kB  8421kB  8389kB            RWFW
 6    8421kB  8422kB  512B              KERN-C
 7    8422kB  8422kB  512B              ROOT-C
 9    8422kB  8423kB  512B              reserved
10    8423kB  8423kB  512B              reserved
 2    10.5MB  27.3MB  16.8MB            KERN-A
 4    27.3MB  44.0MB  16.8MB            KERN-B
 8    44.0MB  1118MB  1074MB  ext4      OEM         msftdata
12    1185MB  1202MB  16.8MB  fat16     EFI-SYSTEM  启动
 5    1202MB  1204MB  2097kB            ROOT-B
 3    1204MB  4387MB  3183MB  ext2      ROOT-A
 1    4387MB  15.7GB  11.3GB  ext4      STATE       msftdata

可以看到序号为 1 的分区已经扩容为 11.3GB 了，但实际底层的 ext4 文件系统还没有扩容，扩容 ext4 文件系统之前需要先用 e2fsck 命令检查文件系统：

(trusty)root@localhost:/home/zzm# e2fsck -f /dev/sda1
e2fsck 1.42.9 (4-Feb-2014)
第一步: 检查inode,块,和大小
第二步: 检查目录结构
第3步: 检查目录连接性
Pass 4: Checking reference counts
第5步: 检查簇概要信息
STATE: 30211/65536 files (0.3% non-contiguous), 228239/262144 blocks

完成之后再使用 resize2fs 命令扩展 U 盘上序号为 1 的分区的文件系统：

(trusty)root@localhost:/home/zzm# resize2fs /dev/sda1
resize2fs 1.42.9 (4-Feb-2014)
Resizing the filesystem on /dev/sda1 to 2755852 (4k) blocks.
The filesystem on /dev/sda1 is now 2755852 blocks long.

没什么意外的话 resize2fs 操作将能很快完成，此时 U 盘上 home 用户空间的扩容也就完成了，可以重启用 U 盘引导计算机进入 CloudReady 系统了。

安装 Flash 插件

CloudReady 系统在第一次激活启动的时候就会提示你安装 Adobe Flash 插件，如果你身在墙外或者全程 VPN 的话点击继续应该可以直接安装成功。

如果启动时提示安装 Adobe Flash 插件时安装失败（被墙阻挡是国内用户安装失败的主要原因，因为 Flash 插件需要从 Google 网站上下载 Chrome Linux 安装包），也可以进入系统之后在 Shell 环境下手工安装。

CloudReady 安装 Flash 插件的脚本在 /opt/neverware/check_or_install_flash.py 路径下，查看其中的代码可以发现其从这个网址下载 Chrome Linux 安装包并自动解压缩出 Flash 插件文件安装到当前系统 /opt/google/chrome/pepper 中：

https://dl-ssl.google.com/linux/direct/google-chrome-stable_current_i386.deb

我们可以在浏览器中手工下载该文件，并修改 check_or_install_flash.py 文件中的 deb_path 为实际下载到的文件的路径，例如：

deb_path = "/home/chronos/user/Downloads/google-chrome-stable_current_i386.deb"

提示

CloudReady 系统下 home 用户路径为 /home/chronos/user，这一点和 Chrome OS 有点不一样（Chrome OS 路径中会附加随机生成的用户 ID），/home/chronos/user/Downloads 即为用户下载目录路径。

之后再到 Shell 终端中手工运行 check_or_install_flash.py 应该就可以正确安装了，完成之后最好重启下系统使 Flash 插件生效。

使用体验

经过一段时间的实际使用，我发现 CloudReady 还是基本达到了其宣称的类似 Chromebook 体验的，系统界面看起来和 Google 官方 Chrome OS 基本没什么区别，在一般的 PC 机上使用起来也挺流畅的，使用 Google 账户登录之后原先在 Chromebook 或者 PC 端 Chrome 浏览器上使用的所有书签、历史记录、插件和 App 都可以自动同步过来，我之前发布的 Chrome OS 下的 快盘文件系统 App 使用起来也没什么问题。

下面总结一下我个人认为的 CloudReady 系统目前的优劣之处：

优点：

• 无缝支持 Google 账户并同步;
• 支持 Android Runtime，可以运行一些 Android App;
• 新版本增加了 Netflix 等相关支持;
• 免费个人版本直接支持 mp3、mp4（H264）硬件解码;
• 支持单独安装 Adobe Flash 插件;
• 相对完善的社区支持.

缺点：

• Evernote（印象笔记）等需要 Chrome OS 的 App 无法运行（提示与设备不兼容）;
• 底层仍然是 32 位 x86 Linux 系统，最大只能使用 4GB 内存;
• CloudReady 不支持直接的在线更新.

当然实际使用感受还是见仁见智的，欢迎各位安装 CloudReady 系统进行测试咯，文章中有任何问题欢迎提出指正，祝玩的开心~~~

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 服务不出意外也能看到起作用咯。

KeePass 目前相对也有个劣势就是浏览器插件功能不强，基本都需要配合 KeePass 客户端软件使用，好在 KeePass 也支持 Windows、Mac OS X、Linux、Android、iOS 等各种操作系统，可惜目前在 Chromebook 这种不能直接运行客户端软件的系统上使用时会有一些障碍。LastPass 由于是通过 Chrome 浏览器扩展直接在线同步的没有这个问题，而你如果是 Chromebook 和 KeePass 的重度用户，那还是相当不便的。

有关 KeePass 的详细介绍和原理请参考其官方网站：http://keepass.info/。

经过初步研究，这里我列出几种在 Chromebook 上使用 KeePass 的方法供读者参考：

• Crouton + keepass2 + chromeIPass：

这个方法可能暂时只适用于使用 x86 处理器的 Chromebook，Chromebook 上可以使用 Crouton 安装基本完整的 Linux 系统，安装完成之后可以直接在 Linux 系统中安装 keepass2 软件包（比较新的 Linux 系统软件源中一般会自带这个的），并从 KeePass 官网下载启用 KeePassHttp 插件，这样就可以在 Chrome OS 系统里安装 chromeIPass 扩展愉快的使用 KeePass 密码数据库了。

这里就不详细介绍 keepass2 软件如何安装，chromeIPass 扩展如何使用之类的了。无奈由于目前 armhf 版本的 Linux 系统自带的 mono （KeePass 图形程序依赖开源的 mono .NET 开发环境）版本的问题，armhf 下的 keepass2 可以安装但无法正常运行。

笔者在目前使用的三星 ARM Chromebook 安装的 Ubuntu 14.04 版本上就无法正常运行，将 Crouton Linux 系统升级到最新的 Ubuntu 15.04 或者 15.10 等系统（自带的 mono 环境已经升级）有可能能正常运行，这里没有继续尝试了。

• CKP Chrome 扩展程序：

CKP （KeePass integration for Chrome）是 Chrome 应用商店里的一款 KeePass 嵌入式扩展程序，安装之后导入 KeePass 数据库就可以实现访问网站时自动填入用户名和密码，可惜就是 CKP 只能以只读方式使用 KeePass 密码数据库，如果数据库文件变化了只能重新导入（Chromebook 上还没有太好的办法能直接修改密码数据库文件）。

CKP 同时功能上也存在限制：无法完整浏览密码数据库里的全部条目，如果某个服务密码存在密码数据库里但不能直接通过 Chrome 浏览器访问这样就没法取出密码了。

• BrowsePass Chrome 应用：

BrowsePass 则是另一款独立的 Chrome Packaged App，因此不能实现根据当前浏览的网页自动填写用户名和密码的功能，这个 App 目前对密码数据库文件支持文件好，可以完整浏览全部目录和条目，可以复制密码到相应的网页，但是仍然还有一个主要问题：BrowsePass 目前也只支持只读方式打开密码数据库，作者说后续可能会增加写数据库支持，但不保证什么时候能加入的。

• Chrome ARC + KeePassDroid：

这个是目前我正在使用的方法，主要这种方式完全支持对密码数据库的各种写入操作，不需要另外运行一个 Crouton Linux 系统，而且这也是比较通用的方法哦，不只是能在 Chromebook 下使用，其实也可以直接在 Windows、Linux 等其它安装了普通 Chrome 浏览器的系统下使用。

Chrome 现在支持通过 ARC（App Runtime for Chrome） 直接运行 Android 程序，虽然目前兼容性还不是特别好，但 KeePassDroid 这种没有使用 NDK 代码的简单 Android 应用还是完全支持的。

首先安装 ARC Welder Chrome 应用，安装完成之后会自动安装其依赖的 App Runtime for Chrome 运行环境，然后从网上下载 KeePassDroid 的安装 apk 文件，打开 ARC Welder 应用加载对应的 apk 文件将其转换为 Chrome 应用，不过需要注意的是转换的时候必须启用剪贴板访问权限，而且记得增加这个参数：

{"enableExternalDirectory": true}

启用外部 SD 卡目录访问权限，这样转换出来的 KeePassDroid Chrome 应用才可以正常打开 KeePass 密码数据库文件，具体如下图所示：

ARC Welder 转换 KeePassDroid

然后点击 Download ZIP 按钮保存成 zip 文件，并将 zip 文件解压缩并在扩展程序界面加载为 Chrome 应用。

第一次启动 KeePassDroid 应用时 Chrome OS 系统会提示你选择一个 SD 卡目录，选择之后会让你选择密码数据库文件路径，只要把你的 KeePass 数据库文件放到对应的路径打开即可，例如我使用的路径就是这样：/storage/sdcard/Download/zzm.kdbx。

选择密码数据库文件之后输入你的数据库主密码，KeePassDroid 就会列出数据库里的所有目录和条目，进入一个任何条目，KeePassDroid 会自动弹出通知消息提示你复制用户名和密码，这样就可以正常在各类网站上使用 KeePass 密码咯。

后记：

目前 GitHub 上的 Pascal Mathis 开发了一款基于 Node.js 的 KeePass 库：keepass.io，这个 Node.js 库实现了完整的密码数据库读取和写入功能，在和开发者简单沟通之后，有想法在后面有空时基于 keepass.io 将其完整功能改为通过 Chrome Filesystem 等 API 实现从而不依赖 Node.js，这样能以单独 Chrome App 的形式使用 KeePass 密码数据库。只是在发现 KeePassDroid 能正常使用的情况，这个就当作后面有空时的一个念想再说咯～～～ 祝各位玩的开心。 ^_^

想到平时经常用的快盘（原金山，现已被迅雷收购）云存储，因此最近参考了快盘 API 和 Chrome OS 相关文档之后花费了些时间使用纯 JavaScript 开发了一款 Chrome OS 下的快盘文件系统。

下载安装

建议直接从 Google Chrome 应用商店安装本应用，这样以后可以自动升级 App：

https://chrome.google.com/webstore/detail/kkjodkkaeoeogphajdfbgcbmohpkemjd

此 Chrome 应用只支持 Chrome OS 或者 Chromium OS 操作系统，例如 Chromebook 笔记本、Chromebox、Chromebase 一体机等设备，不支持 Windows 等普通桌面或移动操作系统上的 Chrome 浏览器。

安装运行的 Chrome OS 系统版本需要至少 40.0 版本以上，为达到更好的使用效果，建议始终更新至最新版本，下面将详细说明。

如果您不能方便的访问 Google Chrome 应用商店，那也可以直接访问此项目的 GitHub 主页并检出代码本地安装（本地安装步骤这里就不详述了）：

https://github.com/zohead/kuaipan-chromeos/

使用介绍

安装成功之后在 Chrome OS 应用程序启动器或者扩展程序界面中启动快盘文件系统就会出现下面的主界面：

界面非常简单，只有 挂载快盘、断开快盘 两个操作，点击 “挂载快盘” 按钮稍等片刻就会弹出快盘官方网站授权快盘应用的界面，输入您的用户名和密码登录并授权给 快盘 for Chrome OS 应用即可。

挂载完成之后主界面会自动隐藏并弹出 Chrome OS 文件管理器应用，自动显示快盘的文件列表：

当前初始发布的 0.1.1 版本实现了基本的文件操作功能，文件和文件夹的创建、删除、重命名、下载、上传都支持，不支持文件共享、协助等 Chrome OS 本身并不支持的功能。

挂载完成之后快盘里存储的图片、PDF、Office 文档等 Chrome OS 系统直接就支持的文件可以直接在文件管理器 App 中双击打开，H264 等标准格式的视频也可以在文件 App 中直接双击打开实现在线播放效果：

使用限制

需要注意的是由于快盘开放 API 的限制，此 App 当前存在以下限制：

• 暂时支持上传最大 300MB 的文件；
• 不支持从非 0 的位置写文件或者将文件 truncate 为非 0 大小（快盘未开放续传上传 API，对正常使用影响不大，除非某些 Chrome App 需要从非 0 位置写文件）；
• 同样由于快盘未开放续传上传 API，文件上传的实际写入操作只能在关闭文件的时候（即上传完成时）进行，这将导致写完成之后要等一会才能真正上传完成；
• 如果上传的文件比较大那需要额外等待一段时间，中间会出现上面视频播放图片中的超出预期时间的提示框，此时不要点取消按钮，直接不用管它，等上传实际完成即可，如果上传失败会报错；
• 其它快盘用户共享给您的协作文件夹不会在文件列表中显示；
• 不支持查看文件历史版本功能，需要在网页端或者 PC 客户端中查看。

据说快盘 API 有每天 5000 次的调用次数限制，我自己测试没有达到这个限制，如果有其它用户使用此 App 真的导致用不了了我会尝试联系快盘调大 API 调用次数限制。

缩略图问题

Chrome OS 文件 App 中显示文件列表时支持以缩略图形式显示，这个对于照片文件夹特别有用，但是 Chrome OS 44.0 以下版本的文件 App 存在 Bug，低版本对于图片文件夹并没有请求缩略图信息，而是直接读取文件夹中每个图片文件完整数据并显示为缩略图，这样会导致访问照片文件夹速度比较慢（有时会出现上面在线视频播放中的超时提示）。这个问题由于是文件 App 的问题，无法直接解决只能更新 Chrome OS 版本。

这个是以缩略图形式显示存储在快盘里的照片文件夹效果：

其它

如果在使用中发现什么问题欢迎在我的 GitHub 项目主页上提交 issue，出现的 Bug 我会尽量解决：

https://github.com/zohead/kuaipan-chromeos/issues

祝玩的开心 ^_^

后来看到国外有人推荐了好几款 Chrome OS 下的编辑器 App，例如 Zed 之类的，最后综合比较之后还是决定用 Caret 编辑器，在 Windows Chrome 上安装 Caret App 之后用起来确实是非常不错的，但比较意外的是在三星 Chromebook 上使用时却发现有两个比较严重的问题：

1、键盘输入的时候光标位置不对，输入的字符越多光标就越向后偏移，这样造成在 Caret 下根本无法选择文字，查找替换之类的也很麻烦；

2、使用 Chromebook 自带的中文输入法输入中文的时候会出现选择候选词之后候选词的最后一个字总会被截掉的问题，例如输入“中文”这两个汉字组成的词，选择候选词之后就只有一个“中”字了，如果只输入一个汉字就会出现死活都显示不出来的诡异现象。

出现这两个问题之后我尝试过在 Caret 的 GitHub 网页上提交新的 issue，但作者只是说应该是 Caret 用的 ACE 编辑器处理的问题，作者无力解决。

经过一番查找尝试，光标显示的问题才找到办法解决。Caret 用的 ACE 编辑器只支持等宽字体，而 Chromebook 上默认用的 Noto Sans 也是等宽字体，无奈我在 Caret 中修改用户配置把字体修改为各种其它 Chromebook 自带的等宽字体（monospace 等等）都不起作用，最后多番尝试才发现 Chrome OS 早期使用的 Cousine 字体没有这个问题，在 Caret 的 “设置” - “用户偏好” 中修改为：

"fontFamily": "Cousine"

这样就可以了，保存之后无需重启程序 Caret 会自动使用新配置。

后来再经过尝试之后发现把 Windows 系统上的宋体这一经典的等宽字体拷贝安装到 Chromebook 上之后并指定使用 SimSun 宋体也不会出现这个问题，如果想显示成宋体的效果可以手工安装字体的（不过这需要启用 Chrome OS 的开发模式才行的哦）。

另外一个输入中文被截掉的问题，所幸在 ACE 编辑器的 issue 里看到了有中国用户报了类似的问题（虽然体现和解决方式不太一样），这个需要修改 Caret App 里的 ACE JavaScript 编辑器代码才行。

这里还是需要启用 Chrome OS 的开发模式，启用之后按 Ctrl + Alt + T 键打开 Chrome OS 的 Shell，进入这个目录（1.5.4_0 是 Caret 插件的实际版本，实际替换下就行）：

~/Extensions/fljalecfjciodhpcledpamjachpmelml/1.5.4_0/js/ace

用 vi 之类的其它编辑器打开该目录下的 ace.js 文件，找到下面这一段 JavaScript 代码：

        } else if (data == PLACEHOLDER.charAt(0)) {
            /*if (afterContextMenu)
                host.execCommand("del", {source: "ace"});
            else // some versions of android do not fire keydown when pressing backspace
                host.execCommand("backspace", {source: "ace"});*/
        } else {

直接注释掉上面高亮显示的第 2 - 5 行（就是这个 else if 代码块里的所有代码咯）。

ace.js 文件修改完成之后保存退出，然后重新打开 Caret App 就会发现中文输入问题也解决了。

另外需要说的是光标位置显示的问题在 Zed 等其他几个 Chrome 下的编辑器 App 里也是存在的，估计都是由于用的 ACE 编辑器引起的，但这个问题似乎在其它 x86 Chromebook 上好像也没出现过。如果本文中有任何问题还请提出指正哦，祝 Chromebook 用的开心 ^_^。

由于 Chromebook 底层使用的还是 Linux 内核，装了 Crouton 插件之后可以在 Chromebook 里以 chroot 的方式跑另外的 Ubuntu 系统，只不过 Chromebook 自带的内核模块有些缺失，比如我需要的 binfmt_misc 和 cifs 模块都是没有的，特别是很有用的 cifs 模块用于挂载 Windows 机器上的共享目录。因此想自己编译 Chromebook 的 kernel 加入需要的内核模块。

三星 Series 3 ARM Chromebook 自带的 16GB SSD 毕竟有点小，ARM 系统里装一堆开发环境还是嫌麻烦，还有比较重要的一点是国内的网络环境 git clone 出 Google Source 上的 kernel 源代码速度实在是太慢了，于是就想着用之前注册的 Koding 云端开发平台上跑交叉编译器来编译 Chromebook 的 kernel。

Koding 云端开发平台默认自带了 Node.js、Python、Ruby、Go 等开发环境支持，Koding 默认给了一个很强大的 Web IDE 编辑工具，可以在 Web 上直接登录 Shell 操作，而且 Koding 提供的 Linux 虚拟环境默认就安装了 gcc、Makefile 等工具，其免费套餐提供的 1GB RAM、3GB 硬盘空间用来编译 kernel 也勉强够用了。

先在 Chromebook 里按 Ctrl +Alt + T 键切换到 crosh Shell 里确认当前 kernel 版本：

chronos@localhost / $ cat /proc/version
Linux version 3.8.11 (chrome-bot@build44-m2) (gcc version 4.9.x-google 20140827 (prerelease) (4.9.1_cos_gg_2f9796c_4.9.1-r82) ) #1 SMP Sat Mar 7 06:47:35 PST 2015

可以看到现在用的是最新 Linux 3.8.11 版本，从 Google 官方提供的 kernel 版本库里确认需要使用的 kernel 分支：

https://chromium.googlesource.com/chromiumos/third_party/kernel/

我需要的 3.8.11 版本就可以直接使用 chromeos-3.8 分支，现在可以 SSH 远程登录到 Koding Linux 系统上，幸运的是我们还可以在 Chromebook 安装 Secure Shell 这一牛叉 App 直接进行 SSH 登录，Secure Shell 支持 Koding 的 SSH 证书（需要自己登录到 Koding 的 Web Shell 里生成哈）形式，不过选择证书时需要注意把公钥和私钥文件同时选上。

Koding 云端开发平台默认使用的是 Ubuntu 14.04 LTS 64 位系统，这样也比较好，ARM 交叉编译器安装起来也很方便了，先 clone 出 kernel 源代码：

git clone https://chromium.googlesource.com/chromiumos/third_party/kernel -b chromeos-3.8

然后运行 sudo apt-get install gcc-arm-linux-gnueabi 安装交叉编译器，Ubuntu 提供的 ARM gcc 编译器是 4.7.2 版本。

接着需要把 Chromebook 当前的 kernel 配置导出来，在 Chromebook 上切换到 Shell，运行 sudo modprobe configs 命令，然后拷贝 /proc/config.gz 文件并解压缩，通过 scp 命令将解压缩出来的 config 文件拷贝到 Koding Linux 系统中。

在 Koding Linux 系统中进入刚才 clone 出来的 Linux kernel 源代码目录，将 Chromebook 上拷贝过来的 config 文件重命名为 .config，然后运行下面的命令进行 kernel 配置：

cd ~/kernel
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig

我们可以在 Network Filesystem 中启用 cifs 模块，同时可以启用 binfmt_misc 模块，保存 kernel 配置，运行下面的命令直接开始内核编译：

cd ~/kernel
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-

如果你不想编译完整的 Chromebook kernel，也可以使用这两个命令只编译需要的 binfmt_misc 和 cifs 模块，这样可以节省时间：

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- M=fs/cifs
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- fs/binfmt_misc.ko

需要注意的是这样编译出来的 cifs.ko 模块文件还是依赖 md4.ko 文件（会自动编译出来）的。

下面就是通过 scp 把编译出来的 cifs.ko、md4.ko、binfmt_misc.ko 文件拷贝到 Chromebook 系统中，我们可以将这 3 个文件放到 Linux 内核模块目录中（不过这一步需要在 Chromebook 的开发模式中禁用 Chrome OS 的 rootfs 分区锁定功能）：

mkdir /lib/modules/3.8.11/kernel/fs/cifs
mv cifs.ko /lib/modules/3.8.11/kernel/fs/cifs
mv binfmt_misc.ko /lib/modules/3.8.11/kernel/fs
mv md4.ko /lib/modules/3.8.11/kernel/crypto

然后可以运行 sudo depmod -a 命令让系统自动生成内核模块依赖关系。

需要注意的是如果你把新编译出来的 ko 模块文件放在不是 rootfs 分区里（未禁用 Chrome OS 的 rootfs 分区保护等情况），这样 insmod binfmt_misc.ko 等命令加载模块会报错失败：

Chromium OS LSM: init_module denied module="/home/chronos/user/Downloads/binfmt_misc.ko" pid=12499 cmdline="insmod binfmt_misc.ko"

这是由于 Chrome OS 默认做了限制即不允许加载放在 rootfs 分区以外的文件系统上的内核模块文件，我们也可以运行下面的命令解除这个限制：

echo 0 > /proc/sys/kernel/chromiumos/module_locking

当然如果你将模块拷贝到上面提到的标准内核模块目录中的话就不会有这个问题了。

经过测试这样的方法编译的模块使用起来还是没有问题的，当然还是有一个不爽之处就是如果 Chrome OS 升级之后内核版本也升级了，但这些模块也需要重新编译了，文中有任何问题还是欢迎提出指正哦，祝玩的开心 ^_^