仮想環境研究所

HDD/SSDをクローンしただけでは起動に失敗する

(結論修正 20240125 20:15JST)
 下記修正してなかったことにさっき気がついた。fsckでdirty bitを削除すると、その直後は直るけれども、またダメになる。EFIパーティション(これがなんとまあ20世紀の遺物VFAT!)がぶち壊れていたのでフォーマットし直し、クローン元のファイルをコピーし直しgrubを再インストールで解決。

(結論)いろいろ苦労したけれど、fsckでなおった。どうやらEFIパーティションのコピーに失敗してファイルが壊れ、さらにMicrosoftの自動修復プログラムが動くと他のファイルをぶち壊す。

 私物のCriteaVF3のHDDがだんだん調子悪くなってきて、

Ubuntu、Win10共に時々フリーズする
時々grubに入らないでWindowsブートローダーに行く

など、どう考えてもヤバい状態を呈してきた。いい加減古いPCなので、見切りをつけてもいいのだけれど、やれることはやってみようかとSATAのSSDをポチった。

 そもそも元入っていた500GBのHDDは換装して1TB化済み…
$ sudo fdisk -l の結果
ディスク /dev/sda: 931.51 GiB, 1000204886016 バイト, 1953525168 セクタ
Disk model: HGST HTS721010A9
単位: セクタ (1 * 512 = 512 バイト)
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O サイズ (最小 / 推奨): 4096 バイト / 4096 バイト
ディスクラベルのタイプ: gpt
ディスク識別子: 373B9346-9FAF-4F8E-97E4-xxxxxxxxxxxx

(ディスク識別子は慣例に従って伏せました。必要性はわからんけど)

 で、新しいSSDはこちら。Western Digital  WD Green WDS100T3G0A



 西部数(Western Digital)のSSDは緑だの青だの色でグレードが分けられているようだけれども、別にそんなヘビーユーズじゃないから緑でいいだろ。

 で、裸族のお立ち台があるので、この新SSDをそこに立たせてもいいのだけれど、後々のためのバックアップの意味も含めて、1台USB外付けHDDを仲介します。UbuntuなどLinuxのライブメディアでPCを起動してsdaをフリー状態にしておいてから、次の例に示すようなコマンドを打ちます。仲介したHDDにはSeagateEXPANSIONというボリュームラベルが付いていて、Ubuntu Liveメディアで起動したら、/media/ubuntu/SeagateEXPANSIONという場所にマウントされていました。フルパスを間違えずに打つ自信がなかったり面倒くさい時には、ファイルマネージャーでファイルコピーをしておいて、ターミナルに[shift]+[ctrl]+[v]で貼り付けます。

$ sudo dd if=/dev/sda of=/media/ubuntu/SeagateEXPANSION/hogehogebkup.img status=progress

 ブロックサイズを指定したければbs=128Mなどと打ってもいいけれども、なんかあまり速さは変わらない。あと、status=progressを打たないと、どこまで進んでどのくらいの速度でやっているのか全くわからずイライラする。
 で、だいたい120MB/sくらいの速度でコピーされてた。
 コピーが終わったら、PCの腑分け。裏蓋を剥がし蓋を裏返したところ。ほこりひどいな。





 で、この取り出したHDDとSSDを差し替えて裏蓋を閉じて、再度、Ubuntu LiveでPCを起動。
 あ、それで1回めにLiveメディアから起動したとき、そもそもよく理解していなかったのだけれど、UEFIで起動するPCは、BIOSで「どのデバイスを優先するか」みたいなのが表示されるからそのつもりでいると、USB端子に接続したLiveメディアが表示されていない。我が家のPCではCriteaVF3の場合だけのようだけれど、UEFIのロゴ表示までに[f2]を押してUEFI画面に入ると、なんだか起動領域のラベルらしきものが表示されているけれども、USBストレージは表示されていない。
 そこで、第1位のところでenterを打つと、それまで表示されていなかった、接続されているストレージの起動可能部分がすべて表示されるので、ここから該当デバイスの領域を選ぶ。で、変更を保存して再起動すると、無事、USB Liveメディアから起動できる。
 で、起動したら今度はバックアップ時の逆。
