Let me start with the scenario that led me into issues with the Ubuntu Startup Disk Creator. I had been running Ubuntu GNOME, a flavor of Ubuntu that was focused on a mostly vanilla install of Gnome on top of Ubuntu. Well, Ubuntu was finally getting rid of the Unity desktop, so the spin off that I had been using was no longer going to be updated. Fair enough.
I had Ubuntu installed, and I wanted to give Fedora a try (it has been a while), so I just needed to create a bootable USB stick. Normally I would use dd, but Ubuntu has a tool, and I thought sure, let’s try this gui tool. Quick and easy. That led me down the rabbit hole that you see here.
Ubuntu has a page dedicated to the topic. Create a bootable USB stick on Ubuntu. This page walks through using the Startup Disk Creator. It does mention using an Ubuntu ISO image, but what should work for one, should work for most any ISO. At least this is what I thought. It turns out that if you are not using a Debian based distro, then the application will fail silently. It just sits there and does nothing.
At this point, I could have just used dd and been done with it, but I wanted to find out what was going on with the application, and why it was not working. Let me add a quick note and say, I had not tried a Debian based ISO on the application. This was because I wanted to try out the latest Fedora, and had not bothered to pull down another ISO.
Finding the source code for the USB Creator took a bit longer than planned. The code is hosted on LaunchPad which uses Bazaar as its version control system. Having used multiple systems over the years, launchpad felt like a step back in time. Unless I missed something, there is no easy search within a project, the navigation is antiquated, and the look and feels leaves a bit to be desired.
My first thought was to create a bug on the issue. Even if I was going to fix it, I wanted to ensure that the issue was being tracked, and to see if anyone else had submitted a bug on the topic already. I was surprised when I went to the bug page, and found that the package had not been configured for bug reports yet. At this point, I was more frustrated than anything else, and had decided I was going to use dd to create the usb disk, but I wanted find out what the problem in the code was.
Digging through the code, I found that the core of the application is a few python scripts. Nothing wrong there. I am a huge fan of python for a number of reasons. So, I dug into the code and found the issue rather quickly to my surprise.
From https://bazaar.launchpad.net/~usb-creator-hackers/usb-creator/trunk/view/head:/usbcreator/backends/base/backend.py
if extension == '.iso':
label = self._is_casper_cd(filename)
if label:
self.sources[filename] = {
'device' : filename,
'size' : os.path.getsize(filename),
'label' : label,
'type' : misc.SOURCE_ISO,
}
if misc.callable(self.source_added_cb):
self.source_added_cb(filename)
elif extension == '.img':
self.sources[filename] = {
'device' : filename,
'size' : os.path.getsize(filename),
'label' : '',
'type' : misc.SOURCE_IMG,
}
if misc.callable(self.source_added_cb):
self.source_added_cb(filename)
The issue is on line 42. The application checks to see if the iso file ‘is_casper_cd.’ This check returns `None` if it does not follow this format. A simple exception could have given the end user some sort of idea about what the issue was, but instead, it fails silently.
From https://bazaar.launchpad.net/~usb-creator-hackers/usb-creator/trunk/view/head:/usbcreator/backends/udisks/backend.py
# Device manipulation functions.
def _is_casper_cd(self, filename):
for search in ['/.disk/info', '/.disk/mini-info']:
cmd = ['isoinfo', '-J', '-i', filename, '-x', search]
try:
output = misc.popen(cmd, stderr=None)
if output:
return output
except misc.USBCreatorProcessException:
# TODO evand 2009-07-26: Error dialog.
logging.error('Could not extract .disk/info.')
return None
The fact that this code fails silently, the code base does not provide for bug features, and that there is no documentation on this bug/feature is problematic. A simple review of this should have caught the problem. Also, as you can see in the previous section, they do log an error when the data can not be extracted, but they do nothing if the file format does not exist.
At a minimum they could have thrown an error. Another option would have been to continue with the disk write, but to skip the label information. Otherwise, give the end user a clue.
In the end I just used good old fashioned `dd`.
user@host$ sudo dd bs=4M if=/path/to/archlinux.iso of=/dev/sdx status=progress oflag=sync