【Ubuntu日和】【第18回】Ubuntuが起動しなくなった時にストレージ全体を退避する方法

PCは何もしなくても壊れるものだ

　新年あけましておめでとうございます。

　年末年始の間は、鳶目兎耳で知られる読者の皆様も、きっとUbuntuを使っていろいろ遊んでいたのではないかと思う。そこで今回は遊びすぎた結果、うまく動かなくなったUbuntuの対処方法について紹介しよう。本当は新年一回目とあっておめでたい話がしたかったのだが、「Ubuntuに関連した景気の良い話」を思いつかなかったのだ。むしろ逆に特定の人にとっては、新年早々胃が痛くなる話になってしまい申し訳ない。

トラブルはあなたを強くする
Ubuntuが起動しなくなったら
Liveシステムを使ってストレージ全体を退避する
Liveシステムを使って一部のデータを退避する
ストレージイメージからデータを取り出す
次回はログインできなくなった時などの対処法
1. 共有:
2. 関連

トラブルはあなたを強くする

　世の中には「何もしていないのにトラブルに巻き込まれる系」の人が存在する。たとえばハードウェアを買ったら高確率で初期不良をひいてしまうとか、ソフトウェアを使おうとしたらなぜかレアなバグを踏んでしまうとか。そこまでいかないにしても、個々のタイミングの悪さや運の悪さに起因して、「何もしていないのに壊れた」は現実に起こりうると思って良い。

　よってUbuntuに限らず常日頃からトラブルに遭遇した時を意識して使い続けることも大事だし、いざトラブルに遭遇したとしても大象兎径に遊ばずの気持ちで鷹揚に構えよう。それに、どんな形にせよトラブルに対する解決はあなたの血肉となる。よってトラブル遭遇時は兎兵法に頼らず、「正しい解決方法」を調べ、それを実践することも肝要なのだ。今回はそんな「正しい解決方法」のうち、まずはやっておくと安全な「ストレージの退避方法」を紹介しよう。

　とは言え、時間がない時にトラブルに遭遇するのは避けたいところ。普段からトラブルに遭遇しにくくなるポイントは次のとおりだ。

余計なパッケージを同じマシンにたくさんインストールしない
設定変更の際の手順を文書化しておく
何かあったときにすぐに復旧できるようにバックアップをとっておく

　どれも「当たり前」の話ではあるのだが、トラブルに遭遇しやすい人はこれができていないことが多い。

　まず1点目の 「余計なパッケージを同じマシンにインストールしない」 点について。Ubuntuにしろその他のOSにしろ、1台のマシンにいろいろなソフトウェアをインストールすることで、自分にとって便利なマシンへと進化できる。しなしながらあまりにも大量のパッケージを入れすぎると、たとえば起動に時間がかかったり、他の機能とバッティングしたりといろいろなトラブルの元になってしまうのだ。Ubuntuの公式リポジトリだけでなくサードパーティのリポジトリも追加するようになると、今度はUbuntuのリリース間のアップグレード(参考:【第5回】Ubuntuのリポジトリの追加方法とアップグレード)がうまくいかなくなることも多い。

　よって、日常的に使用するホストマシンは、確実に必要で、できれば品質も安定しているものだけをインストールしておくことがポイントだ。

　もし「話題になっているから、便利そうだから、試しにインストールしてみたい」なんてソフトウェアが出てきた場合は、コンテナ・仮想マシンなどを活用すると良いだろう。Ubuntuをはじめとする多数のLinuxディストリビューションは無償で提供されている。つまり、複数の仮想マシン・コンテナについて、金銭的なコストを気にする必要なく複製することが可能なのだ。VirtualBox・GNOME Boxes・LXDなどが、Ubuntu上で動くおすすめの仮想マシン管理システムだ。

UbuntuのLXDにインストールした、Ubuntuの仮想マシンインスタンス