$ sudo dd if=/media/ubuntu/SeageteEXPANSION/hogehogebkup.img status=progress
 これもbs=128Mなどとブロックサイズを指定しなくても、120MB/sくらい出ていた。ちなみに、我が家の裸族のお立ち台は、USB2.0以下らしくてコネクタ部が白色で、ここに元sdaだったHDDを挿してif=sdc of=sdaでやってみると23MB/sくらいの速度しか出ず、イライラする。

 で、無事新しいsdaたるSSDにコピーが終わったら、Ubuntu Liveを終了し、LiveメディアをPCから取り外して、再起動。ここからが今回表題の本題。

 まず、grubが起動しないでいきなりWindows10の起動が始まった。そして、このエラー画面。

 しかしながら、これは待っていれば処理が終了して再起動がかかり、問題なく(一見)Windows10のデスクトップが立ち上がった。
 変なのー、と思いながら、再起動をかけるも、やはりgrubには行かない。おかしいね。とは言え、さっきの自動修復らしき動作の過程での再起動でもgrubに行かなかった。普段はWindowsアップデートの再起動時にもgrubに行って逆に面倒なのに。
 ということで、[f2]連打でUEFIを呼び出すと、
 これはさっきの画像の再掲だけれどもこれと同様にUbuntuをちゃんと表示することができて、変更を保存して再起動すると、

ちゃんとgrubが来るし、(iPhone8のへっぽこカメラだとピントが合わなかった)


ちゃんとUbuntuが起動した。

 やれやれめでたしめでたし…と思ったら、再起動すると…あれ、UbuntuもWin10も起動しないでUEFI画面に行くぞ。そして、bootページを見てみると、UbuntuもWindowsもなくなっている。なにこれ?

 再度、イメージファイルからSSDにコピーしてみた。さっきは勝手にWindowsブートローダーに行ってしまったので、[f2]連打でUbuntuを指定して起動。あれ、ちゃんと起動する。しかし、2回めにはまたgrubに行かなくなった。そこで、Windowsブートローダーを明示的に指定して再起動すると、1回め(自動的にWInブートローダーに飛んだとき)同様、なんかエラーがあるよと表示して自動修正、以降はWin10は問題なく起動できるようになるも、Ubuntuは再起不能。
 そこで、grubが逝っちゃってるなと思って、改めてLiveメディアで起動して、ターミナルから
$ sudo grub-install /dev/sda
と打っても、インストールできない。

 ここからが泥沼にハマりだす。割り切って、Ubuntu再インストールしてしまえ、と思ってLiveメディアの「Ubuntuをインストールする」をやってみると、なぜか

GRUBを/dev/sda*にインストールできません
grub-install/dev/sda* の実行に失敗しました。
これは致命的なエラーです。

と、ここ↓に出ているのと同じエラーが出る。

Ubuntu日本語フォーラム
インデックス » 初心者サポート » grub-install/dev/sudaにインストールできない
2021-06-19 14:59:16

 で、余計な問題に引っ掛かり始めて寄り道になるのだが、

Qiita
Ubuntuインストール時「’grub-install /dev/sda’ の実行に失敗しました。」 エラーの解決方法
@riiiii
投稿日 2023年06月26日
 ここに指示されている通りにやっても、うまくいくのは4回に1回くらい。で、sdaにインストール済みのUbuntuを削除してインストールするのを選んでも、うまく行ったり行かなかったりで、原因がよくわからない。
 とりあえずそっちの対策は本題ではないので放置で、改めてイメージファイルをSSDに書き出してUbuntuを利用可能にする方法を検索。

 グーグル先生で「Ubuntu hdd クローン 起動しない」と検索すると、

