HDD換装とUbuntu環境の移行 − データの移行、起動時停止問題、UUID指定とハイバネーション設定

ジャンクで購入したThinkPad X21にUbuntu(現在hardy8.04)をインストールして使用している。
無線LANにてウェブ&メール端末として非常に便利に使っていたが、最近HDDがおかしい。
内蔵HDDへのアクセスランプが点灯したまま、OSが固まってしまうことがある。
キー応答も、マウスポインタの反応も完全になくなっている。 発生するタイミングも、起動時から使用中、放置中まで特定していない。
この手の症状の場合、HDDのハード故障の前兆と私のゴーストが囁く(w)ので、 手持ちで安定しているHITACHIの80GB2.5"IDEに載せ替えるとする。

今回のネタは、以下の通り。

• Ubuntu8.04の、HDD交換を伴うデータ移行後の注意点
• 元HDD内容の新HDDへのデータ移行
• データ移行後のファイルの修正(UUIDの場合)
• ブートローダーの設定
• 起動途中で停止、ダンマリ。調査・対策する
• ハイバネーションから復帰しない。調査・対策する
  • => Begin: Waiting for resume device ...

慣れてらっしゃる方は「Ubuntu8.04の、HDD交換を伴うデータ移行後の注意点」 の部分だけ注意すれば、同じハマりは無いかと。

最終的に、起動も、ハイバネーションの動作も全て解決することができた。
UUIDや、各種設定との関連も知ることができ、良いトラシュー(?)経験になりました。

ちょっと長くなっています。ご容赦を。

Ubuntu8.04の、HDD交換を伴うデータ移行時の注意点

Ubuntu 8.04がインストールされているHDDを、別のHDDに交換する。
データ移行を行う際に必要になる、OS側の注意点。

• /etc/fstab、/boot/grub/menu.lstのUUIDの設定変更が必要
  

  /etc/fstabと/boot/grub/menu.lstには、HDDのUUIDが直接記述されている。
  HDDを交換前、データ移行時などに、新しいHDDのUUIDに書き換えること。
  これを行わないと、起動やマウント動作などに色々と面倒が起きる。
  

  デバイス固有のUUIDの確認方法は、以下のような方法がある。

  • $ sudo vol_id -u /dev/sda1
  • $ sudo /lib/udev/vol_id /dev/sda1
  • $ ls -l /dev/disk/by-uuid/
    (/dev/disk/by-uuid/配下の確認は、場合によっては正しい結果が得られない)
• /etc/initramfs-tools/conf.d/resumeのUUIDの設定変更が必要
  

  /etc/initramfs-tools/conf.d/resumeにも、HDDのUUIDが直接記述されている。
  変更した上で、ramdiskの再構成を行う。($ sudo update-initramfs -u)
  

  変更を忘れると、正常に起動しない、ハイバネーションから復帰しない等の現象が発生する。
  

  参考リンク：

  • Slow boot process on "waiting for resume device"
• /etc/initramfs-tools/conf.d/直下には、バックアップファイルを配置しない。
  

  /etc/initramfs-tools/conf.d/resumeは、 ハイバネーションのデータ保存デバイスを指定している。
  update-initramfsコマンドでramdiskファイルを再作成する際には、 /etc/initramfs-tools/conf.d/配下のファイルを全て 読み込んでいる。
  もし"resume"ファイルを、"resume.bak"などと同一ディレクトリに保存すると、 両方のファイルが読み込まれてしまい、 正常に起動しなくなる、ハイバネーションから復帰しないなどの現象に至る。 .../conf.d/resumeのバックアップファイルは、.../conf.d/bak/resume.bak等と、 サブディレクトリを掘って格納しておくのが吉。 (/usr/share/initramfs-tools/initスクリプト内での設定ファイルの読み込み動作に由来している)

自分も事前にこれさえわかっていれば、試行錯誤する事はなかったんすけれどね。
以下は、上記の教訓を得た過程です。

元HDD内容の新HDDへのデータ移行

単なるデータ移行のみならddでもよいが、新HDDの容量も大きく、今回はパーティションのリサイズを伴う方法で行った。