　物理マシンの中身を薄く保っておくと、いざ新しいPCを購入した時の移行作業もシンプルになる。極端な話、仮想マシンのインスタンスをコピーすればそれで終わりなのだから。

　何かをインストールしたとき、設定を変えたときは、その 手順や意図を文書化 しておくと良い。理想的にはどこかに環境構築に関するドキュメントを用意しておき、何か手を加える際はそこをアップデートした上で作業すると良いだろう。誰が読んでも理解できる文書にするのがベストだが、そこまで手間暇をかけるのは難しいかもしれない。自分がわかる程度に簡素化していても十分だ。ただし、「過去の自分」は往々にして「考え方がよく分からない他人」になることだけは注意しておこう。

　作成した文書の保存先はWebブラウザさえあれば更新できて、モバイル環境からでも参照しやすい、Google DocsやGistなどのクラウドサービスがおすすめだ。手順さえはっきりしておけば、もう一度実施しなくてはならなくなったときの時短になる。まさに、兎を得て蹄を忘ることがないような備えと言えるだろう。「/etc」以下にあるシステムの設定ファイルに関しては「etckeeper」パッケージをインストールしておくだけで、変更点をバージョン管理できるようになるのでおすすめだ。

　最後に重要な点が 「バックアップ」 である。本質的にバックアップは「トラブルが発生したあとの復旧」で重要になる。ただ、根拠のない経験に基づく意見として、バックアップをきちんととっている環境はトラブルが起こりにくい。言い換えると、 バックアップをサボった時に限って問題が発生する 。よってバックアップを取っておくことはトラブル回避の観点からも重要なのだ。たぶん。

　ちなみにどんなにバックアップを取っていても、リカバリーのテストを行っていない環境は、バックアップしていないのと同義である旨も留意しておこう。

Ubuntuが起動しなくなったら

　さて、本題に入ろう。まずは 「Ubuntuが起動しなくなった」 場合を考える。一口にUbuntuが起動しなくなったと言っても、いくつかのケースにわけられる。

ログイン画面は表示されるけれどもログインできなくなった
起動途中で止まる
そもそも画面に何も表示されない

　ログインできないケースは次節で扱うとして、よくあるのは 「起動途中で止まる」 ケースだろう。これはさらに細分化できる。

黒い画面に白い文字の「＜コード＞grub>＜／コード＞」で止まる
黒い画面に白い文字の「＜コード＞(initramfs)＜／コード＞」で止まる
黒い画面に白い文字でよくわからない文字列がたくさん表示された状態で止まる
PCとディスプレイの電源は入ったっぽいが黒い画面のまま

　いずれも、システムデータが入ったストレージが壊れたか、壊れかかっている場合に起こりやすい。ほかにも「起動系の設定ファイルを間違えて変更した」「システム更新中に意図しない問題が起こり中途半端な状態で中断してしまった」なども考えられる。先に、ストレージが壊れていないとした場合の、チェックポイントを紹介しておこう。

　「＜コード＞grub>＜／コード＞」で止まるのは、ブートローダーである「GRUB」の設定に何がしかの問題が発生した場合だ。最近のシステムだとおおよそ、「GRUBの設定ファイル(＜コード＞/boot/grub/grub.cfg＜／コード＞)に問題がある」か「＜コード＞/boot＜／コード＞以下にあるGRUBが参照するファイルが存在しないか」のどちらかに分類される。UEFI未対応のシステムだと、ストレージにあるMBR(Master Boot Record)に問題が発生しているケースもあるが、その場合はプロンプト表示には至らない可能性が高い。

grubのプロンプトで止まってしまった例。grub.cfgに書かれているコマンドをインタラクティブに実行できる

　典型的な修正方法は、「update-grubを実行して正しいgrub.cfgを再生成する」なのだが、そもそもupdate-grubコマンドを実行するためのシステムが起動できないので現実的ではない。そうすると「＜コード＞grub>＜／コード＞」で適切なコマンドを入力して無理やり起動するか、Liveシステム等のストレージが不要な環境で原因を追求し、update-grubを実行することになる。いずれの手法も、問題が発生したのがクリティカルなシステムではなく、それなりに時間的余裕があるときは楽しい作業だが、そうでない場合はただただしんどいだけだ。よって、後述するLiveシステムからとりあえずシステムを複製してしまう方法をおすすめする。

