Ubuntu起動画面(splash画面)が崩れてしまうときは

Ubuntuが起動するときには、「Ubuntu」の文字とロゴがしばらくの間表示され、その後ログイン画面、あるいは直接ログインする場合にはデスクトップ画面へ移行する。このシンプルだが美しい画面のことを「スプラッシュ画面」(splash画面)という。

昔のLinuxディストリビューションでは、起動時にはいろいろなサービスが起動する様子が延々と表示されていたので、それに比べるとシンプルで一般向けといえるだろう。さらに、このスプラッシュ画面は、いろいろなアプリのテーマのように着せ替えることもできるので、自分が気に入ったものを利用することも可能だ。

ところが、困ったことにこのsplash画面が非常にみにくいものに変わってしまうことがある。特に、起動時に画像ではなく、文字で「Ubuntu」と表示されるようなケースがある。
これは、ビデオドライバをプロプライエタリなものに変えた場合によく発生する。典型的なのがNvidiaのドライバで、これを利用するとたいてい、文字表示に変わってしまう。
もちろん、文字表示でもUbuntuの利用に実害は発生しないが、せっかく美しいデザインを誇るUbuntuのこと、できればもとの美しいスプラッシュ画面が出てくれるようにしたい。
このようなときに、以下のような方法にすると修復が可能なようである。

以下、Ubuntu 14.04でテストしている。なお、以下編集するファイルはいずれもシステム設定ファイルなので、慎重に編集すること。また、管理者権限でないと書き込みできないので注意する。端末を開き、

sudo gedit /etc/default/grub

のようにするとよいだろう。

<その1>

  1. 最初のUbuntu起動画面(grubの画面。背景が紫色)のところで、「C」を押して起動を止める。
  2. プロンプトが出るので、ここで「vbeinfo」と入力する。
  3. 数多くの解像度の組み合わせが出てくる。例えば「640x480x32」とあれば、640×480ピクセル、32ビット解像度での表示をサポートしているということである。この中から1つを選んで記録しておく。自分のディスプレイの解像度になるべく近いもの、そしてなるべく高い解像度のものを選んでおく。
  4. 「exit」と入力してgrubの起動画面に戻るか、Ctrl+Alt+Delを押して再起動する。
  5. このままコンピュータをブートし終わったら、作業開始である。まず、grubの設定を変更する。/etc/default/grubで、以下のようにある行

    #GRUB_GFXMODE=640×480

    の次の行に、以下のように書き足す。

    GRUB_GFXPAYLOAD_LINUX=1920×1080-32

    ここで、=のあとの部分は解像度と色のビット数である。先ほど起動時に調べた解像度と色のビット数を上の数字に当てはめて書いておく。この数字を間違えるとスプラッシュ画面がうまく起動しないので、もしうまくいかない場合はgrubでの解像度と色の数値をいろいろと試し、ここの部分を書き換えてみよう。なお、解像度と色の数値はできるだけ高いもののほうがよいようだ。

  6. 次に、/etc/initramfs-tools/conf.d/splashというファイルを編集する。ここにはただ1行、

    FRAMEBUFFER=y

    とだけ書く。

  7. 以下のコマンドを実行して、initramfsへの変更を有効にする。

    sudo update-initramfs -u -k all

  8. 以下のコマンドを実行して、grubへの変更を有効にする。

    sudo update-grub

  9. 再起動し、スプラッシュ画面が出てくるかどうかを確認する。

<その2>

