gdiskを使ってハードディスクパーティションテーブルをMBRからGPTに変更しましたが、うまくいきました。ただし、システムの再起動後に「GRUB」が表示され、カーソルが点滅して起動できません。
オペレーティングシステム：Parrot Security Companion
この問題をどのように解決できますか？私のファイルをどのように再取得できますか？
答え1
通常、BIOS スタイル GRUB が MBR にインストールされると、実際の MBR ブロックの後の最初の数ブロックも占めます。ただし、GPTパーティションディスクでは、GPTパーティションテーブルは同じ場所にあるため、既存のGRUBの重要な部分です。〜しなければならない新しいGPTパーティションテーブルで上書きしました。
変換が正しく実行されると、ファイルに問題はありません。損傷はGRUBブートローダに制限されます。このブートローダ（BIOSスタイルシステム用のバージョン）では、重要な部分は次の場所にあります。ゾーン外デフォルトでは、組み込みのバイナリコードの生のフラグメントです。ライブLinuxメディアからシステムを起動した場合は、パーティションをマウントしてその中のファイルに正常にアクセスできるようになりました。
UEFIを使用すると、UEFIブートローダが完全にファイルとして含まれるため、この問題は発生しません。セキュアブートを使用しない場合、GRUB UEFIバージョンのコア部分は単一のファイル*.efi、通常はUEFIブートローダの標準的な場所である特別なESPパーティションに含まれ、grubx64.efi残りはモジュールにロードできます。必要に応じて生成されたファイルにあります。
MBRパーティションディスクがUEFIモードで起動される場合、ESPは通常特殊タイプIDが0xEFのFAT32パーティションです。 GPTパーティションディスクでは、ESPにはデフォルトですべてのGPTパーティションツールで知られている専用のUUIDタイプ識別子があります。
WindowsはGPTフォーマットのシステムディスクでのBIOSスタイルの起動プロセスの使用をサポートしていないため、システム製造元がこのシナリオをまったくテストしていない可能性があります。ただし、理論的には、通常の場所がGPTパーティションテーブル自体と競合するGRUB部分に適した新しい場所が提供されている場合は、正常に動作します。この新しい場所はBIOS ブートパーティション、私はOldfredが以下を言及していると信じています。BIOS_grubパーティションコメントに。
BIOSブートパーティションは1MiBを超える必要はありませんが、今度はそのパーティションを作成してGRUBを再インストールして、新しいGPTパーティションテーブルが置き換えるコンポーネントを含めるために使用できるようにする必要があります。
未分割の空き容量が1MiB以上ある場合、または既存のパーティションの1つをそれほど安全に縮小できる場合は、ライブLinuxブートメディアを使用してBIOSブートパーティションを作成し、それに応じてタイプを設定できます。他の場所に空き容量はありませんが、スワップパーティションがある場合は、現在のスワップパーティションを削除してより小さな1MiBパーティションを再作成することが、BIOSブートパーティション用の空き容量を確保する簡単な方法です。
次に、既存のルートパーティション（および必要に応じて他のパーティション）をマウントし、そのパーティションにchrootを適用し、現在のバージョンがgrub-installBIOSブートパーティションをサポートしていることを確認し、それを使用して現在GPTパーティションシステムディスクにGRUBを再インストールする必要があります。
しかし私は意見のoldfredの提供に同意します。他の問題がないことを確認するには、まず起動可能な起動回復ユーティリティ（他のコンピュータを使用することもできます）その後、コンピュータはそれを使用して現在の状況に関するレポートを生成し、ここへのリンクを投稿します。
私も尋ねたい：そもそもなぜこのような転換をするのでしょうか？？ BIOSスタイルのブートを使用していて、現在のシステムディスクサイズが2TiB未満の場合、GPTパーティションに変換することで得られる利点は非常に制限されます。より大きなシステムディスクに移行する場合は、新しいディスクを既存のディスクと交換し、変換に問題がある場合に再試行できるように、新しいディスクを使用して移行する方が安全です。