がとらぼ

ノートPCにChrome OS 89を入れてみた + 仮想デスクトップ

Chrome OS

前回Chrome OS 87をインストールしてから1ヶ月ほど立った頃(4月に入ってから)にバージョン(88と)89のリカバリーイメージ(13729.45.0_samus)が公開されていた。
Brunch Frameworkはr89が出てなくてr88 stable 20210223が最新だった。そこで、この2つを更新ではなく前回と同じ方法でクリーンインストールした。
ところが、動作が非常に遅くて調子悪い。ノートPCのパッドの左クリックも反応が殆どない(滅多に押されたと認識してくれない)。元のバージョンに戻そうかなと思ったとき Chrome OS 89のリカバリーイメージが更に更新されて13729.56.0_samusになり、Burnchもr89 stable 20210403がリリースされた。更に改めてクリーンインストールし直した。
結果的には何か動作が遅いのも左クリックがなかなか認識されないのもあまり変わらなかった。クリック効かないという症状は全く騒がれていないので「お前の環境だけ」所謂「おま環」というやつかもしれない。なにしろ、ChromebookではなくただのノートPCだし、必須スペックである第3世代以降intel CoreシリーズのCPUが搭載されているPCでもない。動かなくても全く文句言えない環境だし。

そのクリックが効かないというのはボタンクリックだけ。チェックボックスなどは全く問題なくポチポチできる。つまりタッチパッドのドライバと相性が悪いとかそんなんじゃなくてOS側の問題っぽい。ボタンを押しても反応しないときは何度押しても反応しない。一度ボタンの外にポインタを動かしてからもう一度ボタンをクリックすると正常に押せることが多い。または、ボタンの上にポインタを移動したとき、ボタンの色が少し薄く表示されるときなら押せば反応することが多いよう。

で、速度面を少しだけ改善＋Chrome OS 88, 89で追加された機能にも少しだけ触ってみた。

Chrome OS 89を触ってみた 1
インストールしたChrome OSのバージョンは89.0.4389.95だった。

Chrome OS 89を触ってみた 2
COGでCPUの使用状況を見てみた。CPUがCeleron B820というクソカスなので何もしていないアイドル状態でもCPU使用率25%程度？一応2コアとも使われているっぽい。

Chrome OS 89を触ってみた 3
初期設定が気に入らない3点を変更した。
Chromeブラウザを起動してURL入力欄に chrome://flags を入力して項目を探し設定を変更する。