「その1」の方法でスプラッシュ画面が出ない時には、先ほどのファイルに書いた解像度と色の数値が間違っていないことを確認した上で、さらに次のような変更を加えてみる。

  1. 先ほどと同様、/etc/default/grubを再度編集する。今度は、

    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash”

    と出ている行の先頭に「#」を加えてこの設定を無効化し、その下に以下のように書く。以下は1行である点に注意。

    GRUB_CMDLINE_LINUX_DEFAULT=”quiet splash nomodeset video=uvesafb:mode_option=1920×1080-32,mtrr=3,scroll=ywrap”

  2. 同じく/etc/default/grubにおいて、

    GRUB_GFXMODE=1920×1080-32

    とある行があり、その先頭に「#」が入っていたら、それをとって、この行の設定を有効にする。なお、数値は先ほど述べた通り、grubでサポートされている解像度と色の数値のうち、いちばん高いものを選んでおく。

  3. 続いて、/etc/initramfs-tools/modulesファイルを編集する。このファイルの最後に、以下の1行を加える。

    uvesafb mode_option=1920×1080-32 mtrr=3 scroll=ywrap

  4. 「その1」の6.で行った、/etc/initramfs-tools/conf.d/splashファイルの作成を行っていない場合は、それを行う。
  5. 以下のコマンドを実行して、initramfsへの変更を有効にする。

    sudo update-initramfs -u

  6. 以下のコマンドを実行して、grubへの変更を有効にする。

    sudo update-grub

  7. 再起動し、スプラッシュ画面が出てくるかどうかを確認する。

<その3>
上記2つでもうまくいかない場合には、そもそもスプラッシュ画面が出せる状態になっているのかどうかを確かめよう。スプラッシュ画面を表示しているソフトはPlymouthというものである。これを実行してみる。

sudo plymouthd ; sudo plymouth –show-splash

これで画面が出るはずである。画面が出たことを確認できたら、Unityで端末を選んでおいて、

sudo plymouth quit

でPlymouthを終了する。

これで画面が出ない場合、plymouthの一部パッケージを追加する必要がある。追加して出るかどうかを確認しよう。

sudo apt-get install plymouth-x11

これで上記のPlymouth画面表示を試し、それでもダメであれば、さらに/etc/default/grubを以下のように編集する。
まず、

#GRUB_GFXMODE=640×480

という行があれば、その行の下に

GRUB_GFXPAYLOAD_LINUX=auto

という1行を加える。grubへの変更を有効にするため、update−grubを実行する。

sudo update-grub

再起動し、スプラッシュ画面が出るかどうか試して欲しい。

私の場合は、「その1」「その3」の組み合わせ、あるいは全てのケースを投入した結果うまく行っている。おそらくは「その1」「その2」だけで、解像度を正しく記述すればうまくいくかも知れないが、それぞれに違いがある可能性もあるので、上で記述した方法をいろいろ試してみて欲しい。

<参考>

6年もののネットブックを余ったSDカードで高速化してみる

いまから5〜6年前だろうか。「ネットブック」、あるいは「ミニノート」と呼ばれるコンピュータがはやったことがあったのを覚えていらっしゃるだろうか。
比較的能力の低いCPU、狭い液晶画面、小さなHDD、少ないメモリ領域という形で、性能をぐんと抑えつつ価格を5〜6万とものすごく安くしたコンピュータである。
ただ、その後間もなく登場したタブレット機器に押されて、一気に下火になり、今は店頭で見かけることもまずなくなってしまった。

さて、私の手元には、2008年9月に投入したこのネットブックがある。Acer Aspire ONE、AOA-150Bbである。
性能はといえば、

  • CPU…Intel Atom N270 (1.6GHz, デュアルコア)
  • メモリ…1GB (増設不可)
  • ハードディスク…160GB
  • プリインストールOS…Windows XP Home Edition

というものである。ちなみに、私が欲しいなぁと思っているタブレット、Xperia Z2タブレットでは、

  • CPU…Snapdragon 801 (最大2.3GHz, クアッドコア)
  • メモリ…3GB
  • 記憶容量…32GB
  • プリインストールOS…Android 4.4

と、ストレージさえ除けば処理性能は圧倒的に上回っている。もうそんなボロいネットブックなんて処分してしまえばいいとは思うのだが、そこは「もったいない」精神が働くというわけで、できる限り現役のまま使ってあげたいというのが私の気持ちである。

現在このネットブックは、Ubuntu 12.04 LTS(当然32ビット版)が動作している。以前はWindows XPとのデュアルブートであったが、XPのサポート終了に伴ってWindows領域を削除、さらにディスクパーティション構成を組み替えて、完全にUbuntu専用機になっている。
なお、さすがに処理性能を考えて、Unityは2Dとしてある。他の軽量デスクトップも考慮に入れてはあるのだが、持ち歩いて頻繁に使うこと、電源性能(サスペンド、ハイバネートのしやすさ)の問題で、重いがUnityを使用している。