AOMEI
クローンしたSSDが起動しない!解決策は?
BCD領域を修復する
SSDはGPT形式である場合、必ずブート領域の修復が必要になります。ディスクをクローンする時、起動リストもクローンされますが、実際にOSが入っている番地が変わってしまうことがあります。リストの番地を参照してもその番地にOSがいないので、SSDが起動できなくなってしまうんです。

 若干書きっぷりが心許ない気がするけれども、まあ、そういうことだろうとおおよそ予測はついている。

はてなブログ
SSDを別のPCにつないだらLinuxが起動しなくなって弱った
白樺
2020-02-04

USBスティックのArchを起動して,問題のディスクをマウントして,arch-chrootして,mkinitcpio -p linuxを実行したらうまく行ったと。
早速真似をしたら,ずばり起動しました。
Linuxというか,Arch Linuxのブートプロセスのことがよくわかっていないのだけど,mkinitcpioというのは,
mkinitcpio は initial ramdisk 環境を作成するために使われる Bash スクリプトです。mkinitcpio(8) より:

 へー。Ubuntuにはそういうのはないのか?

 更にグーグル先生。「ubuntu hddクローン」。
HDDからSSDへの換装作業ログ
平林孝太@東京大学

 Ubuntu14.04でだいぶ昔のバージョンですが、
 grub のインストール
 /dev/sda1 の fstab も同様に編集して再起動すると、  まず HDD (/dev/sda) のブートローダが起動して、  HDD の /etc/fstab の設定を参照して SSD が / にマウントされる、  という中途半端な状態になる。  SSD 単独でブート可能にするために /dev/sdb に grub をインストールする。 
この辺が関係あるかどうか、ですな。
 ちなみに、grubを見に行けなくなったパーティションにUbuntu20.04をインストールし直して、その後、元々使っていたUbuntuのディレクトリをまるっとコピーすると、 /boot/grub/grub.confに書いてあるUUIDが合わなくなっているので、grubが立ち上がらなくなるが、UUIDを修正してやると、grubは立ち上がり、その後「カーネルがねえよ」というエラーを吐いて止まるというところまで確認した。

20231126 01:55JST追記

 グーグル先生で「ssdクローン gpt ずれる」と検索。

Tenoshare 4DDiG
【Windows10/11】SSDへのクローン後、起動しない?! スタートアップ 修復を実行
加藤篤人            最終更新日: 2023-11-10 16:50:49
  •  エラーコード0xc000000fが出た
    OSの起動が正しく行えなかった場合には、0xc000000fというエラーが表示されます。BCDファイルが紛失していたり、破損していたり、その他システムファイルの破損が原因で発生します。破損しているファイルを、修復することでエラーコード0xc000000fを回避できます。

対処4.BCD領域を修復する
SSDはGPT方式であるため、Boot領域の修復が必要になります。ディスクのクローンを作成する場合には、起動リストもクローンされます。しかし、実際にOSが入っている箇所が微妙にズレることがあり、SSDが起動できなくなることがあります。その時には、インストールメディアから再起動を行い、コマンドプロンプトで指定されたコマンドを実行する必要があります。

ガジェットブログ「オニオン座」
SSD交換でクローンソフトを使ったら失敗したので、SSD/HDDクローンマシンを使ったらうまくいったお話
2022.05.14
よくよく調べると、GPT形式のSSDをクローンした場合、クローン先のSSDでは起動リストの番地が変わってしまうことがあるためブート領域の修復が必要との情報を得ました。ブート領域(BCD領域)の修復には結構面倒な手間がかかりました。

 だんだん情報が集まってきました。

20231126 2:20JST追記

 再びグーグル先生で検索、「ubuntu bcd」まで打ったら「edit」と補完された。あ、あったね、bcdeditって。

Zenn
WindowsとUbuntuのデュアルブート環境を作る(Windows Boot Manager+rEFInd)
2021/02/19に公開

Windows Boot ManagerからrEFIndを起動してそこから起動するOSを選択する

 Winのブートマネージャーから起動OSを選択するパターンですね。

