2024-07-29 別ディスクにリカバリしたらパーティションが認識されなかった。対応。
ddでリカバリしたはずなのにパーティションができていない。なぜだ？
lsblk
で見てもパーティションがないってことだ。
Windows側にこのディスクをつないでみるとパーティションがあるのだが。という謎現象だった。
しょうがないのでパーティションを指定してリカバリすることを試みる。
まず、リカバリするイメージをループデバイスにつなぐ。
sudo losetup -fP /path/to/BackupDirectory/Backup_xxx_ymd.img
これでどこのデバイスになっているかを確認。
sudo losetup -a
今回は loop20 だった。
sudo parted /dev/loop20 print
モデル: Loopback デバイス (loopback)
ディスク /dev/loop20: 128GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:
番号 開始 終了 サイズ ファイルシステム 名前 フラグ
1 1049kB 2097kB 1049kB bios_grub
2 2097kB 540MB 538MB fat32 EFI System Partition boot, esp
3 540MB 76.0GB 75.5GB ext4
こんな感じだった。要はイメージのパーティション構成が分かる。
一部手順追加、ここから（2024-09-30）
sudo dd if=/dev/zero of=/dev/sdc bs=4M status=progress
要はゼロ埋めクリアしてからにしようかな。どうもこうしないとうまくいかないっぽい？？
ーーーここまで。
ディスク全体の最初の数MBをコピー:
これには、GRUBのブートローダー部分も含まれます。
sudo dd if=/dev/loop20 of=/dev/sdc bs=4M count=1
さて、これで以前のままのGrubがコピーされたのだろうか？
このまま起動できるといいのだがなぁ。
では次に、バックアップ先のディスクにパーティションを作る。
lsblk で調べて、sdcが対象のディスクとわかる。
sudo parted /dev/sdc
(parted) mklabel gpt
(parted) mkpart primary 1MiB 2MiB
(parted) set 1 bios_grub on
(parted) mkpart primary fat32 2MiB 540MiB
(parted) set 2 boot on
(parted) set 2 esp on
(parted) mkpart primary ext4 540MiB 76.0GiB
(parted) quit
要はここまででバックアップ先のディスクにパーティションを作ったわけだ。
sudo partprobe /dev/sdc
lsblk
sdc 8:32 0 111.8G 0 disk
├─sdc1 8:33 0 1M 0 part
├─sdc2 8:34 0 538M 0 part
└─sdc3 8:35 0 75.5G 0 part
sr0 11:0 1 1024M 0 rom
この状態になったので、イメージからディスクにddでコピーする。
パーティション単位。
sudo dd if=/dev/loop20p1 of=/dev/sdc1 bs=4M status=progress
sudo dd if=/dev/loop20p2 of=/dev/sdc2 bs=4M status=progress
sudo dd if=/dev/loop20p3 of=/dev/sdc3 bs=4M status=progress
とりあえずこの状態で起動できるかテスト。
再起動
起動できない場合、仕方ないのでGrubをインストールする必要があるかもしれない。
要は以前の設定のGrubとは違うことになるけど仕方ないということでね。
Grubの設定。
リカバリディスクのマウント：
sudo mount /dev/sdc3 /mnt/tmp
sudo mount /dev/sdc2 /mnt/tmp/boot/efi
重要なシステムディレクトリのバインド：
sudo mount –bind /dev /mnt/tmp/dev
sudo mount –bind /proc /mnt/tmp/proc
sudo mount –bind /sys /mnt/tmp/sys
sudo chroot /mnt/tmp
GRUBのインストール：
grub-install /dev/sdc
update-grub
chroot環境の終了とアンマウント：
exit
sudo umount /mnt/tmp/dev
sudo umount /mnt/tmp/proc
sudo umount /mnt/tmp/sys
sudo umount /mnt/tmp/boot/efi
sudo umount /mnt/tmp
2024-07-11 古いディスクは完全に消去。
コマンドメモ
lsblk
sudo dd if=/dev/zero of=/dev/sdb bs=4M status=progress
sudo dd if=/dev/urandom of=/dev/sdb bs=4M status=progress
sudo shred -v -n 3 /dev/sdb
2024-06-30 やっぱりddだけでは起動できなかった
要はUUIDが変わったのかな？
2024-07-12 追加設定
Gpe4oさんに聞いた結果
lsblk
で対象ディスクを特定
ライブUSBでシステムを起動:
ライブUSBを使ってシステムを起動します。
SSDのパーティションをマウント:
ターミナルを開き、SSDのルートパーティション（おそらく/dev/sdb3）をマウントします。
bash
コードをコピーする
sudo mount /dev/sdb3 /mnt
必要なファイルシステムをバインド:
proc, dev, sysのファイルシステムをマウントします。
bash
コードをコピーする
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
chroot環境に入る:
chrootを使って、マウントしたファイルシステムにアクセスします。
bash
コードをコピーする
sudo chroot /mnt
GRUBのインストール:
GRUBを再インストールします。/dev/sdbに対してインストールします。
bash
コードをコピーする
grub-install /dev/sdb
update-grub
chroot環境から出る:
exitコマンドを使ってchroot環境から出ます。
bash
コードをコピーする
exit
ファイルシステムのアンマウント:
マウントしたファイルシステムをアンマウントします。
bash
コードをコピーする
sudo umount /mnt/dev
sudo umount /mnt/proc
sudo umount /mnt/sys
sudo umount /mnt
再起動:
システムを再起動し、SSDから起動することを確認します。
bash
コードをコピーする
sudo reboot
というか、外部HDDをつなぐと起動しない。
しかもその後に外部HDDを切断した後も起動しなくなるという謎現象が出ていた。
よって、移行後のSSDから起動した後に以下を実行。
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt-get update
sudo apt-get install -y boot-repair
boot-repair
でもって、念のため外部HDDを接続して、認識された後に、再度上記を実行。
これでとりあえず、外部HDDを接続したままUbuntuが起動するようになった。
2024-06-29
HDD １６０GBが注意表示になっていたので移行。
超古いHDDだったからな。IDEだし。
SSDに移行する。手持ちSSDは１２０GBだった。
VirutalboxにこのHDDを接続して、GnomeのDiskUtilityでパーティション縮小。
一時間ちょっとかかった。
この状態で起動できることを確認。
これをSSDに移行する。
この先の手順としては、ddかな？SSDにコピー。
Grub,ブートローダーの調整必要かも。
SSDから起動でOKのはず。
SSDだからパフォーマンスも爆上げするはず。
とりあえずこれか。gpt4oさんに聞いた内容。
ーーーーー
lsblkコマンドやfdisk -lコマンドでデバイス名を確認します。
例: /dev/sda がHDD、/dev/sdb がSSD。
sudo dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progress
ーーーーー
lsblkで見たところ、今回は
HDD= /dev/sdb
SSD=/dev/sdc
だった。
で、コピー終了。dd終わり。これだけで起動すると楽なんだけどな。