Ubuntu ISO MBRでは、GPTパーティションがブートパーティションと重複し、MBRを編集できないのはなぜですか？

Question

質問とコンテキスト：

たとえばubuntu-16.04-desktop-AMD64.isoのようなディストリビューションのMBRパーティションテーブルで、GPTパーティションがプライマリブートパーティションとオーバーラップしているように見えるのはなぜですか？何らかの方法でパーティションテーブルを編集しようとすると、エラーが発生するようです。

MBRを編集してUSB永続性を追加したい（他の場所で説明）ため、パーティションを追加するか、ブートパーティションを拡大する必要があります。

これは以前は機能していたと思いますが、このディストリビューションと同様のディストリビューションで重複したGPT＃2パーティションは、fdisk、sfdisk、parted、gparted、partprobeをひどく混同しているようです。

私のマシンはMBRであり、GPT biosではありません。

私は何が欠けていますか？

ここにディストリビューションのMBRパーティションテーブルがあります（ISOファイルから直接）：

cat ubuntu-16.04-desktop-AMD64.iso | xxd | head -32 | tail -5

与える：

00001b0: 28db 2b00 0000 0000 708e 0e0e 0000 8000 (.+.....p....... 00001c0: 0100 0058 e0fa 0000 0000 6048 2c00 00fe ...X......`H,... 00001d0: ffff effe ffff 4411 2c00 8012 0000 0000 ......D.,....... 00001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 00001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U.

（これをデコードするには https://en.wikipedia.org/wiki/Master_boot_record を参照してください。）

テーブルは、＃1プライマリブートパーティションのアドレス01beから始まり、「80」が表示されます。
次に、＃1プライマリパーティションがtype = GPTであることを示すアドレス01d2の「ef」に注目してください。

これは、パーティション（リトルエンディアン）によるテーブルの内訳です：

partition#1 (normal MBR): 80 = 'boot' partition flag 00 01 00 = starting HSC (head, sector, cylindar) 00 = partition type ("Empty partition entry") 58 e0 fa = last HSC (head, sector, cylindar) 0000 0000 = LBA (logical block address) of first absolute sector in the 6048 2c00 = number of sectors in partition partition #2 (GPT): 00 = non-boot partition fe ff ff = starting HSC (head, sector, cylindar) ef = partition type ("EFI system partition") fe ff ff = last HSC 4411 2c00 = LBA (logical block adr) of first abs sector in part. 8012 0000 = number of sectors in partition

パーティションテーブルの編集を試みます：

fdiskは、これらのパーティションが重複していることを報告します。 sdb2 [2927216]の始まりがsdb1 [0-2955679]の内側にあることに注意してください

Sudo fdisk -l /dev/sdb

与える：

 Disk /dev/sdb: 14.5 GiB, 15527313408 bytes, 30326784 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x40a863e7 Device Boot Start End Sectors Size Id Type /dev/sdb1 * 0 2955679 2955680 1.4G 0 Empty /dev/sdb2 2927216 2931951 4736 2.3M ef EFI (FAT-12/16/32)

私が読んだことから、GPTパーティションを持つことは問題ありませんが、パーティションが重複することはありません。
Isoをusbスティックにddしようとすると、トラブルが始まります。スティックはUbuntuをライブで起動しますが、どのパーティションエディタを試しても、エラーなしで（つまり、起動されず、マウントされていない間）パーティションテーブルを編集できません。
さらに、次の時間のかかる手順を行わないと、パーティションテーブルを削除してUSBスティックを通常の状態に戻すことさえできません。
```
dd if=/dev/zero of=/dev/sdb bs=[something like 512 or 2048; doesn't matter] count=[some large number like 100000^] 
```
^小さい数字は常にこれを修正するとは限りません。プライマリfsブロックだけでなく、セカンダリfsブロックも消去する必要があると思います。

fdiskを使用して、スティック上に新しいms-dosパーティションテーブルを作成します。

新しいパーティションテーブルを作成する前にワイプするために上記のddを実行しないと、パーティションマップ（debian8またはubuntu-16のいずれか）を編集しようとすると、次のエラーメッセージなどが表示されます。
```
Libparted Warning The driver descriptor says the physical block size is 2048 bytes, but Linux says it is 512 bytes. 
```

また、ubuntu-12から、この最も啓発的なメッセージを受け取ります：

gparted -l /dev/sdb: libparted : 2.3 Could not stat device -l -- No such file or directory. /dev/sdb contains GPT signatures, indicating that it has a GPT table. However, it does not have a valid fake msdos partition table, as it should. Perhaps it was corrupted -- possibly by a program that doesn't understand GPT partition tables. Or perhaps you deleted the GPT table, and are now using an msdos partition table. Is this a GPT partition table? Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted's rescue feature to recover partitions.

では、ディストリビューションのMBRをどのように編集しますか？

ところで、私はこれが実際にディストリビューションである方法であり、その外観から、しばらくの間、オーバーラップを修正する方法を尋ねていません（Ub-v16、14、および12も見ました）、むしろ、可能であれば編集する方法を探しています。

アイデア：

これは、isohybridのアプリケーションが多すぎるために発生する可能性があります（ms-dos MBRをCDROM 9660 isoに追加してUSBで起動できるようにするため）。
使用する可能性のある他の、おそらく新しいパーティションテーブルエディタはありますか？
この問題を持たない、おそらく古い古いUbuntuディストリビューションはありますか？

Elliptical view · Accepted Answer

回避策

USBメーカーツールを使用して作成するのではなく、USBスティックのパーティションサイズを調整することができますcanスティック、代わりに端末コマンドのみを使用してUSBスティックをゼロから作成します。システムがBIOSを使用している場合に機能する詳細な手順は次のとおりです。

端末のみを使用してBIOSの永続性を備えたライブUbuntu USBドライブを作成する方法

USBスティックを使用したバックアップの使用上のヒント：バックアップに使用する2つの同一のUSBバックアップOSスティックを保持しますメインのDebianデュアルブートW10システム。バックアップを行っているときにシステムが実行されないようにします。 USBスティックが磨耗することもあるので、2つの同一のスティックも必要です。これにより、残りの良いスティックから新しいスティックにddコピーするだけで簡単に新しいものを作成できます。

システムを非常に壊れたため、修正できなかったとき、彼らは何度も助けてくれました！また、上記のリンクに含まれる増分バックアップおよび復元手順も非常に高速です。ただし、システムの欠陥が書き込まれ、破損するため、現在の増分が必要なときに機能しない可能性があるため、時々完全バックアップを実行する必要があります。私は今、毎週完全バックアップをしようとしています。

Rod Smith · Answer

Ubuntuの.isoイメージファイルは、複数のブート方法とデバイスをサポートするように設計されたFrankensteinのMonster形式を使用します。

ブートメディア
- ISO-9660およびEl Toritoを使用してブートするためにイメージをDVDに書き込む
- 従来のディスクパーティションシステムを使用して起動するために、USBフラッシュドライブまたは同様のメディアに「生」のイメージをコピーする
起動モード
- BIOSモードの起動
- EFIモードブート

開発者は、非常に多くの形式と起動方法を使用するために、データ構造を使用してゲームをプレイします。これらの画像は実際には「通常の」ディスク画像のように扱われるべきではありません。特に、NOTではなく画像を変更することを最も強調するべきです。これらのデータ構造のトップレベルの専門家でない限り、何らかの方法で。 FWIW、GPT fdisk（gdisk、cgdisk、およびsgdisk）パーティショニングツールを作成しました。Iはあなたが言うことを試みませんしようとしています！

代わりに、インストールメディアを変更する必要がある場合は、次の2つのいずれかを実行する必要があります。

これらの2つのアプローチのうち、最初のアプローチはおそらくあなたが望むものに適しています。実際、この種のツールには、必要な処理を正確に行うためのオプションが用意されていると確信しています。（ただし、どのツールがそのような機能を提供しているかは思い出せません。）2番目のアプローチは、カスタムインストールイメージにパッケージを追加するようなタスクに役立つ可能性が高くなります。

以前にこの種のことを行うことができた場合、開発者は特定のシステムの問題を回避するためにデータ構造のより恐ろしいハックを作成する必要性を発見したので、チャンスが変わります。たとえば、ブランドXのコンピューターがフランケンシュタインのモンスターパーティションテーブルを解析できない場合、開発者はそれを調整して、ブランドXコンピューターで動作するようにします。これは、データ構造が以前よりもさらに奇妙であることを意味します。ただし、これは私の側の憶測に過ぎず、あなたが説明した詳細については確かに話すことができません。