mieki256's diary

GParted Live CD を使って、転送元HDDの各パーティションを縮小リサイズして、全体的にSSDの容量に ―― 256GB以下に収める。

_GParted -- A free application for graphically managing disk device partitions
_GParted -- Download

この手の作業に必要になるのは以下のツール。

• GParted
• ddrescue
• testdisk

この3つは GParted Live CD に入ってる。

ちなみに、KNOPPIX 9.1 DVD が起動するUSBメモリでも試してみたけれど、そちらに入ってる GParted はリサイズ処理すらエラーを出してしまって正常に動かなかった。GParted Live CD を使ったほうがハマらずに済むかも。ISOのサイズも小さくて済むし。

gparted-live-1.6.0-3-i686.iso (483MB) を入手。

USBメモリにISOを入れて起動させるために、UNetbootin (unetbootin-windows-702.exe) も入手。

_UNetbootin - Homepage and Downloads

Windows10 x64 22H2上で UNetbootin を起動して、Gparted の iso をUSBメモリに書き込んだ。USBメモリは16GBの品を使ったけれど、今回は 2GB 程度あれば足りたかもしれない。

何はともあれ、Gparted Live CD が入ったUSBメモリで起動。

• VGA云々と表示されてる3番目の項目を選ぶ。
• Keymap はそのまま。
• Laungauge は Japan を選択。15 を入力。
• 0を選んでX11を起動。

自動で Gparted が表示されるので、各パーティションを縮小リサイズ、かつ、移動して詰めていく。適用ボタンをクリックすると、指定した処理が実際に行われる。

GParted でリサイズや移動をして、SSDの容量、256GBより少ない感じにまとめたら、GParted を終了。Terminal を起動。ddrescue を使って、セクタ単位で、ディスクを丸々コピーする。

一般的には dd を使って作業することが多いらしいけど、ddは不良セクタがあった場合にそこで処理が止まってしまうらしい。ddrescue なら不良セクタはスキップして処理してくれるのだとか。

dd にしろ ddrescue にしろ、転送先SSDの容量が小さいので、「これ以上転送できない」「サイズがおかしい」的なエラーが最後に出てくるけれど、そこは無視して作業する。後で testdisk を使って不整合な部分を修正してしまうので…。

転送元HDDが /dev/sda、転送先SSDが /dev/sdc なら、以下のように打つ。

sudo ddrescue -f -v /dev/sda /dev/sdc logfile.log

-f は上書き指定。-v は詳細表示(進捗状態の表示)。logfile.log は、ログファイル名。

今回の、SATA接続で、HDD → SSD に256GBを転送する処理では、1時間ほどで終わってくれた。なんだか早過ぎる気もするけど…。

testdisk を使って、パーティションテーブルがおかしくなった状態のSSDを修復。

sudo testdisk

操作は以下を参考にした。

_パーティション情報を削除してしまったHDDの復旧を Ubuntu 上の TestDisk を用いて復旧する。 - KusoBoze is here.

HDDやSSDのパーティションには、UUIDというIDがついてる。このUUIDは重複しない値がついてるはず、ということになっている。

昔の Linux は /dev/sda1 とか /dev/sdb2 とか、そういう記述形式で各パーティションを指定していたけれど。この形式ではHDDやSSDを接続するポートを変えてしまったときに、各パーティションの判別名も変わってしまうので都合が悪い。そこで、各パーティションにUUIDをつけて管理しようということになったらしい。

以下で、パーティション一覧や、各パーティションのUUIDが確認できる。

lsblk
sudo blkid

ddrescue でコピーした直後は、HDDとSSDの各パーティションに同じUUIDがついてしまっている。このままだとUUIDを使ってパーティションを特定できなくなる…。どちらかのUUIDを変更したい。

しかし、これが上手く行かない。本来なら、GParted でパーティションを右クリックして「New UUID」を選べば変更できそうなのだけど…。「e2fsck -f を使え」云々のエラーしか出てこない…。どうしたもんか…。

Linuxは、/etc/fstab というファイルで、どのパーティションをどのディレクトリにマウントするか指定できるけど。その際、UUIDではなくて、ラベル(LABEL)を使うこともできるらしい。

今回、重複したUUIDが存在していてパーティションの特定ができない状態になっているし、どう考えてもラベルのほうが人間には分かりやすいので、そのような指定に修正することにした。

GParted で、各パーティションにラベルを設定する。右クリックして「Label File System」と書かれた項目を選べば、ラベル名を入力するダイアログが開く。

今回は以下のような指定にした。

• / にするパーティション : ROOT
• /home にするパーティション : HOME
• linux-swap にするパーティション : SWAP

SSD (/dev/sdc) 内の、/etc/fstab が入ってるパーティション(/dev/sdc1)を一時的にマウントして、/etc/fstab を修正できるようにする。

sudo mkdir /mnt/sdc1
sudo mount /dev/sdc1 /mnt/sdc1
cd /mnt/sdc1
cd etc
sudo nano fstab

/etc/fstab を編集。UUID=xxxxx と書かれている部分を、LABEL=ROOT といった感じで書き換えておく。

# /etc/fstab: static file system information.
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
LABEL=ROOT /               ext4    errors=remount-ro 0       1
LABEL=HOME /home           ext4    defaults        0       2
LABEL=SWAP none            swap    sw              0       0