dump、restoreを使って、ファイルをコピー(?)した。
cpやtar等でも良いのかもしれないが、安心の為により低レベルのファイル移行を行いたかったので。

以下、/mnt/workに新HDDの領域をマウント、/dev/sda1の内容を、 /mnt/work配下にコピーする、という流れのコマンド抜粋。
HDDの初期化やらは、定石どおりに。面倒なので、ここでは省略します。
dump,restoreをパイプしています。同一ホスト上で何だこりゃな感じですが、上手くできます。

[実施例]
$ sudo init 1
# mount /dev/sdb1 /mnt/work
# cd /mnt/work
# dump -0uf - /dev/sda1 | restore -rvf -

データ移行後のファイルの修正(UUIDの場合)

新HDD上に、データが複製できたら、その中の/etc/fstabと/boot/grub/menu.lst、 /etc/initramfs-tools/conf.d/resumeに記述されているUUIDを、 新しいHDDのUUIDに変更しておきます。

まず、新しいHDDのUUIDを調べます。

[vol_idコマンドでの出力例]
# vol_id -u /dev/sdb1
62b58812-281a-45dc-8a69-78ed9cb57d4e
# vol_id -u /dev/sdb3
64769c58-f53a-4a49-92e8-ea823f1f89fc

デバイス名とUUIDの紐づけが確認できましたので、これを元に設定変更です。

fstabは、ご自身のファイルを見ていただくと一目瞭然ですが、 UUID=..で始まるのが、デバイスのUUIDが指定されている箇所です。
LABEL=..とか、/dev/sdX1とかの指定方法もありますが、今回はUUIDの場合の指定方法ということで、UUIDにのみ着目します。

[fstabの例]
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/sda1 (/)
UUID=62b58812-281a-45dc-8a69-78ed9cb57d4e /               ext3    defaults,errors=remount-ro 0       1
# /dev/sda3 (swap)
UUID=64769c58-f53a-4a49-92e8-ea823f1f89fc none            swap    sw              0       0

/boot/grub/menu.lstのkernel行に、UUIDにてrootカーネルオプションが指定されている場合がある。
これを、新HDDでルートになるデバイスのUUIDに修正する。
以下では、root=UUID=...の部分に、新HDDでルートになるデバイスのUUIDを記載している。

[/boot/grub/menu.lstの例]
title           Ubuntu 8.04.1, kernel 2.6.24-22-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.24-22-generic root=UUID=62b58812-281a-45dc-8a69-78ed9cb57d4e ro quiet splash
initrd          /boot/initrd.img-2.6.24-22-generic
quiet

/etc/initramfs-tools/conf.d/resumeには、 ハイバネーション時にデータを退避しておく領域のデバイスのUUIDを記述します。
一般的にswapパーティションらしいです。
以下でも新HDDのスワップパーティションのUUIDを記述しています。

[/etc/initramfs-tools/conf.d/resumeの例]
RESUME=UUID=64769c58-f53a-4a49-92e8-ea823f1f89fc

ブートローダーの設定

前項までで、新HDDにはブートローダー以外の設定は終了しました。
ここで

$ sudo mount /dev/sdb1 /mnt/work
$ sudo grub-install --root-directory=/mnt/work /dev/sdb

と実行して一発成功すれば、幸せです。後はHDDを交換して起動を確認するのみです。
自分の環境では何やら"BIOSがうんちゃらかんちゃら"とエラーが出て失敗。
そのため現状でのgrub-installは諦めて、以下の流れで処置。

1. grub起動FDDの作成

   grubのstage1,stage2のみを組み込んだ起動ディスクを作成します。
   このディスクで起動することで、grubのコマンドラインが使用でき、 起動エントリーを手入力することで、HDD内のシステムから起動できます。

   $ sudo dd if=/boot/grub/stage1 of=/dev/fd0 count=1
   $ sudo dd if=/boot/grub/stage2 of=/dev/fd0 seek=1
   

   参考リンク：

   • GRUB について - Linux活用日記
