gparted does not recognize the iso9660 file system in cloned Ubuntu USB boot drives

This illustrates that lsblk can see the iso9660 file system:

lubuntu@lubuntu:~$ sudo lsblk -f /dev/sda
NAME FSTYPE LABEL UUID MOUNTPOINT
sda iso9660 Lubuntu 16.04.1 LTS i386 2016-09-09-18-15-41-00 /cdrom
└─sda1 iso9660 Lubuntu 16.04.1 LTS i386 2016-09-09-18-15-41-00
lubuntu@lubuntu:~$ sudo lsblk -m /dev/sda
NAME SIZE OWNER GROUP MODE
sda 3.7G root disk brw-rw----
└─sda1 859M root disk brw-rw----
lubuntu@lubuntu:~$

Status changed to 'Confirmed' because the bug affects multiple users.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1622313

The attached screenshot illustrates the worse problem in some older versions. It seems to work better in the i386 version of 14.04.1 (like in 16.04.1) but this screenshot was made in a live system booted from

ubuntu-14.04.1-desktop-amd64.iso

Having found this problem with the Trusty amd64 version, I tried the Xenial amd64 version too, and it is affected in a minor way. It shows the file system, but it gets the sector size wrong and hence the aize of the drive. My 32 GB seems to contain 119 GiB (128 GiB is reported by parted, and it thinks it is a mac file system). The the screenshots in this and the following comment.

Screenshot #2 for Xenial amd64 ...

Please, consider subscribing to the upstream bug report at (https://bugzilla.gnome.org/show_bug.cgi?id=771244).

It affects me, too.

And here are some details from me...

I am running Ubuntu 16.04.1 LTS, 64-bit.

For some time I have been using Startup Disc Creator to create Lubuntu 32-bit install media (on USB flash drives).

However, today (8th September 2016), when I was attempting to create a Lubuntu 16.04.1 LTS desktop 32-bit install USB flash drive using Startup Disc Creator (0.3.2), it would write the iso to the flash drive OK. Except for one thing. The flash drive is not being recognised. To quote GPartEd, "Unable to detect file system!".

Bit more: Whilst the resulting install media can install Lubuntu OK, you just can't look at it with a File Manager or GPartEd.

No, gparted does not work in this case (but in most other cases gparted is a good tool).

But you can mount the partition with the iso9660 file system manually, and after that you can look at it with a file manager, or as illustrated below, with command line tools. For example, I can read the file README.diskdefines in the iso9660 file system. Try it :-)

-----
sudodus@xenial32 ~ $ sudo lsblk -f /dev/sdd
[sudo] password for sudodus:
NAME FSTYPE LABEL UUID MOUNTPOINT
sdd iso9660 Lubuntu 16.04.1 LTS i386 2016-09-09-18-15-41-00
└─sdd1 iso9660 Lubuntu 16.04.1 LTS i386 2016-09-09-18-15-41-00
sudodus@xenial32 ~ $ sudo lsblk -m /dev/sdd
NAME SIZE OWNER GROUP MODE
sdd 3,7G root disk brw-rw----
└─sdd1 859M root disk brw-rw----
sudodus@xenial32 ~ $ sudo mount /dev/sdd1 /mnt
mount: /dev/sdd1 is write-protected, mounting read-only
sudodus@xenial32 ~ $ ls -l /mnt
totalt 36
dr-xr-xr-x 1 root root 2048 sep 9 20:15 boot
dr-xr-xr-x 1 root root 2048 sep 9 20:15 casper
dr-xr-xr-x 1 root root 2048 sep 9 20:15 dists
dr-xr-xr-x 1 root root 2048 sep 9 20:15 install
dr-xr-xr-x 1 root root 18432 sep 9 20:15 isolinux
-r--r--r-- 1 root root 3114 sep 9 20:15 md5sum.txt
dr-xr-xr-x 1 root root 2048 sep 9 20:15 pics
dr-xr-xr-x 1 root root 2048 sep 9 20:15 pool
dr-xr-xr-x 1 root root 2048 sep 9 20:15 preseed
-r--r--r-- 1 root root 227 sep 9 20:15 README.diskdefines
lr-xr-xr-x 1 root root 1 sep 9 20:15 ubuntu -> .
sudodus@xenial32 ~ $ cat /mnt/README.diskdefines
#define DISKNAME Lubuntu 16.04.1 LTS "Xenial Xerus" - Beta i386
#define TYPE binary
#define TYPEbinary 1
#define ARCH i386
#define ARCHi386 1
#define DISKNUM 1
#define DISKNUM1 1
#define TOTALNUM 0
#define TOTALNUM0 1
sudodus@xenial32 ~ $
-----

I can confirm this also happens in Xubuntu 16.04 (all updates 3rd Oct. 2016)

Awesome that it looks like this will be fixed. It's freaky seeing seriousy warning whenever you open Gparted off a live USB that's (after dd'ing an ISO to it.) I trial a lot of distro's and I've always worried about my fixed partitions. It actually displays a error after every change or reload of Gparted if a IS0-9660 file system is present, even if it's not being used. (Will upload screen-shot.)

What I hope is that after this issue is resolved, it will be possible to use partitioneditor and make additional partitions on the stick - otherwise all the extra space is wasted. It's not easy to find USB3 sticks less than 16gb these days.

@alan-ezust,

It is important that gparted can read the typical file systems of [hybrid] iso files *cloned* to USB drives and memory card. One reason is that otherwise people will think that the file system is damaged, when it is actually exactly what it is supposed to be. The *Ubuntu Startup Disk Creator* (alias usb-creator-gtk) in 16.04 LTS and newer versions is a cloning tool. *Disks* (alias gnome-disks) and *mkusb* (when making live-only boot drives are also cloning tools.

But it will not be possible to edit the partition table and create a new partition after the partition(s) with iso 9660, because this whole partition table is read-only by its nature. It was designed for optical media (CD and DVD disks).

So if you wish to use the extra space, you can should use a tool that *extracts* the content of the iso file to an already created file system. One alternative is a *persistent live drive with mkusb*, which uses a partition with the label 'casper-rw' and an ext file system for persistence and another partition with the label 'usbdata' and an NTFS file system for general storage and communication with computers running Windows.

*Unetbootin* and *Rufus* are extracting tools also when creating live-only USB boot drives.

Finally, mkusb can *restore* a cloned USB boot drive to a standard storage drive with an MSDOS partition table and a partition with a FAT32 file system. There has been problems (bugs) in Disks, but now I think it can also restore a cloned USB boot drive to a standard storage drive.

This bug was fixed in the package gparted - 0.28.1-0ubuntu1

---------------
gparted (0.28.1-0ubuntu1) artful; urgency=medium

  * New upstream release (LP: #1708184) (Closes: #857015)
    - Recognize the iso9660 filesystem (LP: #1622313)
  * Update debian/watch to watch for .gz or .xz tarballs too
  * Drop obsolete dirs, menu and .xpm
  * Drop gparted.postinst which fixed a mistake from Debian Lenny
  * Switch to simple dh7 style rules
  * Enable all hardening flags
  * Bump debhelper compat to 10
  * Update 02_use-pkexec.patch:
    - Refresh and let autoreconf update generated files

 -- Jeremy Bicha <email address hidden> Wed, 02 Aug 2017 14:47:22 -0400

Yay :-)