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

Bug #1622313 reported by sudodus on 2016-09-11
32
This bug affects 7 people
Affects Status Importance Assigned to Milestone
GParted
Fix Released
High
gparted (Ubuntu)
High
Unassigned
Nominated for Xenial by Alberto Salvia Novella

Bug Description

I am testing in a live system and looking at the very drive, from which it is booted, the current daily iso file of Lubuntu Xenial i386 (post 16.04.1 LTS). The problem is that the file system cannot be identified, and several end users may (and will) think that the USB boot drive is damaged. But it works, it is cloned, which is the straightforward method to create a boot drive from a hybrid iso file.

this issue was worse in previous versions, where gparted would complain about an error; now it is at least seeing the partition. The next step is that it can see the file system too.

lsblk can see it, as illustrated by the following command line (in a wide terminal window),

sudo lsblk -fm

The attached screenshot illustrates the problem, and shows that it affects the text mode program parted too.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: gparted 0.25.0-1
ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
Uname: Linux 4.4.0-38-generic i686
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: i386
CasperVersion: 1.376
CurrentDesktop: LXDE
Date: Sun Sep 11 10:10:21 2016
LiveMediaBuild: Lubuntu 16.04.1 LTS "Xenial Xerus" - Beta i386 (20160909)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: gparted
UpgradeStatus: No upgrade log present (probably fresh install)

Edit:

After some testing I found that the current i386 versions behave in a similar way as Xenial.

But the current amd64 (64-bit) versions are more severely affected by this bug. It is much worse in Trusty, but also bad in Xenial as illustrated by screenshots in comments #6 and #7. This behaviour will really confuse new users of Ubuntu and the Ubuntu flavours.

sudodus (nio-wiklund) wrote :
sudodus (nio-wiklund) wrote :

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:~$

Launchpad Janitor (janitor) wrote :

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

Changed in gparted (Ubuntu):
status: New → Confirmed
Ubuntu QA Website (ubuntuqa) wrote :

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

tags: added: iso-testing
sudodus (nio-wiklund) wrote :

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

sudodus (nio-wiklund) wrote :

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.

sudodus (nio-wiklund) wrote :

Screenshot #2 for Xenial amd64 ...

sudodus (nio-wiklund) on 2016-09-11
description: updated

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

Changed in gparted (Ubuntu):
importance: Undecided → High
Changed in gparted (Ubuntu):
status: Confirmed → Triaged
Ian Bruntlett (ian-bruntlett) wrote :

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.

sudodus (nio-wiklund) wrote :

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 ~ $
-----

Changed in gparted:
importance: Unknown → High
status: Unknown → Confirmed
Andrew Allen (andrew.nz) wrote :

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

Andrew Allen (andrew.nz) wrote :

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.)

alan ezust (alan-ezust) wrote :

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.

sudodus (nio-wiklund) wrote :

@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.

Changed in gparted:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.