　「＜コード＞(initramfs)＜／コード＞」で止まるケースは、GRUBが参照するストレージは問題ないものの、システムがインストールされているストレージないしパーティションが壊れているケースだ。その結果、ルートファイルシステムをマウントできずにエラーとなる。ここで出てくる「initramfs」とは、起動時に使われる小さなアーカイブで、多種多様なストレージをマウントするために使われる。GRUBはまずカーネルとinitramfsをメモリ上に展開した上でカーネルを起動する、カーネルは各種ハードウェアの認識や初期化処理を行った上で、initramfsをマウントし、さまざまなドライバをロード、システムストレージのマウントに入る。何らかの理由でストレージをマウントできなかったときにここで止まる、というわけだ。

initramfsのプロンプトで止まってしまった例。限定的なLinuxコマンドなら使える

　マウントできない理由は、ストレージが存在しない、GRUBの設定を間違えた、ストレージが壊れてしまった、などが考えられる。正直ストレージが壊れてしまった場合、対応できる内容は限られてしまうし、それ以外についても解決に時間がかかることも多い。こちらについても一旦Liveシステムに逃げる方法を、後ほど説明する。

　黒い画面に白い文字がたくさん出るケースは、いわゆる「カーネルがパニックした」というケースが多い。これはカーネルかカーネルのデバイスドライバがうまく動かなかったことを意味する。カーネルに関して知識のある人がログをよく読めば原因が分かることもあるが、簡単に判明するとは限らない。この場合は古典的ではあるものの、とりあえず 周辺機器やビデオカードなどをいろいろ取り外した上でもう一度起動を試してみる と起動できる場合も多いので、まずはそれから試してみると良いだろう。

　最後が、黒い画面のまま何も文字が表示されないケースだ。これはハードウェア側の問題の可能性が高い。マシンが複数のディスプレイ端子を持っている場合は別の端子を試してみるとか、キーボードのEnterキーを何度か打って画面に何か表示されないか試してみるぐらいしか手はないかもしれない。「Ctrl-Alt-F2」を押すとログイン画面が表示されるようなら、GUIライブラリやGPUドライバの問題の可能性もある。その場合は、次の手順で回避できるかもしれない。

　まずPCの電源を投入後にESCキーを連打し、grubのプロンプトを表示させる。プロンプトが表示されたら「normal」コマンドとエンターキーを入力し、直後に一度だけESCキーを押す。そうするとGRUBメニューが表示される。ただし環境によってはメニューの表示ができないかもしれない。この時は諦めよう。運良くメニューが表示されたら、カーソルキーで「Ubuntu」で始まる行を選択し、「e」キーで編集モードに入る。カーソルキーで「linux」ではじまる行に移動し、その末尾に半角空白と「nomodeset」を追記する。

nomodesetの追加場所

　その後、Ctrl-xで起動処理を開始しよう。この方法で画面が表示されるようになるようなら、おそらくGPUドライバ関連の問題だ。ここから先は使っているGPUに依存するが、「GPUの名前や世代名・型番」などと「Ubuntu」や「Linux」を組み合わせて検索すると、同じような問題に遭遇していたり、運が良ければ回避策が見つかったりするのでチャレンジしてみてほしい。

Liveシステムを使ってストレージ全体を退避する

　さて、ハードウェアに依存しないケースについては、症状ごとに調査しながら解決することになるが、まずは何をするにしても、 「Liveシステムで起動し、必要なデータのバックアップを取る」 ことを強くおすすめする。Ubuntuの場合、Ubuntuのインストーラ自体がLiveイメージになっているため、起動時にインストーラではなく「Ubuntuを試す」を選択すれば、そこからバックアップを取れる。