で、これがどれだけ遅いのかということだが、簡単なベンチマークということで、Google ChromeとFirefoxを、起動後Unity操作可能時点で同時にクリックし、両方が起動する時間を測定してみることにした。Google ChromeもFirefoxも、数個のタブがすでに開いており、それを読み込みながら起動する設定となっている。

  • Google Chromeの画面(どこか1つ)が出てくる時間…4分10秒
  • Firefoxの画面(どこか1つのタブ)が出てくる時間…7分30秒

普通のコンピュータでブラウザ1つを立ち上げるのに7分かかっていたら処分した方がよいに決まっている。

このようにとんでもなく遅い原因はメモリ不足である。最近のブラウザであれば、数個タブを開いていれば1GBなんてあっという間に食ってしまう。つまり、ブラウザを立ち上げていると(もちろん、起動直後なので、他のプロセスも次々に起動しているが)メモリを食い、1GBを使い尽くすと、今度は仮想メモリ(スワップ)領域へのデータ移動が始まり、両方でディスクアクセスを取り合ってずっとディスクにアクセスしたままになる、という構図である。
(なお、この実験のときには、スワップのしやすさを表す数値 swappinessは通常の60から10へと変更して、よりスワップがかかりやすくしている。)

この遅いマシンを何とか改善したい。そこで目をつけたのは、使われずに自宅で放置されていた2GBのSDカードである。
Aspire ONEには2つのカードスロットがある。1つは右側にあるSDカード専用スロット、1つは左側にある、SDカードなどいろいろなカードを読み込めるマルチカードリーダースロットである。
作戦としては、このどちらかにSDカードを挿入、スワップ領域をこちらに移設して、高速なアクセスを実現させようというものである。
なお、大量のアクセス(読み書き)が発生するため、SDカードの寿命は著しく短くなってしまうが、もともと使われていなかったSDカードなので、そう惜しいという気持ちはない(もし皆さんが実践されるときには、その点よく注意して欲しい)。

作戦はこうである。

  • Aspire ONEのSDカードスロットにSDカードを挿入
  • 起動時にマウントさせるように認識、かつそれがスワップ領域であるようにする
  • スワップ領域をこのSDカードに割り当て
  • swappinessを調整してわざとスワップされやすいようにする

今回は、左側のマルチカードリーダースロットをスワップ用SDカードに割り当てた。これは、Ubuntu上では/dev/mmcblk0p1として参照することができる。
普通に挿入するとリムーバブルメディアとして認識されてしまうので、まずマウントを解除、次にディスク領域をスワップ領域として確保する。これは、Ubuntu付属の「ディスク」ツール、GParted、コマンドラインからであればfdiskなどいずれかで可能である。これらでSDカード領域をまるごとスワップ領域にする。

最後に、起動時に必ずマウントされるようにするため、/etc/fstabをちょっとだけ改良する。もしもともとスワップ領域を設けているのであれば、そのエントリーを参考に次の行を付け加える。なお、もともとあるスワップ領域の行は消さないで、先頭に「#」を入れておき、コメントで無効にする。

/dev/mmcblk0p1 none swap sw 0 0

これでOKだ。再起動するか、

sudo swapoff /dev/sda4 (デバイス名は機器によって変更すること)
sudo swapon /dev/mmcblk0p1

を実行すれば、新しいSDカード上のスワップ領域が有効になる。cat /proc/swapsにより、スワップ領域の使用状況を確認することが可能だ。一応、確認しておこう。

次は、スワップしやすくしてしまう(積極的にメモリからSDカードに「吐き出す」)設定である。これは、swappinessという数値をいじる。この値は、スワップのしやすさを表す数値で、0に近づくほどスワップしにくくなる。通常は60であり、最近の大容量メモリを搭載した機種では10や0という値をとることも珍しくないが、今回は逆に、80や90という値にしよう。これを設定するのは、/etc/sysctl.confというファイルである。ここに1行、こういうふうに記述する。

swappiness = 90

