サーバーのリプレースをすべく、QNAPのケースを改造して組み換えを行いました。
その後、いざHDDを付け替えて起動というところで、ブートデバイスとして認識してくれないことがわかりました。
嫌な予感がして前環境のBIOSの設定を確認してみると、ブートは「UEFI＋レガシー」となっています。
いわゆる従来のBIOSと近年のUEFI両方でのブートに対応するモードです。
試しに「UEFIオンリー」に変更してみると、従来の環境でも起動してくれません。
つまり、私はこのサーバーをBIOS環境で構築していたということです。
しかしながらマザーボード（AsRockJ4105-ITX）はUEFIブートしかサポートしていないそう。
何も考えずに購入してしまったため、UBUNTU側を対応させる必要が出てきてしまいました。
既存の環境をBIOSブートからUEFIブートに変更しているよい例が出てこず、手探りでなんとか移行に成功したので、メモに残しておきたいと思います。
UEFIはESPパーティションにあるブートローダーを読みにいくような仕組みになっているようです。
今回の手順では、まずHDDのMBRからGPTへの変換作業を行い、ESPパーティションを作成、GRUBを書き込みます。
UBUNTUのバージョンは14.04.1LTSです。
まず、前準備としてefibootmgrというパッケージをインストールしておきましょう。
私の環境にはこれが入っておらず、grubinstallコマンドに失敗してしまいました。
既存の環境でブートできるうちにこれをやっておかないと、パッケージをダウンロードしてきて手動でインストールする羽目になります。
既存のmbr環境で起動した状態で
sudo apt-get install efibootmgr
ここからは新環境に移行するHDDを接続し、ライブCDで作業を行います。
uefiでusbライブ環境を起動し
gparted(gui)で後ろ256MBを切ってフラグboot,espにしておく
その後、作成したパーティションをvfatでフォーマットします。
sudo /sbin/mkfs.vfat -F32 /dev/sdb4
ターミナルを開き、gdiskでmbr→gpt変換を行います。
※データが吹き飛ぶ可能性があります。必ずバックアップを取ってから行いましょう。
sudo gdisk
/dev/sda
r(revovery and transformation options)
f(load MBR and build GPT)
y(yes)
w(write)
y(yes)
では、UEFI用のgrubを入れ直して行きましょう。
rootの入っているパーティションをマウントして作業します。
また、先程作成したESPパーティションを/boot/efiにマウントします。
sudo apt-get install grub-efi
sudo mount /dev/sda2 /mnt
sudo mkdir -p /mnt/boot/efi
sudo mount /dev/sda4 /mnt/boot/efi
sudo mount –bind /dev /mnt/dev
sudo mount –bind /proc /mnt/proc
sudo mount –bind /sys /mnt/sys
sudo chroot /mnt
/usr/sbin/grub-install –target=x86_64-efi –efi-directory=/boot/efi /dev/sda
再起動
シェルが出るorGRUBメニューが出るが起動しない状態になると思うのですが、慌てずに手動でブートしましょう。
メニューでeを押すとエディタが起動し、Ctrl+Cでシェルへ入れます。
ls
HDD一覧がでたら、片っ端からset rootして/bootがあるパーティションを探しましょう。
set root=(hd0,gpt2)
ls /
これで/bootがあったら、カーネルの場所を伝える
rootの場所も必ず明記します。
linux /boot/vmlinuz-x.xx.x-xx-generic root=/dev/sda2
initrd /boot/initrd.img-x.xx.x-xx-generic
boot
これでブートできるはずなので、正しい設定を行います。
sudo mount /dev/sda4 /boot/efi
/usr/sbin/grub-install –target=x86_64-efi –efi-directory=/boot/efi /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg
これでUEFIからブート可能となりました。
おまけ
ブート後、mysqlが吹っ飛んだことが判明したのでリカバリ
設定ファイルを書き換えてリカバリモードで起動します。
1から順に数値を上げてmysqlを再起動してみてください。起動できた時点でバックアップを取り、再構築を行います。
最大5なのですが、4以上はデータが欠落する可能性があるそうです。
sudo vi /etc/mysql/my.cnf
[mysqld]
innodb_force_recovery = 3
起動したら全てのDBをバックアップします。
mysqldump -u root -p -x –all-databases > alldatabase.dump
mysqlを停止し、mysqlで始まるDB以外をすべて削除します。
sudo service mysql stop
su
sudo rm -rf `ls -d /var/lib/mysql/* | grep -v “/var/lib/mysql/mysql”`
リカバリ設定をもとに戻して起動し、バックアップから復元して問題なく動けば完了です。
sudo vi /etc/mysql/my.cnf
[mysqld]
innodb_force_recovery = 0
sudo service mysql start
mysql -u root -p < alldatabase.dump
反省点
・efibootmgrを入れておく必要があることを知らなかったため、すでに既存のブート設定を潰してしまった。
更にchroot環境でapt-getができなかったので、パッケージを落としてdpkgしたらどうにかなった
・わけも分からず/bootを消してしまった。
当たり前だがカーネルが入っているのでuefiだろうが絶対消してはいけません。
以前取得していたバックアップイメージをマウントして対応した。
なお、gpt変換後はmbrパーティションが触れなくなった（ぶっ壊した？）ので、ルートの/bootにコピーした。
sudo mount -t ext2 -o loop,offset=65536 boot.img /mnt-boot
sudo cp -r /mnt-boot/* /mnt/boot
