VMWare ConverterのLinuxコンバート97%問題の対処法(Error loading operating system)

概要

以前の投稿でLinuxのConverter が97%で終了する場合のイメージ取得方法を投稿したが、その後のBootディスクの構築を手動で行う方法について紹介する。ちなみにそのまま起動すると「Error loading operating system」というシンプルなメッセージが出現する。

この手順を実施した環境

今回の対象システムのディスクの構成は以下の通り。
Reconfig失敗の原因は、ディスクのUUIDの置換の失敗と考えられる。

ファイルシステムの構成

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda3 during installation
UUID=4e10556e-812e-4e06-bb0b-5473abec1912 / ext4 relatime,errors=remount-ro 0 1
# /boot was on /dev/sda1 during installation
UUID=d363601b-de9c-4bb1-bb58-41fc7e7f8bf1 /boot ext4 defaults 0 2
# /data was on /dev/sda4 during installation
UUID=6ccd8b82-4bc2-4f4d-8e4c-38f06a9410ab /data ext4 relatime 0 2
# swap was on /dev/sda2 during installation
UUID=4434473c-67da-4fdb-8fc4-2b81e3fac6bf none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0

ディスクパーティションの構成

$ sudo fdisk -l
Disk /dev/sda: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders, total 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00073dba

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1953791 975872 83 Linux
/dev/sda2 1953792 17577983 7812096 82 Linux swap / Solaris
/dev/sda3 17577984 85938175 34180096 83 Linux
/dev/sda4 85938176 209713151 61887488 83 Linux

リカバリ対象のOSバージョン

 $ cat /etc/os-release 
NAME="Ubuntu"
VERSION="14.04.5 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.5 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

手順

CD-ROMブート

BIOS設定画面の起動

CD-ROMブートを行うために、BIOSのデバイス起動順序を変更する。仮想マシンのプロパティで「次回仮想マシンの起動時に、強制的にBIOSセットアップ画面に入る。」オプションにチェックを入れて、仮想マシンの電源を入れる。

デバイスの優先順位の変更

「CD-ROM Drive」が一番上に来るようにする。

ISOイメージのマウント

BIOS設定画面にいるときに、ISOイメージのマウントを行っておく。

今回の復旧対象がUbuntu Linuxであるため、UbuntuのISOイメージを選択する。

BIOS設定の変更を確定する。

 

リカバリ環境設定

CD-ROMからOSが起動するが、初期の環境設定が必要になる。OSインストールと似たような手順になる。

言語の設定

セットアップに使用する言語を選択する。

メニューからは「壊れたシステムを修復」を選ぶ。

警告メッセージに「はい」を選ぶ。

ロケールの設定が必要なので、対応しておく。

キーボードの設定もある。

キーボードのレイアウト設定

ネットワークの設定

ネットワークは使わずに作業は完結するため、ここではすべてキャンセルを選択すればよい。

キャンセルを何度か実行すると、ネットワークの設定方法を訪ねてくるので、「今はネットワークを設定しない」を選択して進む。

一時的なホスト名なので、デフォルトのままで設定する。

ルートパーティションのマウント

修復する環境を整えていく。事前に調べた元システムの情報は以下であるため、まずは/dev/sda3をルートとしてマウントし、/dev/sda1を/bootにマウントして、復旧作業を行う予定である。

/dev/sda1 ⇒ /boot
/dev/sda2 ⇒ swap
/dev/sda3 ⇒ /
/dev/sda4 ⇒ /data

しかし、/dev/sda3をマウントしようとしたところ、困った問題が起きた。

/dev/sda3内でシェルを実行
警告メッセージの表示
シェルが見つからないエラーの発生

調査して後からわかったことだが、この問題はパーティションの読み取り順番を間違えており、/dev/sda2が元のルートパーティションであった。実際、デバイスの認識順番は環境によって変わる可能性があり、読み違えの防止のために導入されたのがUUIDでのマウントであったりするのだ。

気を取り直して、/dev/sda2をルートパーティションにマウントして、作業を継続する。

警告メッセージの表示
/dev/sda2内でシェルを実行
確認メッセージの表示
シェルの獲得

無事ルートファイルシステムをマウントすることができた。

このサーバは/bootパーティションが分かれているため/bootのマウントを行う必要があるが、読み取り順番が変わっている可能性があり、残りのパーティションは一度マウントしてみて、パーティションのサイズや中身のファイルの内容から推測してファイルシステムの特定を行った。結果として、/dev/sda1が/root、/dev/sda3が/data、/dev/sda4がSWAPであることを特定した。

トライアル&エラーを行っている様子

/dev/sda1を/bootにマウントし直す。

 # mount -t ext4 /dev/sda1 /boot

ブート構成の再構築

/etc/fstabの修正

UUIDで書かれている設定を新しい物理デバイスで書き直し、起動する。もちろん新しいデバイスのUUIDを調べて記載しても構わない。

/etc/fstabの修正

GRUBの再構成

GRUBの再構成を行う。UUIDの記述が修正される。

 # grub-install /dev/sda
GRUB再構成の様子

CD-ROMの取り出しと再起動

あとは、ISOイメージをアンマウントして、BIOSの起動順番を変えて起動するだけである。うまく言っていれば、GRUBからきちんとOSが起動してくるはずである。

再度、BIOS起動になるように仮想マシンのオプションを編集
 # exit 

exitコマンドでシェルを抜けて、「システムの再起動」を行う。

BIOS設定画面でCD-ROMの起動順序を下げて、設定保存後、BIOS設定画面を抜けるが、

IPアドレスは既存のコンフィグを持っているため、IP重複が発生しないように、仮想マシンのプロパティで、ネットワークアダプタの「接続中」および「パワーオン時に接続」のチェックを外す必要がある。

BIOS設定を抜けると、無事GRUBからシステムが起動されることを確認できた。

参考情報・サイト

vmware TECHNOLOGY NETWORK』(LiamSchneiderさん 2010-07-22)