2. 新HDDへの換装
3. grub起動FDDで手動起動

   作成したgrub起動FDDを挿入して起動します。
   

   grub>

   というコンソールが出てきますので、 /boot/grub/menu.lst内に記述されている起動エントリーを記述して起動します。
   この際には、UUID等ではなく/dev/sda1とかのデバイス名を利用すると楽で確実。
   

4. grub-installの実行

   問題なければ、以前のシステムと同じように起動しているはずです。
   ログインしてgrub-installしてしまいます。

   [実行例]
   $ sudo grub-install /dev/sda
   

   実行した時に、以下のように出てくる。
   "Installation finished. No error reported."とあるのに、 何やらチェックしてみては？と言うような文言も追記してあって、 最初失敗したんかな？と誤解した。
   上記のように"Installation finished"とあれば大丈夫みたい。

   [grub-install実行例]      
   $ sudo grub-install /dev/sda
   Searching for GRUB installation directory ... found: /boot/grub
   Installation finished. No error reported.
   This is the contents of the device map /boot/grub/device.map.
   Check if this is correct or not. If any of the lines is incorrect,
   fix it and re-run the script `grub-install'.
   
   (hd0)   /dev/sda
   

5. 正常起動の確認

起動途中で停止、ダンマリ。調査・対策する

ハイバネーションから復帰しない。調査・対策する

上記の問題は、同じ原因。解決済み。
/etc/initramfs-tools/conf.d/resumeの設定ファイルに絡んでの作業考慮不足でした。

現象

• 起動開始時、スプラッシュウィンドウが表示され5秒後位に決まって停止する。
• grubにて、kernel行から"quiet splash"を削除して起動確認すると以下の文言で停止している。(確認したときは、常に。)

  Begin: Waiting for resume device ...
  

原因

• その１：/etc/initramfs-tools/conf.d/resume内のUUIDの変更忘れ。
• その２：及び、resumeファイル変更後のRAMディスクファイルの再構成忘れ。

• その３：/etc/initramfs-tools/conf.d/直下に、本来存在しない古い内容のバックアップファイルを作成してしまい、その内容がRAMディスクファイル再作成時に参照されてしまった為。

結果、RAMディスクファイルに、適切なハイバネーションデバイスのUUIDが反映されず、 起動時に存在しないUUIDの認識の待ちに入ってしまっている。
/etc/initramfs-tools/conf.d/直下のファイルは、 RAMディスクファイル再作成時に実行される/usr/share/initramfs-tools/initスクリプトにより全て読み込まれている為に、今回の現象に繋がった。

対策

• その１：/etc/initramfs-tools/conf.d/resume内のUUIDを、現在のswapパーティションのUUID値に修正する。
• その２：/etc/initramfs-tools/conf.d/resumeを修正したら、RAMディスクファイルを再作成する。($ sudo update-initramfs -u)
• その３：/etc/initramfs-tools/conf.d/直下には、本来存在しないファイル(ex.バックアップファイル)を配置しない。

その３の動作は、/usr/share/initramfs-tools/initスクリプト内での設定ファイルの読み込み動作に由来している。

/etc/initramfs-tools/conf.d/resumeは、ハイバネーションのデータ保存デバイスを指定している。
update-initramfsコマンドでramdiskファイルを再作成する際には、 /etc/initramfs-tools/conf.d/配下のファイルを全て読み込んでいる。
もし"resume"ファイルを、"resume.bak"などと同一ディレクトリに保存すると、 両方のファイルが読み込まれてしまい、正常に起動しなくなる、 ハイバネーションから復帰しないなどの現象に至る。 .../conf.d/resumeのバックアップファイルは、.../conf.d/bak/resume.bak等と、 サブディレクトリを掘って格納しておくのが吉。

回避方法

• 再起動を繰り返すと起動することがあった。
• grubより、kernel行から"quiet","splash"を削除、"UUID=..."の部分を"/dev/sda1"等に置換して起動。すると起動できた。

以上の方法でひとまず起動させることで、処置を行うことが可能。

参考リンク

• Slow boot process on "waiting for resume device"