起動時にLiveシステム(Ubuntuを試す)とインストーラ(Ubuntuをインストール)を選択する画面

　Liveシステムでバックアップするためには、追加で次のデバイスが必要になる。

Liveシステムを起動するためのUSBメモリ(4GiB以上の容量が必要)
バックアップ先のストレージ(バックアップデータの量に応じた容量が必要)

　バックアップ先のストレージは、NAS等のネットワーク越しでも構わないし、USBストレージ等を別途繋ぐという方法もある。そこは手持ちのデバイスに合わせてなんとかすると良いだろう。容量の大きなWindowsマシンがあるなら、Windowsのファイル共有(SMBプロトコル)も使える。

　Liveシステム用のUSBメモリの作り方はUbuntuのインストーラとまったく同じだ。詳細は「人気Linuxディストリビューション、Ubuntuを触ってみよう！」を参照してほしい。ちなみにUbuntu Japanese Teamがリリースしている「日本語Remix」のISOイメージを使えば、Liveシステムのアプリケーションも日本語化されるのでおすすめだ。

　起動したらバックアップ用のストレージを接続し、バックアップを行なう。バックアップ方法にはいくつものツールが存在する。今回はGUIを使ってよりシンプルに行なうために、UbuntuのLiveシステムに最初から入っている「ディスク」(gnome-disk-utility)を使うことにしよう。

　まずは画面左下のボタンから「disk」を入力して、ストレージ管理ツール(アプリケーション名は「ディスク/Disks」)を起動する。

ストレージの管理画面

　最低でも次の4種類のデバイスが表示されるはずだ。

もともとUbuntuがインストールされていた領域：サイズやストレージの名前から判断が必要
CD/DVD DriveもしくはUSBメモリ：Ubuntuのインストーラそのもの
Loop Device：Liveシステムを動かすための一時的な領域
その他：バックアップ用のストレージなど

　この時点でストレージのハードウェアそのものに問題なければ、ここからデータを吸い出せる可能性は高い。一旦ストレージ全体のイメージをコピーして別の場所に保存しておけば、そこからストレージそのものにダメージを与えることなく、必要なデータを取り出せる可能性も出てくる。

　バックアップを取りたいストレージを選択した上で、「ディスク」の画面の右上にある三点リーダーから「ディスクイメージを作成」を選択しよう。ここでイメージのファイル名と保存先を選択できる。

ストレージごとのコンテキストメニューから「ディスクイメージを作成」を選択する

保存先はストレージと同程度以上のサイズがないといけない

　保存先はローカルのストレージはもちろん、リモートのストレージも選択できる。上記ダイアログの「保存先フォルダー」から「その他」を選択すると詳細な選択ダイアログが表示されるので、それに従おう。ネットワーク先のストレージを選択したい場合は、さらにサイドペインから「その他」を選ぶ。そうすると次の図のように、さまざまなプロトコルを指定できるのだ。

smbはWindowsのファイル共有となる。NASなどはSSHかWebDAVが使える場合も多い

保存先をSSHサーバーが動いているUbuntuとする場合はこのように設定する

　あとは「作成開始」ボタンを押せば、保存が開始される。

保存中はプログレスバーが表示されるので、完了するまで放置しよう

　残念ながら「ディスク」はストレージデータの圧縮には対応していないため、大きなストレージはそのサイズのままイメージ化することになってしまう。もし圧縮が必要なら他のバックアップツールを使うことになるだろう。もしCLIでも良ければ、次のようなコマンドでも十分対応可能だ。

　まずあらかじめ、バックアップ対象のストレージデバイス名を記録しておこう。先ほどの「ディスク」を使って、バックアップ対象のストレージを選択すると、ウィンドウ下部に表示される「デバイス」がそれに該当する。最近のPCだと、接続形態によっておおよそ次の3パターンのいずれかになるだろう。

