Unable to create working Ubuntu Server 14.04 LTS media

[num-lock]

A while ago I switched from UUI (Universal USB Installer) to Rufus, because the ISOs provided by arch-linux require syslinux6 to work properly. (UUI still uses syslinux4 IIRC) It wouldn't even boot with UUI. Now I have a weird experience: Using Rufus I am not able to create a working USB media (using ubuntu-14.04.3-server-amd64.iso). It boots just fine and I get to select my locales and everything. But as soon as I am supposed to create the disk partitions, the installer fails, telling me there was a problem loading data from the CD-ROM. Switching back to UUI I am able to create a working media just fine. Might this be a problem with Rufus or the ISO itself and UUI just does some quirks to get it working?

[pbatard]

I'm not seeing issues with ubuntu-14.04-server-amd64.iso (which is the ISO I have - I may try to download 14.04.3). I tried booting in both MBR and UEFI mode and was able to get to the partition tool just fine. The only issue I encountered was that Ubuntu seemed to be unhappy about the floppy drive I had on one of the machines I tested and I had to disable it in the BIOS.

Was your error happening after you selected how you wanted to partition your drive and were trying to commit these changes?

[num-lock]

It happens right after selecting the locales and keyboard layout. Then the installer straight goes to the error, trying to load the partitioning dialog/tool I guess. It's not even getting as far as asking me about how or what to partition. I researched a bit and apparently it's related to filenames. There is a question on askubuntu.SE with pretty much the exact same error I am getting: link to the question (However, I did not check the integrity test yet, which is mentioned there)

No clue why the same ISO works with UUI but not Rufus. If I have some spare time I'll create a media with UUI and Rufus and generate a diff over the filenames or something ... if that helps.

[pbatard]

If I have some spare time I'll create a media with UUI and Rufus and generate a diff over the filenames or something ... if that helps