再起動してこの設定を有効にすれば、準備完了である。
それでは、どのくらい速くなったかを調べてみよう。先ほどと全く同じ設定で、起動直後にGoogle ChromeとFirefoxを起動して、両者のタブ(のうち1つ)が操作可能になる時間を測定する。まず、swappinessが60(デフォルト値)の場合。

  • Google Chrome…3分33秒
  • Firefox…2分ちょっと(10秒程度。このとき計測がうまくいかなかった)

まぁもちろんまだ遅いといえば遅いが、先ほどのケースからすれば劇的に改善された。さらに、swappinessを90とし、preloadを有効にした上で(いままではメモリが少ないので有効にしなかった)改めて測定する。

  • Google Chrome…2分40秒
  • Firefox…2分10秒

となる。Google Chromeで性能が向上しているのは、タブあたりのメモリ割り当てが多いGoogle Chromeで効果が顕著に出ていることを示していると思われる。
もちろん、Firefoxが起動して2分もかかって表示されるのはそれでもイライラするかとは思うが、起動したあとしばらく待ってマシンが落ち着いてから起動するようにするなど、運用を工夫すれば若干気分的にも改善できると思う。
なお、この時点でスワップ領域の消費量は300MBほどで、2GBのSDカードの10数パーセントである。

いろいろ書いたが、この方式は、いってみればWindowsのReadyBoostと同じような考え方で、HDDよりは高速な半導体デバイスに記憶領域を間接的に移動させるというアイディアである。
同じ考え方はデスクトップ機にも応用可能である。例えば、使用していない2GBや4GBのUSBメモリなどが余っているのであれば、それらをスワップとして割り当ててやれば、メモリが少ないマシンでも高速化の効果が出る可能性はある。

ただ、この設定で運用を行って以来、サスペンドやハイバネートが効かなくなってしまった。
サスペンドについては原因が不明である。
ハイバネートは、このSDカードの領域が足りないためと推測される(Write errorが出るのだが、SDカードそのものの検査を行ってもディスクエラーは確認されない)。そこで、ハイバネートをかけたい場合、いったん無効にしたHDD上のスワップ領域を有効にする。

sudo swapoff /dev/mmcblk0p1 && swapon /dev/sda4

これでハイバネートは元に戻るが、運用上面倒ではある。このあたり、いいアイディアがあれば追求してみたいが、もう6年ものとなっているネットブックがいつまで持つかという点も問題ではある。

【2014年8月28日追記】その後のスリープ・ハイバネート対応を別記事にまとめてみました。参考になさってください。

Xperia ZL2で日産カーウィングスを利用する

私は日産カーウィングス(2007年式の日産デュアリス、メーカーオプションのナビ使用)を利用していて、しかも結構ヘビーユーザーである。オペレーターサービスはもちろんのこと、情報チャンネルもフル活用、渋滞情報のダウンロードも行って、常に最速ルートが選択されるようにしている。

さて、日産カーウィングスを含め、こういった通信機能付きのナビは、たいていはBluetoothで接続している。
ややこしくなるので詳細は省くが、Bluetoothにはいくつかの「プロファイル」と呼ばれるものがある。いわば機能である。例えば、HSP(ヘッドセットプロファイル)は、Bluetooth経由でヘッドセット(まぁ、ヘッドフォンではあるが、場合によってはスピーカーなどということもあるだろう)を実現する。

こういった通信機能付きのナビは、大抵の場合BluetoothのDUN(Dial-Up Network Protocol.ダイヤルアップネットワークプロトコル)という、一昔前の通信をシミュレートするような通信プロトコルを使用する。ところが、 たいていの携帯、とりわけスマートフォンでは、Bluetoothには対応していても、DUNプロトコルを実装していないのである。
従って、日産カーウィングスの「携帯対応確認ページ」へ行くと、スマートフォンには一部機種を除き対応していない旨書かれている。これが、私がずっとガラケーを利用してきた理由である(もちろん、ガラケーでも対応していない機種はある。なので、事前にこの表をチェックして対応機種を購入するわけである)。

