ディスク複製で LVM の VG（VolumeGroup）名の重複の解決方法
前エントリの SSD ベンチマーク、前々エントリの SSD 購入報告で書いたように、自宅サーバのストレージを HDD から SSD へ移行する際に、LVM の VG（VolumeGroup）名が重複していたために、簡単にはディスクコピーができず苦しんだばかりか、ディスクコピーをした後に、正常起動させるまでに更に苦しんだ備忘録です。
まず結論というか今後の自分へのアドバイス。インストール時の LVM 設定では、必ず VG（VolumeGroup）名をデフォルトの VolGroup00 を日付などを用いて VolGroup100321 みたいにユニーク化して、他と重複させない癖を付けよう！
さて、今から備忘録として記述する Linux のディスク交換の方法は、クローン作成の最適解でも何でもない方法だと思うけど、自分的には非常に慣れ親しんだ方法なので精神的に楽です。
まず、僕が知っているディスクのクローン作成・・・っていうか、ディスクを交換しても同じ状態で復帰させる方法は、過去に紹介したもの含めて３手法です。もっともこれ以上に方法はあると思いますが現状これで不都合はありません。
- TrueImage などクローン作成ツールを利用して、ディスクの複製を作成する方法
- RAID 構成のサーバで Linux を大量インストールする時の簡略化検討 で紹介した、ディスクのイメージを作成する方法（方法１に違い）
- Linux サーバ構築術 - 大量インストールする時の簡略化検討その２ で紹介した、rsync などでファイルの同期コピーを利用する方法
ちなみに今回選択した方法は、もっとも時間がかかる方法３です。理由は簡単です。SSD は書き換え制限が存在するので、なるべく書き込みブロック数を減らしたかったと言うことです。方法１はセクター単位でイメージコピーするため、本当に完全なクローンを作成することができますが、元 HDD が 230GB なので、SSD も 230GB 分が Write 済みになってしまいます。しかもその後で残りの 26GB を利用可能状態にするためには、パーティションサイズの変更という作業が生じてしまいます。方法２もほぼ同様の作業が必要。そんなわけで、いったん SSD に交換して最小構成で fedora をインストールして、再度 HDD 状態に戻してから SSD を eSATA 接続して、必要なファイルを rsync でごっそり転送することにしました。
トラブル１． LVM の VG 名が重複しているので mount できない！
この方法でディスク同期をさせたことがなかったので、思いっきり初歩的ミスではまりました。LVM は VG 名が重複しているとディスクをマウントできないのです。初めはその知識すら持ち合わせていなかったので、何故にマウントできないっ！って悩みました。
とりあえずシングルモードで起動させる。シングルモードでの起動方法はここらへんを見れば解決します。
そんでもって、eSATA 接続で SSD をつなげます。/dev/sdb が接続した SSD っぽいのでマウントしてみる。/boot に相当するパーティションは苦しむことなく接続できる。
[root@srv01 dev]# mount /dev/sdb1 /media [root@srv01 dev]# ll /media 合計 7897 -rw-r--r-- 1 root root 1406155 2008-11-19 02:10 System.map-2.6.27.5-117.fc10.x86_64 -rw-r--r-- 1 root root 84992 2008-11-19 02:10 config-2.6.27.5-117.fc10.x86_64 drwxr-xr-x 3 root root 1024 2010-03-18 05:25 efi drwxr-xr-x 2 root root 1024 2010-03-18 05:36 grub -rw------- 1 root root 3897402 2010-03-18 05:27 initrd-2.6.27.5-117.fc10.x86_64.img drwx------ 2 root root 12288 2010-03-18 05:13 lost+found -rwxr-xr-x 1 root root 2637056 2008-11-19 02:10 vmlinuz-2.6.27.5-117.fc10.x86_64 [root@srv01 dev]# umount /dev/sdb1
お次に / 配下をマウントしてみる。なんだかマウントできない。
[root@srv01 dev]# mount /dev/sdb2 /media
mount: unknown filesystem type 'lvm2pv'
[root@srv01 dev]# mount -t ext3 /dev/sdb2 /media
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
そういえば LVM のマウントの仕方は違うんだと気がつき LV（Logical Volume）名を記述しようとするが・・・そうです。VG 名が重複しているので、SSD 側を有効化することができません！｡･ﾟ･(ﾉ∀`)･ﾟ･｡
とりあえず現情報を採取します。
[root@srv01 dev]# fdisk -l Disk /dev/sda: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes Disk identifier: 0x98deb064 デバイス Boot Start End Blocks Id System /dev/sda1 * 1 25 200781 83 Linux /dev/sda2 26 30401 243995220 8e Linux LVM Disk /dev/sdb: 256.0 GB, 256060514304 bytes 255 heads, 63 sectors/track, 31130 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes Disk identifier: 0x6b41ecd3 デバイス Boot Start End Blocks Id System /dev/sdb1 * 1 25 200781 83 Linux /dev/sdb2 26 31130 249850912+ 8e Linux LVM [root@srv01 dev]# pvscan PV /dev/sdb2 VG VolGroup00 lvm2 [238.25 GB / 32.00 MB free] PV /dev/sda2 VG VolGroup00 lvm2 [232.69 GB / 32.00 MB free] [root@srv01 dev]# vgscan Reading all physical volumes. This may take a while... Found volume group "VolGroup00" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 [root@srv01 dev]# lvscan ACTIVE '/dev/VolGroup00/LogVol00' [230.22 GB] inherit ACTIVE '/dev/VolGroup00/LogVol01' [8.00 GB] inherit [root@srv01 ~]# vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 238.25 GB PE Size 32.00 MB Total PE 7624 Alloc PE / Size 7623 / 238.22 GB Free PE / Size 1 / 32.00 MB VG UUID K6qWBo-uvhY-5tgW-IZir-satd-4xnQ-8jUBBF --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 1 Act PV 1 VG Size 232.69 GB PE Size 32.00 MB Total PE 7446 Alloc PE / Size 7445 / 232.66 GB Free PE / Size 1 / 32.00 MB VG UUID o35Yvk-Q56c-rTAI-Xf7D-w1Rd-NNsp-J3fp6z
VG 名を変更しないと始まらないので、SSD 側の VG 名を変更する。手順は下記の通り。覚えておくと便利。UUID 名は前述の vgdisplay で検出することができます。
vgchange -ay VG名
mount /dev/VG名/LV名 /media
[root@srv01 ~]# vgrename K6qWBo-uvhY-5tgW-IZir-satd-4xnQ-8jUBBF VolGroup1003 Volume group "VolGroup00" successfully renamed to "VolGroup1003" [root@srv01 ~]# vgchange -ay VolGroup1003 2 logical volume(s) in volume group "VolGroup1003" now active [root@srv01 ~]# mount /dev/VolGroup1003/LogVol00 /media
これで無事にマウントできる状態になっているはずです。マウントしてみます。
mount /dev/VolGroup1003/LogVol00 /media
マウント成功！(*^ーﾟ)b
お次は全てのファイルを rsync で転送。ログとか更新が常時発生する部分は差分が発生するけど、まぁ細かい部分は気にしない。また rsync 中に更新が発生しているファイルは同期に時間がかかってしまうけど、それも気にしない。rsync 中は負荷がめちゃくちゃ高くなるけど、シングルモード起動なので気にしません。
rsync -av /etc /media/ rsync -av /lib /media/ rsync -av /lib64 /media/ rsync -av /opt /media/ rsync -av /sbin /media/ rsync -av /selinux /media/ rsync -av /bin /media/ rsync -av /root /media/ rsync -av /home /media/ rsync -av /tmp /media/ rsync -av /usr /media/ rsync -av /var /media/
次に /boot 部分を同期させる。パーティションが違うので /dev/sdb1 をマウントをさせる。
umount /dev/VolGroup1003/LogVol00 mount /dev/sdb1 /media rsync -av /boot/ /media/ umount /dev/sdb1
VG 名が VolGroup00 から VolGroup1003 へ変わるので、コピーしたファイルの内、２つだけ変更する箇所があります。
/boot/grub/grub.conf を変更
mount /dev/sdb1 /media vi /boot/grub/grub.conf
青文字の部分が修正した部分です。VolGroup00 → VolGroup1003 へ変更します。
title Fedora (2.6.27.21-170.2.56.fc10.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.27.21-170.2.56.fc10.x86_64 ro root=/dev/VolGroup1003/LogVol00 rhgb quiet
initrd /initrd-2.6.27.21-170.2.56.fc10.x86_64.img
/etc/fstab も変更。/boot が UUID で記述されているので UUID が抽出です。
umount /dev/sdb1 mount /dev/VolGroup1003/LogVol00 /media [root@srv01 etc]# blkid /dev/mapper/VolGroup00-LogVol01: TYPE="swap" UUID="d00249d8-eb6e-4ed8-99c8-db74c6786ec1" /dev/sda1: LABEL="/boot" UUID="8b5b33bb-215b-4327-aa77-dab83aef01da" TYPE="ext3" SEC_TYPE="ext2" /dev/mapper/VolGroup00-LogVol00: UUID="216de8ab-a156-49c2-a52c-d82909513b70" TYPE="ext3" /dev/sda2: UUID="ROPddb-M2a9-JEWJ-F7cY-u0BG-jMSK-Azqzq5" TYPE="lvm2pv" /dev/VolGroup00/LogVol00: UUID="216de8ab-a156-49c2-a52c-d82909513b70" TYPE="ext3" /dev/VolGroup00/LogVol01: TYPE="swap" UUID="d00249d8-eb6e-4ed8-99c8-db74c6786ec1" /dev/sdb1: LABEL="/boot" UUID="dfc129dd-205b-4e4d-9cd5-36fe4d4ea6d1" SEC_TYPE="ext2" TYPE="ext3" /dev/sdb2: UUID="OPfER5-clJo-wSBP-1PV9-tBJj-wD83-DVDfx5" TYPE="lvm2pv" /dev/dm-2: UUID="88b2e4da-0f9a-4f5b-9f77-fa83f519ad11" TYPE="ext3" /dev/dm-3: UUID="e7e4604c-7b6a-4640-8032-403b343b9cb7" TYPE="swap" vi /media/etc/fstab
青文字部分が変更部分です。UUID は blkid から /boot となっている部分をコピペします。
/dev/VolGroup1003/LogVol00 / ext3 defaults,noatime 1 1 UUID=dfc129dd-205b-4e4d-9cd5-36fe4d4ea6d1 /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup1003/LogVol01 swap swap defaults 0 0
ちなみに最初は /etc/fstab の書き換えを忘れていたのですが、これを忘れるとこうなります。
これで SSD へ付け替えて再起動すれば、無事に元通りの環境として起動するはずです。
トラブル２． なぜか起動しない。
画面撮影を忘れてしまったのですが、何故か、intel matrix storage manager option ROM なんらたってホント初めの部分でフリーズしてしまって先に進めません。超焦りました。とりあえず MBR （マスターブートレコード）が破損したと思い、インストールディスクをレスキューモードで起動させます。起動オプションで、見つかったデバイスはマウントするを選択します。/media/sysimage で SSD がマウントされました。grub-install で MBR を再構築します。
sh-3.00# chroot /mnt/sysimage sh-3.00# grub-install /dev/hda 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'. # this device map was generated by anaconda (hd0) /dev/sda
うまくいったようなので再度 SSD から起動させます。変更が必要な部分は書き換えたはずなのですが、まだ下記のエラーが発生して起動できません。どうやらこの方法でのクローン作成は VG 名を変更しては起動できないようです。
仕方がないので、もう一度インストールディスクをレスキューモードで起動させます。
まずは、grub.conf と fstab の書き換えを行っておきます。VolGroup1003 → VolGroup00 と再修正します。UUID の方は SSD の UUID じゃないとダメなので修正した内容のままで正しい状態です。
chroot /mnt/sysimage vi /mnt/sysimage/etc/fstab vi /mnt/boot/grub/grub.conf
次に VG 名を再変更します。vgchange コマンドで VG 名を元通りの VolGroup00 へ戻してやります。vgrename や vgchange はレスキューモードだと /sbin 配下に存在しないため、SSD 側の /media/sysimage/sbin から /tmp へコピーしておきます。
vgchange 実行前に umount /dev/VolGroup1003/LogVol00 する必要があるのですが、レスキューモードの場合はマウントの仕方が違うようで、下記のように、ちまちま umount してあげる必要があります。マウントを解除したら３つのコマンドを実行。これは前述してきた方法と同じですね。
cd /tmp cp /mnt/sysimage/sbin/vgchange ./ cp /mnt/sysimage/sbin/vgrename ./ umount /mnt/sysimage/boot umount /mnt/sysimage/sys umount /mnt/sysimage/proc umount /mnt/sysimage/dev/pts umount /mnt/sysimage/dev umount /mnt/sysimage/selinux umount /mnt/sysimage swapoff /dev/VolGroup00/LogVol01 ./vgchange -an VolGroup1003 ./vgrename K6qWBo-uvhY-5tgW-IZir-satd-4xnQ-8jUBBF VolGroup00 ./vgchange -ay VolGroup00
以上の作業をもちまして、SSD ブートが可能となり、元ディスクと同じクローン環境として移行完了しました！｡･ﾟ･(ﾉ∀`)･ﾟ･｡
こんな面倒な方法をとらなくても、もっとよい方法があると思います。こんなことならば、TrueImage でクローン環境を作った方が時間的労力を考えると、はるかによかったと思いました。
おしまい。
売り上げランキング: 73
市販されているソフトウェアの中ではこれが一番だ
ほとんど隙なしの完成度で唸ってしまう？ 旧バージョンの不満がほぼ解決された。 やっぱり常備品、でもパーティション操作がやっぱり付かなかった
コメントやシェアをお願いします！