That would help. You may also want to double check the MD5 of your ISO just in case (which you can do using Rufus 2.3 after selecting the ISO, by clicking on the # button at the bottom). Also, have you tried more recent versions than 14.04?

[num-lock]

I've only tried the ubuntu-14.04.3-server-amd64.iso. I can say as much as that the MD5 is correct. I always (have to) check that after ISO downloads. I'll post the diff somewhat around Monday. Unfortunately I won't get to do that earlier.

[num-lock]

Ok, I got to compare both versions. I took the same ubuntu-14.04.3-server-amd64.iso and the same USB media both times and let UUI and Rufus format it on creation. Skipping the obvious parts (UUI license files, syslinux etc.) the files at /pool/main/l/linux-lts-vivid/ are named different.

UUI puts this on the media:

block-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.ude
crypto-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd6.ude
firewire-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.ude
floppy-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd6.ude
fs-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd.ude
... etc

Rufus puts this on the media:

block-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb
crypto-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb
firewire-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb
floppy-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb
fs-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb
... etc

And now, this is what is actually on the ISO:

block-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.ude
crypto-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd6.ude
firewire-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.ude
floppy-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd6.ude
fs-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd.ude
... etc

... which matches with what UUI does.

Files like ...

fat-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb
fb-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb
... etc

... are the same on both and match with the ISO

Also, this file is different: UUI: /pool/main/m/maas/python-maas-provisioningserver_1.7.6+bzr3376-0ubuntu2~14.04.1.deb Rufus: /pool/main/m/maas/python-maas-provisioningserver_1.7.6+bzr3376-0ubuntu2~14.04.1_all.deb ISO: /pool/main/m/maas/python-maas-provisioningserver_1.7.6+bzr3376-0ubuntu2~14.04.1.deb

[pbatard]

Try Alt-K.

Or, to elaborate a bit more: First of all, thanks a lot for performing that comparison. With the above, I have a pretty good idea what's going on here. I have also downloaded the ubuntu-14.04.3-server-amd64.iso as the 14.04 I already had didn't have any of these files.

The issue here is that this ISO uses Rock Ridge extensions, which is mostly used to overcome some of the limitations of ISO9660 when it comes to file names.

With Rock Ridge enabled, you can basically tell whatever or whoever parses an ISO something like "I know this file is labelled firewire-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.ude as per ISO-9660, but I really would like to see it named firewire-core-modules-3.19.0-25-generic-di_3.19.0-25.26~14.04.1_amd64.udeb".

Now, because there's no way of knowing for sure if the underlying application accessing the copied ISO content during boot wants plain ISO-9660 naming (with its limitation) or Rock Ridge, but the logical expectation is that, if someone went the trouble of adding Rock Ridge, most likely, they plan to use it, then by default, Rufus extracts ISO content using Rock Ridge extensions when they are present and therefore use the longer names as pointed above. Oh, and it will also tell you about it in the log:

Extracting files...
Image is an ISO9660 image
This image will be extracted using Rock Ridge extensions (if present)

Then again, since I reckon it is possible that some weird distro maintainers might decide to add Rock Ridge, but NOT use it with their installers, I left a way to disable the use of Rock Ridge extensions in Rufus altogether by using the Alt-K cheat mode.

If you try that, I'm pretty sure that you will find that the ISO works as expected. Can you please give it a try?

Unfortunately, short of maintaining a database of all the ISOs that have an install process that actually makes use of Rock Ridge, and the ones that don't, it's next to impossible to figure out whether Rufus should enable or disable Rock Ridge on the USB creation. IIRC, there are some distros out there (Slackware I believe) for which disabling Rock Ridge will result in problems, and as I pointed out above, the logical thing to assume is that if a Linux distro uses Rock Ridge on their archive files, they do plan to use it during their installation process.

If you want to push it further, maybe you should log a bug with Ubuntu asking them not to apply Rock Ridge extensions if they don't really plan to use them...

[num-lock]

I now created the media with disabled Rock Ridge using Alt-K. The diff now only lists the license, syslinux and other unrelated files. The full diff is now this:

Rufus exclusive files:

/ldlinux.sys
/syslinux.cfg
/autorun.inf
/autorun.ico

UUI exclusive files:

/uui
/uui/ldlinux.sys
/uui/syslinux.cfg
/Uni-USB-Installer-Copying.txt
/Uni-USB-Installer-Readme.txt
/license.txt

Great! However, I still get the same error ... I will double check just in case and might as well run MD5 over all files while I am at it.

[num-lock]

Ok, I just double checked and it did not work. I generated the MD5 sums for all (non exclusive) files and this is the diff:

boot/grub/grub.cfg
isolinux/chain.c32
isolinux/vesamenu.c32
isolinux/isolinux.cfg
isolinux/txt.cfg

It boots fine and everything, but at some point tells me that the installation media could not be mounted. I can't even run the built-in integrity check because of that.

[pbatard]

Huh?

There's nothing in the Rufus code to modify the content of any of these files, and I just double checked that I couldn't see any difference between the USB and the ISO version when I created an UFD with ubuntu-14.04.3-server-amd64.iso (MD5: 9e5fecc94b3925bededed0fdca1bd417) using Rufus 2.3.

Unless the report above is for files that UUI modifies (and that Rufus doesn't), you will have to double check that your UFD is not defective.

If these are the files that UUI modifies, then it would be interesting to see the differences for the text files. But I have to tell you that I'm not planning to add a custom exception in Rufus for ubuntu-14.04.3-server-amd64.iso, as UUI seems to do, in order to modify the configuration files, as this is what the prompt about trying to write in DD-image mode instead of ISO-image mode of Rufus 2.3 is all about, if you find that ISO-image mode encounters issues after boot. It's up to distros maintainers, rather than developers of bootable apps, to ensure that their ISOs can be booted when copied to USB in file copy mode. Not the opposite.

[num-lock]

The MD5 diff was between UUI media and Rufus media, not the ISO.

I'm not planning to add a custom exception

Well, I wouldn't either. Simply using dd on the ISO works, though. But at this point I just blame the ISO anyways. If i find some spare time I'll actually try to investigate this further by myself. At the beginning of all this I thought it was just something obvious for you. I already had something like ISO9660levelsjolietwhatever in mind, but you never know. Rufus works with everything else for me just like it should and I expect. I switched from UUI for a reason.

I'll try to grasp what is going on with those files at least by next week.

[pbatard]

I'll try to grasp what is going on with those files at least by next week.

Thanks.

I may still try to have a look at how UUI alters those files myself if I can. Maybe there's something simple that can be achieved there. While I don't like having to modify the boot config files in Rufus, I do have some provision for this regarding ISOs like Fedora (#547) that rely on the disc label to find the installation files (which needs to be changed when an ISO is converted to FAT32, as a FAT32 label must be uppercase and no longer than 11 chars).

[pbatard]

I had a look at what UUI does, and it seems it uses a list of quirks to apply to specific images. For instance, for the ubuntu-14.04-server-amd64.iso, it changes the kernel and initrd listed in the grub.cfg/isolinux.cfg files from:

kernel = /install/vmlinuz
initrd = /install/initrd.gz

to

kernel = /install/netboot/ubuntu-installer/amd64/linux
initrd = /install/netboot/ubuntu-installer/amd64/initrd.gz

Oh, and is also removes the ui gfxboot bootlogo line in isolinux.cfg.

Unfortunately, the approach I have taken for Rufus is NOT to have to maintain a list of quirks that need to be applied to specific images, because this rapidly becomes unmaintainable and I also expect Linux distro maintainers to know better. So, if an image is not generic enough to be bootable from USB, like Ubuntu 14.04 Server, then it just won't be compatible with Rufus.

I would encourage you to try the 15.04 version - maybe the Ubuntu people have realized that their default kernel was just too restrictive and fixed this compatibility issue...

I will close this issue now.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.