[Bug 1622313] Re: gparted does not recognize the iso9660 file system in cloned Ubuntu USB boot drives

sudodus 1622313 at bugs.launchpad.net
Wed Feb 8 14:08:41 UTC 2017


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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gparted in Ubuntu.
https://bugs.launchpad.net/bugs/1622313

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

Status in GParted:
  Confirmed
Status in gparted package in Ubuntu:
  Triaged

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gparted/+bug/1622313/+subscriptions



More information about the foundations-bugs mailing list