Force Spectre variant 2 mitigation (chrome://flags#force-spectre-v2-mitigation)をDisableに変更。
インテルのCPUのバグによるセキュリティの問題を回避する修正が適用されると動作が遅くなる。超非力なノートPCを使っているので、脆弱性というデメリットを承知の上で泣く泣く無効にしてみた。(効果があるとしてもオススメはできない)

Web Platform Controls Dark Mode (chrome://flags#form-controls-dark-mode)をEnableに変更。
普通のダークモードを有効にした。ブラウザに表示されるコンテンツも含めて強制的にダークモードにするのは別設定で可だけど個人的には好きじゃないのでこの設定のみ変更。

Support showing previews of quick access screenshots, download, amd files (chome://flags#enable-holding-space-previews)をDisableに変更。
これはChrome 88か89で追加になった「tote」(トートバッグのトートね)とかいう画面の右下に最近撮ったスクリーンショットやダウンロードしたファイルや触ったファイルがアイコンになって表示されるもの。Windows 10でいえば「最近使用したファイル」みたいなのがタスクバーに表示されるようなものかしら。これは個人的にはウザいだけでありがたをが全く感じないので無効化した。

ダークモードへの変更とトートの無効化は希望どおりになったが、スペクター脆弱性回避の無効化は「気のせいか高速化したかな、してないかな？」程度の実感できない効果の割に、OSの動作が不安定になってデメリットの方が多かった。特に、OS起動時にログインパスワード入力画面が表示される直前でハングアップするのが頻発。ログインパワスードが正しく入力されているにも関わらずログイン失敗が頻発など。ログイン時前後のトラブルが多い印象。また、スリープモードからの復帰に失敗してハングアップするのも多発。脆弱になって速くならなくてトラブル多いのでは意味がないので使用したノートPCではForce Spectre variant 2 mitigationの無効化は全くマイナスでしかなかった。(設定は元に戻した)

Chrome OSの仮想デスクトップ

Chrome OS 89を触ってみた 4
Chrome OS 88で追加された?仮想デスクトップ機能を触ってみた。
仮想デスクトップの追加や選択の表示は使用したノートPCのキーボードでは[F5]だった。仮想デスクトップを2つ以上にした状態で別のデスクトップに移動するのはChromebookでは[]+[ [ ]または[]+[ ] ]となっている。おそらく普通のPC+英語キーボードであれば[]+[ [ ]または[]+[ ] ]。日本語キーボードでも普通なら英語キーボードと同じハズだか文字コードで見ていないのか英語キーボードと同じ位置のキーで機能するため[]+[ @ ]または[]+[ [ ]になるみたい。日本語キーボードの [ と ] の位置関係は縦なので使い勝手が悪いので英語キーボードと同じ位置のキー(横並び)の方が使いやすいとは思うが知らないと混乱されられる。

ROCK Pi Sを設定してみる (/var/log.hddの扱い変更)

ROCK Pi S

最近のArmbianではシステム稼働中に発生したログがzramの/var/logに書き込まれ、システム停止前に/var/log.hddにコピーし、次回システム起動時に/var/log.hddから/var/logにコピーされる。正確ではないがこんな感じ。

zramはRAMディスクなので電源を落とすと消えてしまう。しかし、ハードディスクと違ってmicroSDカードなどのNANDメモリをストレージに使用するSBCでは、発生したログをその都度直接NANDメモリストレージに追記なんてことをすると劇的に寿命を縮めてしまう。そこで先のような方法で稼働時に発生したログは逐次RAMディスクに書き込み、システム終了時などに必要に応じてmicroSD等のストレージにまとめて書き込む、このような方法が採られるようになったみたい。
個人的には稼働中に発生したログをRAMディスクに置くところまでは良いとして、システム終了時にmicroSDカードに書き出すというところが気に入らない。重要なログなら逐次外部のログサーバ(syslogサーバ)に飛ばしてしまう方が良いし、どうでもよいログなら残す必要が無いと思うから。
つまり、システム起動時に/var/log.hddの中身を/var/logにコピーする、システム停止時に/var/logのログを中身を/var/log.hddにコピーするというこの挙動が要らないと思う。特にシステム終了時の方。

RAMディスクの/var/logとmicroSDカードの/var/log.hddの間でのログファイルのコピーに関係ありそうな設定。
  • /etc/default/armbian-ramlog
  • /etc/default/armbian-zram-config
  • /etc/cron.d/armbian-truncate-logs /var/logの整理用なのであまり関係ない
  • /etc/cron.daily/armbian-ram-logging これは要らない

最後のファイルは要らないのでファイルを削除するか中の行をコメント化する。他の3つは設定を触る必要はなさそう、というか触りたいフラグなどは無い。つまり設定は触らない。

/etc/cron.daily/armbian-ram-logging (変更)
1
2
3
4
5
#!/bin/sh
#/usr/lib/armbian/armbian-ramlog write >/dev/null 2>&1
/usr/bin/truncate /var/log/lastlog --size 0
/usr/bin/truncate /var/log/btmp --size 0
/usr/bin/truncate /var/log/wtmp --size 0

個人的にはこんな感じにすることが多い。2行目は行頭に # を挿入してコメント行にする。最後のtruncateの3行はそれぞれの引数で指定しているファイルを空にしている。これが日次で実行されることになるが、利用履歴は重要だと思うならtruncateの3行は無しで。

RAMディスクの/var/logとmicroSDストレージの/var/log.hddの間でのログファイルのコピーに関する本体は /usr/lib/armbian/armbian-ramlog で、このファイルに存在するsyncToDisk()という関数が実行されるのを防ぎたい。

/usr/lib/armbian/armbian-ramlog (最後の方)
        stop)
#               syncToDisk
                umount -l $RAM_LOG
                umount -l $HDD_LOG
                ;;
        write)
#               syncToDisk
                ;;

syncToDiskという行の頭の方に # を付けてコメント行にする。他の関数はコメント化しない。特にsyncFromDiskをコメント化すると/var/logがzramのRAMディスクにならないので注意。(ログが逐次microSDカードに書かれてしまうのでとてもヤバい)

$ sudo rm -R /var/log.hdd/*

/var/log.hddの中身を消しておく。
あとは、システムを再起動するなどして/var/log.hddにログが置かれないことを確認する。ただし、armbian-hardware-monitor.log と armbian-ramlog.logは無視で。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            209M     0  209M   0% /dev
tmpfs            43M  1.5M   42M   4% /run
/dev/mmcblk0p1   29G  1.4G   28G   5% /
tmpfs           213M     0  213M   0% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           213M     0  213M   0% /sys/fs/cgroup
tmpfs           213M  4.0K  213M   1% /tmp
/dev/zram1       49M  392K   45M   1% /var/log
tmpfs            43M     0   43M   0% /run/user/1000

/var/logがzramファイルシステムであることを必ず確認する。/usr/lib/armbian/armbian-ramlogの編集を間違えるなどすると黄色の字の行が存在しない状態になる。そうなると、microSDカードの極めて脆弱な媒体のファイルシステム上に直接/var/logが作られて、そこにログファイルを追記しまくる(ブロックを消して書き直すのを繰り返す)という恐ろしい行為が行われる。TLC/QLCのカードだとあっというまに寿命を迎えることになる。

Up