SATA接続：/dev/sda、/dev/sdb、/dev/sdcなど
NVMe接続：/dev/nvme0n1、/dev/nvme0n2など
MMC接続：/dev/mmcblk0、/dev/mmcblk1など

　USBストレージなどはSATA接続扱いになる。MMC接続はSDカードや内蔵のeMMCなどで使われる。実際に表示されるデバイス名は、これらの名前の後ろにパーティション番号が付く。SATAなら「/dev/sda1」になるし、NVMeなら「/dev/nvme0n1p1」、MMCなら「/dev/mmcblk0p1」といった感じだ。

　バックアップ対象のストレージのデバイス名が判明したら、バックアップは次のように実行する。

ストレージのバックアップを圧縮して取得する

$ sudo dd if=デバイス名 conv=sync,noerror bs=64K | gzip -c | ssh ユーザー名@ターゲットアドレス dd of=backup.img.gz

　「デバイス名」は上記で確認した名前を、「ユーザー名@ターゲットアドレス」はSSHログイン先のユーザー名やホスト名・IPアドレスなどを指定する。これにより、ターゲット先のホームディレクトリに「backup.img.gz」というファイルが作られるというわけだ。ストレージの場合、使っていない領域も多く、圧縮効果はそれなりに高くなる。

　一度ストレージ全体のバックアップを取ってしまえば、PC側のストレージの復旧で多少ミスをしてもなんとかなることが多い。リカバリ作業の安心感を得るためにも、まずはこれらの対応を行なっておくと良いだろう。

Liveシステムを使って一部のデータを退避する

　保存しなければならないデータがはっきりしていて、なおかつUbuntuそのものは再インストールしても構わないということであれば、ストレージ全体のバックアップを取る必要はない。前項と同じようにLiveシステムを起動した上で、ストレージをマウントしてほかの場所にファイルをコピーしてしまえば良いのだ。

　Liveシステムを起動すると、画面左のLauncherの下のほう、ゴミ箱アイコンの上にストレージデバイスが見えるはずだ。

ストレージデバイスのアイコン

　これが起動できなかったUbuntuシステムが入っているストレージとなる。このアイコンをクリックすると、自動的にストレージをマウントしてその内容を表示してくれる。あとはそこから必要なファイルをコピーすれば良い。具体的な場所は環境に依存するが、よくバックアップが必要になりそうな場所を以下に示しておく。

ユーザーがデータを保存する場所：home/ユーザー名/
ユーザー用設定等の隠しデータ：home/ユーザー名/.localやhome/ユーザー名/.configなど「ドットで始まるファイルやディレクトリ(ドットファイル)」
システム全体の設定ファイル：etc/
システムのログファイル：var/log/

　Ubuntuのファイルブラウザは、ドットファイルを表示しない。もし表示したければ「Ctrl-h」を入力しておこう。

Ctrl-hを押すと、「.」で始まるドットファイルも表示される

ストレージイメージからデータを取り出す

　バックアップデータの「img」ファイルは、ファイルブラウザからダブルクリックするとリストアモードになる。これは特定のストレージデバイスの 中身を削除した上で上書き する形でリストアするため、扱いには注意が必要だ。同程度以上の容量をもった空のストレージデバイスがある場合のみに使う方法だと思っておくと良いだろう。

　「img」ファイルを右クリックし、「別のアプリケーションで開く」から「ディスクイメージマウンター」を選択すると、ストレージをマウントし、中身を閲覧できる。

「別のアプリケーションで開く」を選択すると、ディスクイメージ万ターがー登場する

　ちなみにこの状態は「読み込み専用」でマウントしているため、書き込みはできない。あくまで復旧対象のストレージがにっちもさっちもいかなくなった時に、データを取り出す用途だと考えよう。ちなみにCLIのコマンド(mountコマンドやgnome-disk-image-mounterコマンド)を使えば、書き込み可能な状態でマウントも可能だ。

　不要になったら、ファイルブラウザのサイドペインにある「取り出しボタン」を押せば、アンマウントされる。