しかし、いつまでもガラケーに縛られるのもいやである。私自身とうとう我慢しきれずスマートフォンに乗り換えてしまった。機種は、auのXperia ZL2 (SOL25)である。
もちろん、日産カーウィングスのページには対応表は載っていないし(まだ出たばかりだし),おそらくDUNプロファイルは実装されていないので対応しないだろう。しかしそう黙ってカーウィングスを諦めるのはいやである。そこで考えたのは、DUNを実現するソフトウェアをスマートフォン側にインストールするという手である。

幸い、こういう、DUNを実現するアプリがいくつかある。代表的なものでは、

と、複数出ている。

今回はこの3つを試してみた。その結果、まずbt Dunはアプリを起動すると異常終了して使えない。残り2つ、BlueDunとCobaltBlue 3に絞られることになった。

両者ともお試しモードだと意外にあまり安定して通信できない。一応通信はできるようなのだが、2回続けるとつながらなかったりする。そこで、意を決してどちらか購入して試すことにした。今回はCobaltBlue 3をチョイス。こちらの方が価格が高いのだが、通信の安定性がお試し版の時点で若干上だったのと、日本人による開発のため日本語でのサポートが(万一の場合)受けられそうだ、というのが理由である。

では、インストールを始めよう。
最初に、CobaltBlue 3をインストールしておく。支払いも済ませておこう。
正式版になると、Bluetoothと連動してアプリが起動できるようになるので、アプリ内の設定からその機能をONにしておく。

まずは、カーウィングスナビ側での設定である。
スマートフォンの接続に際しては、最初に携帯電話を登録する必要がある。通常は会社を普通に選べばいいのだが、Xperial ZL2のような「au (LTE)」などという選択肢は当然2007年型デュアリスのナビには存在しない。そこで、携帯電話は手動登録する。
(追記: 多分、どの携帯電話会社、あるいは通信方法を選んでも大丈夫なような気はする。)
携帯電話は手動登録を選び、番号だけ自分の番号をセットしておく、あとの設定はいじらない。ここで、カーナビ側に表示が出て、「この状態のまま、携帯電話を操作します…」という表示が出る。まだここではスマートフォン側のBluetoothは起動しないようにする。

次にスマートフォンをBluetooth接続させる段である。この時点でCobaltBlue 3がインストールされている必要がある。
ここで、スマートフォン側でBluetoothを起動する。この時点でスマートフォン側には、MY-CARという機器と接続する(ペアリング)ためのパスワード(数字である。もし設定を変えていなければ1234)を入力する画面が出るので、間違わずに1234を入力する。このMY-CARがカーナビである。
うまく接続できれば、カーナビ側にも「携帯電話が登録されました」という表示が出る。これでOKだ。

よく間違えやすいのが、CobaltBlue 3をインストールしていない状態で接続し、アンテナが立っているので接続できると思ってしまう状態である。このアンテナは単にハンズフリーフォンでの通話が可能かどうかを示すだけであって、肝心の通信機能を意味するものではない。したがって、上記の手順を踏む必要がある。

今のところ、以下の機能については問題なく作動することを確認した。

  • 一般的な通信機能(情報チャンネル)
  • オペレーター通信(オペレーターに目的地を伝え、その情報をダウンロードし、目的地を設定)
  • 渋滞情報(定期的に取得)
  • CDタイトルの検索・ダウンロード

したがって、一般的なカーウィングスの機能はほぼ使えるといってよいだろう。

もう1つの大きな障壁は、電話帳の転送である。これはGoogleの連絡帳が転送されるのか、内蔵(ローカル)の電話帳が転送されるのかよくわからないので、まだそのままにしてあるが、いずれ試してみたいと思っている。

カーナビも、DUNを必要としない方向に向かっているようである。日産のカーウィングスは、最新のものであれば通信モジュールを内蔵しており、携帯電話やスマートフォンはあくまでハンズフリーシステムとしてだけ動作するようになっている(例えば、V37スカイラインの内蔵カーナビ)。
いずれ、このシステムに置き換えられていくとは思うが、それにはまだ多少時間がかかりそうである。それまでのつなぎとしても、あるいはスマートフォンライフとカーウィングスを両立させたい方にも、ぜひ試してみてもらいたい。