Hello,
debian live images have to solve two problems:
1. a single image that must work both when written to DVD and when written to USB drive
2. a single image that must boot both EFI and BIOS machines
The combination of this results in 4 different ways of booting which need to be combined into a single image:
1. BIOS booting from DVD requires a boot sector within the ISO filesystem, which is ignored when the image is written to USB drive
2. BIOS booting from USB requires an MBR partition table with a partition marked as active, where the first sector is loaded from and executed
3. EFI booting from DVD requires a file EFI\BOOT\BOOTx64.efi within the ISO filesystem, which is loaded and executed
4. EFI booting from USB requires a GPT partition table with a partition of type 'ef' and a FAT filesystem, which in turn needs to contain a file EFI\BOOT\BOOTx64.efi
So the resulting image has two problems:
- In order to achieve 2.) and 4.), we have two partition tables which violates the standard - GPT standard requires that a "protective MBR" is present, with a single partition enclosing the entire space, in order to prevent MBR-only tools from treating the drive as empty.
- In order to achieve 1.) and 3.), the EFI folder is included in the ISO filesystem in the first partition, and the same folder is "mapped" once again in a FAT filesystem within the second partition. If you take a closer look at the cfdisk output, you can see that the first partition starts at 0 and ends at 3793663, while the second starts at 2136 and ends at 2967. So the second partition actually resides within the first, exposing the same EFI folder that is contained in the first partition. In terms of standards, this is clearly invalid, but BIOSes ignore this and boot just fine using this method.
The latter is the reason why cfdisk chokes on this layout; it only looks at the end of the last partition, which is 2967 in this case, and calculates the start of the free space to be at the next cylinder/MiB boundary from there.
Sfdisk should be able to deal with this, it's the tool that works with most of the "strange" disk layouts including disordered partitions etc.
The latter problem could be avoided by creating the image differently, it is also possible to just append the EFI partition at the end of the first and copy the EFI folder there. This means the same data is included twice, and care needs to be taken that both are actually identical, but it prevents problems like yours. But there is no way to prevent having both MBR and GPT in the image, even though *most* EFI implementations also boot from MBR.
Hope I could clarify a bit,
Andreas
Am 24.06.2017 um 19:52 schrieb Markus Laire:
debian live images have to solve two problems:
1. a single image that must work both when written to DVD and when written to USB drive
2. a single image that must boot both EFI and BIOS machines
The combination of this results in 4 different ways of booting which need to be combined into a single image:
1. BIOS booting from DVD requires a boot sector within the ISO filesystem, which is ignored when the image is written to USB drive
2. BIOS booting from USB requires an MBR partition table with a partition marked as active, where the first sector is loaded from and executed
3. EFI booting from DVD requires a file EFI\BOOT\BOOTx64.efi within the ISO filesystem, which is loaded and executed
4. EFI booting from USB requires a GPT partition table with a partition of type 'ef' and a FAT filesystem, which in turn needs to contain a file EFI\BOOT\BOOTx64.efi
So the resulting image has two problems:
- In order to achieve 2.) and 4.), we have two partition tables which violates the standard - GPT standard requires that a "protective MBR" is present, with a single partition enclosing the entire space, in order to prevent MBR-only tools from treating the drive as empty.
- In order to achieve 1.) and 3.), the EFI folder is included in the ISO filesystem in the first partition, and the same folder is "mapped" once again in a FAT filesystem within the second partition. If you take a closer look at the cfdisk output, you can see that the first partition starts at 0 and ends at 3793663, while the second starts at 2136 and ends at 2967. So the second partition actually resides within the first, exposing the same EFI folder that is contained in the first partition. In terms of standards, this is clearly invalid, but BIOSes ignore this and boot just fine using this method.
The latter is the reason why cfdisk chokes on this layout; it only looks at the end of the last partition, which is 2967 in this case, and calculates the start of the free space to be at the next cylinder/MiB boundary from there.
Sfdisk should be able to deal with this, it's the tool that works with most of the "strange" disk layouts including disordered partitions etc.
The latter problem could be avoided by creating the image differently, it is also possible to just append the EFI partition at the end of the first and copy the EFI folder there. This means the same data is included twice, and care needs to be taken that both are actually identical, but it prevents problems like yours. But there is no way to prevent having both MBR and GPT in the image, even though *most* EFI implementations also boot from MBR.
Hope I could clarify a bit,
Andreas
Am 24.06.2017 um 19:52 schrieb Markus Laire:
Thanks, but it seems that cfdisk doesn't understand this partition structure properly either:
Device Boot Start End Sectors Size Id Type
/dev/sdd1 * 0 3793663 3793664 1.8G 0 Empty
/dev/sdd2 2136 2967 832 416K ef EFI (FAT-12/16/32)
>> Free space 4096 246480895 246476800 117.5G
If /dev/sdd1 is 3793664 sectors then there is no way that free space starts at sector 4096. And if I try to create new partition there, cfdisk doesn't allow that and gives error "Start sector 4096 out of range."
On Sat, Jun 24, 2017 at 7:44 PM, Tom & Karen Pino <metalsmith@rangeweb.net> wrote:--
You have a 'Hidden HPFF/NTFS' partition for your main partition.
Gparted is a fine partition tool for general work but don't use it for this sort of job.
Use cfdisk instead.
# cfdisk /dev/sdd
On 06/24/2017 09:08 AM, Markus Laire wrote:
I just put debian-live-9.0.1-amd64-xfce.iso to 128 GB USB-stick and then tried to check the created partitions on a computer running Debian Strech. When I check partitions with "cat /proc/partitions" I get: 8 48 123240448 sdd 8 49 1896832 sdd1 8 50 416 sdd2 So there is one main partition and one tiny one. But if I start GParted to modify partitions, it doesn't see main partition at all, only the tiny one. GParted claims that USB-stick has: - 1.04 MiB unallocated space - 416 KiB fat16 partition - 117.53 GiB unallocated space Why GParted doesn't see the main partition? I want to create another partition for persistence, but I'm afraid GParted will destroy main partition (which it doesn't see) if I try to do any changes. --Markus Laire https://www.MarkusLaire.com