b.gott.jp
Ubuntuのブートエントリが消え去ったときの対処    
2019-07-15
ASUS ROG STRIX Z270Fを使っています。原因不明ですが,時々Ubuntuのブートエントリが消え去ります。久々に再発して,対処に苦労したのでメモ。

 あ、これ我が家のCriteaVF3に起きたこととそっくりじゃないの。

20231126 13:50JST追記

 HDDクローン用機械を使うとあっさりと成功するような話があり、そう言えば買ったきり使ってないのがあったと思いだして使ってみた。
 結論:今度はUbuntuは起動できるがWin10が起動できない。

 まず、クローンニングマシンの取り出し。玄人志向。画像回転メンドクサイのでそのまま貼り付け。

 中身背面。
 クローンニングを指向しているのにスイッチ位置ときたら…。おまけに左のスライドスイッチが固くて、中途半端な位置で止まり、



「NORMAL」と「CLONE」両方のインジケーター点灯。スイッチ位置を正しく設定しないと!

 クローンニング台の電源が切れている状態で、2台のストレージを挿入。VF3のマウント金具は付いたままでOKだった。

 背面の電源スイッチをONにし、中央のボタンを長押しするとクローンニング開始。
 HDD1、HDD2及び進捗バーのLEDが激しく点滅するのでぶっ壊れているのかと心配になるが、これで正常。進捗バーは終了した分が点滅から点灯に変わる。
 1TBのクローンニングにだいたい4時間半かかった。まあまあの速度かな。

 で、SSDをPCに戻して、起動してみる。UEFIでUbuntuを指定して起動すると、ちゃんとgrubが表示され、Ubuntuが起動された。これまでのddコマンド使用と違って、2回め、3回めも問題なく起動できた。
 しかし一方でWin10をgrubから選択すると…
エラー: file '/EFI/Microsoft/Boot/bootmgfw.efi' not found

となって起動できない。
 グーグル先生にこのエラーメッセージをそのまま貼り付けて検索。

ask Ubuntu
Ubuntu 20.04 fails to boot after I ran "/bcdedit set {bootmgr} path \EFI\ubuntu\grubx64.efi" in Windows
                       Asked                        2 years, 3 months ago                    

 えーっ、さっき、bcdeditで直すという話があったけれど、それやったら今度はUbuntuが起動できなくなったってこと?

Qiita
grub画面にwindows10が認識されない問題
最終更新日 2019年11月18日投稿日 2019年11月18日

その理由はwindows10をインストールしているHDDのパーティションがMBR形式になっていたからであった。
windows上でMBR2GPT.exeを使用することでGTP形式に変更ができた。

 我が家とは原因が違うようで。

Ubuntu日本語フォーラム
Windowsを起動すると次回PC起動時にGRUBがエラーになります
2022-05-01 17:12:42
 この問題は、元々はgrubの動作がおかしいということのようですが、
問題の状況としてはこのページと同じく、Windowsのbcdeditで設定していてGRUBがエラーになっていました。
https://askubuntu.com/questions/1356436/ubuntu-20-04-fails-to-boot-after-i-ran-bcdedit-set-bootmgr-path-efi-ubuntu


bcdeditでWindows Boot Managerの項目を書き換えてGRUBを起動させていますが、この設定はUbuntu 20.04で問題になるようです。
(インストールし直すつもりでしたが、その前に試しにVirtualBoxの仮想マシンにWindows 10とUbuntu 20.04をインストールして同じ設定をしてみた結果、同じエラーが再現しました。)
 …やっぱり単にbcdeditすると今度はgrubをダメにしそう。
 そもそもbcdeditってどういうもの? gottさんが「これが本質」と紹介した所

ask Ubuntu
I need to see the BCDedit for a Windows10/Ubuntu install both by Wubi and by separate partition
Asked 7 years, 8 months ago
Modified 9 months ago

を見ると、

bcdedit /copy {bootmgr} /d "Ubuntu Secure Boot"
とか
bcdedit /set {guid} path \EFI\ubuntu\shimx64.efi
って出てくるけど、「{ }」の中は自分の環境値を代入するの?

