I've been examining the Ubuntu 20.04 and Fedora 32 live images, and saw that the first (ISO 9660) partition is set to cover the entire image (at least on the MBR's partition table, didn't check GPT yet). For Ubuntu this is around 2.7 GB; for Fedora it's 1.3 GB. However, after copying these ISOs to a USB stick using dd, gparted shows that the ISO 9660 partition covers the entire 32 GB stick.

Is this a gparted bug? The partition layout is a bit complicated, since the ISO 9660 partition is set to start at LBA 0, effectively covering even the MBR itself. I'm still not sure why this partition must cover the entire image though; I guess it's because when burning it to a DVD, the only filesystem you can have is ISO 9660.

  • You really should check the GPT information. If you have a GPT formatted disk then there will most likely be a "Protective MBR" with just one partition for the entire disk / image. This prevents programs which don't understand GPT from thinking the disk is empty. Jul 27, 2020 at 9:44
  • A proper protective MBR has a single partition in the MBR table with type 0xEE. This doesn't happen for either of the ISOs.
    – Martin
    Jul 27, 2020 at 13:57
  • Yes that's because this is a hybrid MBR and GPT. It's designed to boot on both legacy systems that can't read GPT and newer systems that require a valid GPT EFI partition. Jul 27, 2020 at 14:06
  • The GPT table contains only one partition (EFI) with a partition set to align with a file in the MBR ISO 9660 partition. See isohybrid. By the way, ISO 9660 has a space at the start reserved for "system". So even if it starts at sector 0 it won't overwrite the MBR. Jul 27, 2020 at 14:08
  • @PhilipCouling yes, I know that. However, GPT also contains 2 partitions (3 in the case of Fedora). The first one is the ISO 9660 which is set to cover the entire disk.
    – Martin
    Jul 27, 2020 at 15:31

1 Answer 1


We can say that it is a bug in gparted (and a corresponding bug in parted). These tools 'do not understand' the partition structure of iso files when cloned to USB pendrives (and other mass storage devices).

  • You can look at the drive with modern versions of fdisk and lsblk and get better results.
  • You can create a partition 'behind' the head of the drive and the image of the iso file. This partition can be used to store data, and even to serve as a partition for persistence in a persistent live system for example with Ubuntu 20.04 LTS and Debian 10 live. You can do it yourself with fdiskand mkfs, or easier with mkusb-plug. The mkusb-plug tools may not work in/with Fedora.

Example where lsblk and fdisk see a cloned live USB drive with Lubuntu:

$ lsblk -o model,name,size,fstype,label,mountpoint /dev/sdc
MODEL            NAME    SIZE FSTYPE  LABEL                     MOUNTPOINT
Voyager GT 3.0   sdc    29,5G iso9660 Lubuntu 20.04.1 LTS amd64 
                 ├─sdc1  1,7G iso9660 Lubuntu 20.04.1 LTS amd64 /media/sudodus/Lubuntu 20.04.1 LTS amd64
                 └─sdc2  3,9M vfat    Lubuntu 20.04.1 LTS amd64 

$ LANG=C sudo fdisk -lu /dev/sdc
Disk /dev/sdc: 29,5 GiB, 31641829376 bytes, 61800448 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: 0x2d846e8c

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdc1  *          0 3576319 3576320  1,7G  0 Empty
/dev/sdc2       3541360 3549295    7936  3,9M ef EFI (FAT-12/16/32)
  • Thanks for the response. I'm curious about "You can create a partition 'behind' the head of the drive and the image of the iso file", since that's exactly my goal here. gdisk won't allow me to do this on an existing USB stick, as it also seems to believe that the ISO 9660 covers the entire disk, and it only allows the last sector to be specified as both first and last LBA. mkusb-dus seems to work for this, though I haven't tested the resulting USB stick.
    – Martin
    Jul 27, 2020 at 14:02
  • fdisk can create a partition 'behind' the head of the drive and the image of the iso file, either manually or automatically. Cloned USB drives with Ubuntu 20.04 LTS will create such a partition automatically when booted the first time. Cloned USB drives with Debian 10 will not create it, but you can do it with fdisk or let mkusb-plug do it (using fdisk under the hood). mkusb-dus goes another way, does not clone, but makes partition #3 into a boot partition and copies the content of the iso file parttion #4. This method is inspired by the grub-n-iso method alias isoboot method.
    – sudodus
    Jul 27, 2020 at 19:19
  • @Martin, The following link to a thread at the Ubuntu Forums can help explain how to do it with fdisk on a cloned drive or semi-cloned drive. By semi-cloned I mean that it is treated with sed in order to replace the not so important boot options 'quiet splash' with 'persistent ': Cloned USB drive with Lubuntu Eoan and Focal can be made persistent live
    – sudodus
    Jul 27, 2020 at 19:27
  • When I wrote "mkusb-dus goes another way, does not clone" I meant "when creating a persistent live drive, mkusb-dus goes another way, does not clone the iso file". - But the standard method of mkusb is cloning, pure cloning and nothing else. Cloning is the best method for the two most common cases: To create a USB live (live-only) drive to test the linux distro and to install it into an internal drive.
    – sudodus
    Jul 27, 2020 at 19:52
  • 1
    Here's how to install mkusb, so you to install the ISO to a live USB while allowing storage space on the USB still: Calvin Bui: Create a persistent Ubuntu USB which boots to RAM. Dec 25, 2023 at 2:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .