私のラップトップには元々 128GB の M.2 SSD と 1TB HDD が搭載されていました。システムは Windows とのデュアル ブートとして構成されています。/boot/efi パーティションは /dev/nvme0m1p1 にあり、元のルート パーティションは /dev/sda3 にあります。
元の nvme0n1 のイメージを zip 圧縮し、nvme0n1 を 1TB M.2 SSD と交換し、元のイメージを新しい SSD にクローンしました。その結果、クローン作成が完了すると、Windows または Ubuntu の /dev/sd3 バージョンのいずれかを起動できるようになりました。
次に、新しい ext4 パーティション nvme0n1p6 を作成し、/dev/sda3 パーティションをそこにクローンしました。クローン作成後、初めて update-grub2 を実行したときに、パーティション UIDD を変更するのを忘れていました。その後、gparted を使用してパーティション UIDD を変更し、update-grub2 を再実行して、/dev/nvme0n1p6 の新しい UIDD でイメージが見つかったことを確認しました。
新しいイメージの /etc/fstab の UIDD= ステートメントにスペースを挿入したことを発見するのに 6 時間費やした後、新しいイメージで起動することができました (私の校正スキルは改善の余地があります)。そのイメージがロードされたら、新しい ubuntu の選択を新しい grub.cfg の先頭とデフォルトに移動するために、update-grub2 を再度実行しました。
最後に問題: 再起動後、表示される grub メニューは、元の /dev/sda3/boot/grub フォルダーの grub.cfg のままです。
/nvme0n1p6 用に生成された grub.cfg を /sda3 にコピーすると、その後の起動時に新しい grub.cfg が表示されるようになります。
/sda3 の grub.cfg ファイルの名前を変更すると、再起動時に grub がコマンド ラインで停止します。コマンド ラインを終了すると、Windows OS がロードされます。/sda3 に有効な grub.cfg を復元できるライブ USB イメージを使用して、この問題を修正できます。
実行する必要があるコマンドは update-grub コマンドだけではないと思います。/nvme0n1p1 に保存されているイメージを更新する必要があるのではないかと思います。これは何らかの grub install を実行することで実現できるのでしょうか?
答え1
免責事項: 私は完全に間違っている可能性があります。
情報によると、ハード ドライブ ( /dev/sda3) には Windows が 1 つ、Ubuntu が 1 つインストールされているようです。このハード ドライブのインストールを H と呼びます。次に、インストールを SSD に移動する必要があり、新しい SSD パーティションを作成し、ハード ドライブのインストールをその SSD パーティションにクローンしました (新規インストールを実行したいのですが、これは質問の主題から外れます)。この SSD インストールを S と呼びます。
私の知る限り、問題は S のインストールが完了した後に grub をまったくインストールしなかったことです。そのため、システムにインストールされている grub は、インストール H [1] に属したままです。したがって、grub.cfgインストール H ではまだ現在使用されていることになります。
grub がインストール S から使用するようにするにはgrub.cfg、S から EFI パーティションに grub をインストールする必要があります。
インストール S を起動して実行します:
$ sudo grub-install dummy
$ sudo update-grub
シナリオを誤解していたり、コマンドでエラーが発生している場合はお知らせください。
答え2
新しい M.2 SSD から Ubuntu を実行できるようになったので、1 つの M.2 ポートを備えたラップトップで、nvme0n1p1 上の GRUB インストール済みデュアル ブート ローダーを含む 128 GB SSD を 1 TB SSD に交換するために使用した方法を確認します。明確にするために、Windows 10 の大部分は nvme0 のさまざまなパーティションに常駐し、Ubuntu は元々 sda3 のハード ドライブ パーティションに常駐していました。起動すると、nvme0n1p1 は /boot/efi にマウントされます。
nvme0n1 a のイメージを作成します。私は個人的に、イメージ サイズを縮小するためにパーティションを縮小する手順は実行しませんでした。これが必要であると考えられる場合は、他のユーザーがその方法についてのガイダンスを提供しています。
b. イメージを内部または外部の他のドライブに書き込みます。私は以下を使用しました:
dd if=/dev/nmve0n1 | gzip -c > pathToOtherDeviceFolder/nvme0n1.imgこの
-cオプションにより、gzip は標準出力に書き込み、それをファイルに出力します。ライブ イメージ、Ubuntu Live、または Gparted Live を含む USB ドライブからの起動をテストします。通常使用する外部モニターでラップトップをラップトップから取り外してライブ イメージをテストしなかったため、後で問題が発生しました。外部ディスプレイを接続せずに次の手順を実行しようとして数日かかりましたが、ライブ USB ドライブの起動を妨げていたのは、次の手順の結果ではなく、外部ディスプレイ (またはイーサネット) がないことでした。イーサネットを接続して起動を成功させたかどうかは覚えていませんが、外部ディスプレイを接続していた可能性があります。いずれの場合も、ライブ イメージの依存関係があり、その理由はわかりませんが、回避策はあります。起動したら、移動するイメージを含むドライブをマウントできることを確認してください。
電源を切り、元の M.2 SSD を新しいものと交換します。
画像を新しいnvme0n1に移動する
a. USB ライブ ディスクから起動します。(すでにテスト済みです)
b. 移動したいイメージが含まれているドライブをマウントします。(これもテスト済み)
c. イメージを新しい nvme0n1 に移動します。以下を使用しました:
gunzip -c pathToOtherDeviceFolder/nvme0n1.img | dd of=/dev/nvme0n1再び、gunzip は stdout に書き込み、それが dd にパイプされて新しいデバイスに書き込まれます。
新しい nvme0n1 上の新しいパーティションに Ubuntu を移動します。ここでは、sda3 上の元の Ubuntu イメージを再起動することを選択しました。新しい nvme0n1 は元のイメージのクローンなので、これは問題ありません。USB ライブ環境で操作しながらこれらの手順を実行できない理由はわかりませんが、実際に実行した経験はありません。
a. gparted またはその他のツールを使用して、nvme0n1 に新しい ext4 パーティションを作成します。今後、このパーティションを nvme0n1p6 と呼びます。
b. /dev/sda3 (私の場合) 上の Ubuntu イメージを /dev/nvme0n1p6 にクローンします。私は以下を使用しました:
dd if=/dev/sda3 of=/dev/nvme0n1p6c. クローン作成後、gparted またはその他のツールを使用して、nvme0n1p6 のパーティション UIDD を一意の UIDD に変更します。
操作のために nvme0n1p6 で新規を準備します。
a. /dev/nvme0n1p6 をマウントします。マウント ポイントとして /mnt を使用しました。
b. /etc/fstab を変更して、nvme0n1p6 の UIDD を / としてマウントします。nvme0n1p1 は引き続き /boot/efi としてマウントされることに注意してください。変更されたエントリが適切にフォーマットされていることを確認してください。余分なスペースのせいで、
UIDD=何を間違えたのかと悩む時間がさらに数時間続きました。c. この時点で nvme0n1p6 はアンマウントできますが、この手順を省略したと思います。
USB ライブ ディスクからまだ実行している場合は、元の Ubuntu イメージ (私のは /dev/sda3 にあります) を再起動します。
grub メニュー オプションを更新します。
sudo update-grub2
nvme0n1p6 上の元のイメージ、Windows イメージ、新しい ubuntu イメージが検出され、追加されることを確認します。
再起動し、GRUB ブート メニューで新しい Ubuntu イメージを選択します。
新しいイメージに入ったら、次のコマンドを実行します。
a.
sudo grub-installこれにより、/boot/efi (/dev/nvme0n101) 上の grub ファイルが変更され、grub メニュー grub.cfg の場所として sda3 上の場所ではなく、/dev/nvme0n1p6/boot/grub が参照されるようになります。b. `sudo update-grub' は、クローンされた /boot/grub/grub.cfg を、新しいイメージを一番上に配置し、デフォルトとして配置し、代替選択として sda3 上の元のイメージを配置する新しいファイルに置き換えます。
これで、3 つのイメージのいずれかを起動できるはずです。grub-install新しいイメージで が実行されるまで、grub はメニュー構成ファイルを見つけられないため、元のイメージをマシンから削除できないことに注意してください。
幸いにも、私は手順を省略したり、間違って覚えたりしておらず、この方法があなたにとっても役立つことを願っています。