@IT
Windowsのbcdeditでブートメニューの表示順序やデフォルトを変更する
 画像を引用すると、

ということなので、そのまま??


20231126 1430JST追記

 なんかbcdeditは暗い未来しか見えず、grubが生きている現状、grubにWinのブートローダーを探しに行かせてみようかと。しかし、/boot/grub/grub.cfgを見ても、Windowsという文字列は見つからない。grub.cfgにWinのブートエントリーをどうやって書くのか検索してみた。

グーグル先生に「grub.cfg windows 10 entry」。

ozawaのブログ
Win10をgrubでブート
20170701

/etc/grub.d/40_customを編集します。
 そんな所に書いて置くのか。ちなみに、nautilusをsudoして起動すると、efiパーティションが自動でマウントされていたりとかすごいことを知った。

 なお、上のキャプは、以下の記事に従ってファイルを探したもの。

為せばnull
GRUBがデフォルトで起動するOSを変更する
2021/10/16 
/etc/default/grubを弄ります。

 とりあえず当方でまず必要な操作はozawaさんのほう。で、lsblkの結果がやたらとloopばっかりなので、SSDの該当部だけ。
sda      8:0    0 931.5G  0 disk
├─sda1 8:1 0 300M 0 part
├─sda2 8:2 0 99M 0 part /boot/efi
├─sda3 8:3 0 128M 0 part
├─sda4 8:4 0 871.6G 0 part
├─sda5 8:5 0 857M 0 part
├─sda6 8:6 0 42.7G 0 part /
└─sda7 8:7 0 15.9G 0 part [SWAP]

 で、ozawaさんの場合は
上記の場合だと、sda/sda2にブートローダが入ってます。
自分の場合は、Win10のブートローダが入ってるのは100MBのパーティーションでした。

ということですが、当方は、
ということで、どうやら/dev/sda2が/bootにマウントされ、フルパスで書くと
/boot/efi/EFI/Microsoft
というディレクトリに
/Boot/bootmgfw.efi
があるのかな?

 で、
/etc/grub.d/40_customを編集します
ということなので、


 /bootがあるのはhda2であることは当方も同じなので、「set root=(hd0,2)」でいいはず。この程度の編集なら別に失敗しても起動しなくなるとかはなかろう。
 で、最後に
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
ですな。Centだとgrub.cfgのパスが違うのね。

  ありゃ…。さっきroot化したnautilusでIOエラーって出てたけど、やはり単にnautilusの問題ではなかったか。ということは、この当方で起きている問題、ある程度わかった。/dev/sda2に何か問題が発生していて、クローン後最初に起動した時にはブートローダーが読めるが、何らかの事情で書き換えが行われるとファイルにアクセスできなくなるのだな。よーし、USB Liveメディアで起動して、バックアップしてある/dev/sda2の中身で置き換えたらどうなるかやってみよう。

20231126 16:50JST追記

 うまくいった。
1. まず、LiveメディアでPCを起動して、/dev/sda2をfsckする。
 上図の通りエラーは修復されたけれども、きっとファイルは名前が変更されてどっか連れ出されている。もっとも、こうしないと壊れたファイルを削除することすらできない。
 なお、fsckする前はこの状態。


2. 続いて、/dev/sda2を元のHDDの第2パーティションで上書きする。元のHDDを裸族のお立ち台に挿し、PCをUbuntuをLive起動した上で接続し、端末を開き、lsblkしてみると、/dev/sddになっていた。そこで、
$ sudo mkdir /media/forsda2
$ sudo mkdir /media/forsdd2
$ sudo mount /dev/sda2 /media/forsda2
$ sudo mount /dev/sdd2 /media/forsdd2
と準備して、
$ sudo nautilus
で見てみるとこのとおり。

sda2のルートディレクトリはゴミファイルでいっぱい。


/EFIディレクトリに/bootがなくなっている。

 sdd2の/bootディレクトリの中身。sda2は/bootがないから比較できない。

