Workaround needed to boot from USB stick - "gfxboot.c32: not a COM32R image"

...I ran the 32-bit (i386) ISO.

:)

Issue no longer evident in Lubuntu 18.04 32bit beta 2, at least in live-usb mode.

Thanks,
Ken.
***

This bug has reappeared as of Lubuntu 18.04 i386 20180421.1 daily build.

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/1747329

> Created USB boot stick.

This glosses over what steps you're taking here, and is the actual source of the bug.

The images that we produce are bootable images which, if copied directly to a USB stick, do not have this error.

But you are using some other tool to write the image to a USB stick, and in the process this other tool is modifying the image. It is injecting its own bootloader blocks into the disk which are incompatible with the versions that are shipped in Ubuntu 18.04.

If you are using usb-creator, than this is a duplicate of LP: #1325801 in the usb-creator package. The workaround is to not use usb-creator to write your images to the USB stick. You should use 'dd' instead, which is reliable and whose only limitation is that it doesn't set up persistent storage for your live session.

In any case this is definitely not a bug in grub, because you're not using grub when booting this image on a BIOS system; you're using isolinux which is a different bootloader.

Extracting tools can be affected by this "gfxboot.c32: not a COM32R image" bug. It is a problem of the tool to create the USB boot drive, and should be fixed by the developer of that particular tool.

-o-

Cloning tools are not affected by this bug. You can use Ubuntu's Startup Disk Creator alias usb-creator-gtk in Ubuntu 16.04 LTS and newer versions, or Disks alias gnome-disks, which both are GUI tools with a final checkpoint and they are packaged with Lubuntu. You can also use mkusb, which can be installed from a PPA. mkusb can clone, but also extract and create a persistent live drive.

As mentioned by Steve Langasek, you can also use dd, but it is risky, because it does what you tell it to do without questions and many people have overwritten valuable data after a minor typing error or some other (minor?) mistake.

I've yet to re-test this with the Lubuntu daily build, but creating a startup boot stick with Disks as described above resolved the same issue I was having with a Xubuntu daily build.

So, USB Startup Disk Creator seems to have been at the core of the issue.

Thanks,
Ken.
***

@Ken T (professorsnapper),

Which version of *ubuntu are you running, when you create your USB boot drives? Is it a version before 16.04 LTS? In that case I think there is an old and buggy version of the Startup Disk Creator, that you should avoid :-)

A new robust *cloning* version of the Startup Disk Creator was bundled with Ubuntu 16.04 LTS.

-o-

I'm glad that you have a version of Disks, that can do the job :-)

Hi sudodus,

I'm not certain exactly which machine I used to create the startup disk which caused me trouble (I have a few *buntu machines around running various daily builds, plus an Ubuntu 14.04 LTS one also). It's likely that the program causing problems was the one on the 14.04 machine, as this problem hasn't occurred with every startup disk I've made recently, and I've made them from various machines, even the daily builds.

So, I'm happy to call this resolved...

Thanks!
Ken.
***