SSDにgrubをインストール。以下を参考にして作業させてもらった。

_HDDからSSDへの換装作業ログ
_UbuntuのHDD 2TBからSSD 512GBへのLarger HDD to Smaller SSD換装を行う
_ubuntu BOOT Grub Restoring 起動 復旧 | 市野メモ

実機をシャットダウン後、電源を入れたら、何故かHDD側から Ubuntu Linux が起動してしまったのだけど。これ幸い(?)と、まだマウントされていないはずのSSDに対してgrubをインストール。

sudo mkdir /mnt/sdc1
sudo mount /dev/sdc1 /mnt/sdc1
sudo mount --bind /dev /mnt/sdc1/dev
sudo mount --bind /dev/pts /mnt/sdc1/dev/pts
sudo mount --bind /proc /mnt/sdc1/proc
sudo mount --bind /sys /mnt/sdc1/sys
  
sudo chroot /mnt/sdc1
sudo grub-install /dev/sdc
sudo grub-install --recheck /dev/sdc
sudo update-grub2
exit

umount /mnt/sdc1/sys
umount /mnt/sdc1/proc
umount /mnt/sdc1/dev/pts
umount /mnt/sdc1/dev
umount /mnt/sdc1

この状態で、シャットダウン。HDDを外してSSDだけにして電源を入れてみたところ、SSD側から起動してくれた。

色々ググってたら、e2fsck -f を何度も試すとUUIDが変更できる状態になるかも、という話を見かけた。

HDDとSSDの両方を繋いだ状態で作業するとどうも上手く行かないので、実機からHDDを取り外して、Windows10 x64 22H2 がインストールされてる別PCで作業してみることにした。USB3.0接続HDDスタンド Logitec LGB-1BSTU3 にHDDを差して、Windows + VMware 上で動かした Ubuntu Linux 22.04 LTS からHDDスタンドにアクセス。ちなみに、VMware利用時、USB機器を「ホストから切断」すれば、そのUSB機器は仮想PC側で利用できるようになる。

HDD (dev/sdb) に対して、e2fsck -f を3回ぐらい試してみた。

$ sudo e2fsck -f /dev/sdb1
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking iノードs, blocks, and sizes
Pass 2: Checking ディレクトリ structure
Pass 3: Checking ディレクトリ connectivity
Pass 4: Checking reference counts
Pass 5: Checking グループ summary information
ROOTOLD: 757242/3842048 files (0.5% non-contiguous), 10278914/15360107 blocks

$ sudo e2fsck -f /dev/sdb1

$ sudo e2fsck -f /dev/sdb1

この状態なら、UUIDの変更ができた。

sudo tune2fs /dev/sdb1 -U random

HDDに対してUUIDの変更をする場合、書き換えには数分ほどかかるっぽい…。

そういえば、本来この手のツールは、SATA接続されている状態を前提にして使うことを、うっかり失念したまま作業してしまった…。USB接続では上手く行かない時があったりするのかもしれない…。どうやら今回は上手く行ったっぽいけど…。

HDD側のUUIDを変更できたので、調子に乗ってSSD側のUUIDまで変更してしまったところ、SSDから Ubuntu Linux を起動できなくなった…。カーネルのロードすらできない。

おそらく、grub にカーネルがある場所をUUIDで指定していたのに、そのUUIDが変わってしまったので、カーネルがあるパーティションを見つけることができず、起動できなくなったのだろう…。

修復には、別途、OSが起動する何かを用意しないといけない。Ubuntu Linux 22.04 LTS が起動するUSBメモリを作成して、そちらで起動して、grub を再インストールした。

余談。USB2.0メモリを使ってこのあたりの作業したらとんでもなく時間がかかった。OSが起動するまで、USBメモリのアクセスLEDがずっとチカチカ。10分以上経過してから、ようやくデスクトップ画面が出てきた…。

SSDから起動するようにしてみたら、"Scanning for BTRFS file system" なるメッセージが表示されたタイミングで、そこから30秒ぐらい待たされる状態になってしまった。

Linux Mint 関係の掲示板で同種の不具合事例を目にした。解決策も書いてあった。

_SOLVED "Scanning for BTRFS file system" during boot - Linux Mint Forums

sudo apt-get purge btrfs-tools
sudo update-initramfs -ukall
sudo apt purge btrfs-progs
sudo update-initramfs -ukall

おそらく、btrfs関連パッケージを削除しつつ、initramfs なるものを作り直しているのだろう…。

HDDからSSDに換装してみたところ、OSのデスクトップ画面が出てくるまで2分かかっていたのが、40秒で出てくるようになった。

たしかに速くはなった。でも、期待していたほど速くもない印象。と言うのも、もしこれが Debian Linux なら、HDDにインストールしてある環境でも1分ぐらいで起動してくれるので…。

Ubuntu Linux は、何故か起動が遅い…。いやまあ、こちらが把握してない色々なサービスが山ほど立ち上がってるとか、サポートしてるハードウェアの種類が多くてハードウェアのチェックで時間がかかってたりするのかなと想像するのだけど。

とは言え、Webブラウザの起動等、明らかにHDD利用時より速くなった気もする。これなら、Webブラウザを起動させようかな、という気分にもなれそう。今までは起動時間が長過ぎて、起動させなきゃならんのか、やだなあ…みたいな気分になっていた…。