/EFI/Microsoftディレクトリは違いなし。


/EFI/Microsoft/Recoveryも差異なし。

/EFI/Ubuntuも差異なし。

さっきアクセスできなかった/EFI/Microsoft/bootディレクトリ。sda2はfsckでファイルが持っていかれたので少なくなっている。

 これを確認して、sdd2の内容でsda2を上書きし、PCを再起動…Ubuntu無事起動。ただし、さっき
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
がWinブートローダーを見つけられずにコケたためにぶっ壊れているみたいで、grubが表示されずにUbuntuが起動開始する。まあいいや。

 続いて、再起動をかけて、UEFI画面でWinブートローダーを選ぶ。またしてもエラー発生の画面になり、修復を始める。しかし今回はその後でUbuntuが起動できなくなることはなかった。
 Windowsを起動したければ都度[f2]を押してUEFI画面を呼び出し、起動優先順位を編集すればいいのだけれど、元通りになっていないのは気持ちが悪いので、
/etc/grub.d/40_custom
を元に戻した上で、
$ sudo grub-mkconfig -o /boot/grub/grub.cfg
 これで元通りに、grubによるブートローダー選択画面が出るようになった。

20231203 1615JST 追記
 またgrubが起動しなくなった。そこで、先日同様、Live USBから起動して/dev/sda2の中を見てみると、/EFI ディレクトリから /Ubuntu ディレクトリが消滅していた。
 で、fsckしてみると、またまたdirty bitがどうのこうのと…。直ってないな。
 grubのインストールを試みる。しかし、ファイルシステムエラーとは別の理由のエラーが発生してインストールできない。「grub-install: error: failed to get canonical path of `/cow'.」とな。
 このエラーメッセージをそのままグーグル先生で検索。

ubuntu Japanese Team wiki
UbuntuTips/Others/ReinstallGrub2

※ 各行の最初にある '$' , '#' はシステムが表示するものです。それぞれ「ユーザー権限」「管理者権限」で実行する事を示します。一緒に入力(コピー&ペースト)しないでください。

$ sudo mount /dev/sdXZ /mnt
$ sudo mount /dev/sdXY /mnt/boot/efi
$ sudo mount --bind /dev /mnt/dev
$ sudo mount --bind /dev/pts /mnt/dev/pts
$ sudo mount --bind /proc /mnt/proc
$ sudo mount --bind /sys /mnt/sys
$ modprobe efivars
$ sudo chroot /mnt

# grub-install /dev/sdX
# update-grub
# exit

$ sudo umount -lf /mnt/sys
$ sudo umount -lf /mnt/proc
$ sudo umount -lf /mnt/dev/pts
$ sudo umount -lf /mnt/dev
$ sudo umount -lf /mnt/boot/efi
$ sudo umount -lf /mnt
ということなのだけれど、(うちではsdXZがsda6、sdXYがsda2)

# grub-install /dev/sdX

から進めなくなる。こういうエラー。

Installing for i386-pc platform.
grub-install: warning: this GPT partition label contains no BIOS Boot Partition; embedding won't be possible.
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

 そこで、「grub-install: error: will not proceed with blocklists.」をグーグル先生にて検索。

趣味の記録部屋
GRUB2 の grub-install で遭遇した問題
公開日: 2021/09/02
最終更新日: 2022/03/08

BIOS boot partition を作る場所は、現在の1つ目のパーティションの先頭セクタ 2048 よりも前になります。GPT で通常のパーティションを切るとき、大抵はセクタ 2048 以降を使って作っているはずなので、たとえディスクいっぱいいっぱいのパーティションを作ってしまっていたとしても、2048 以前のセクタに空きがあると思います。

 なるほど。grubインストールのエラー以降の操作のコンソールコピペを長々とするとこのブログの文字数制限にひっかかるので、次の記事に移動するよ。

最近の「公開」カテゴリーもっと見る

最近の記事
バックナンバー
人気記事