Created attachment 468312 [details]
The mkusbinstall used to create the bootable USB drive.
Description of problem:
I tried to make a USB drive with customized Fedora with a "mkusbinstall" script that uses syslinux on a Fedora 14 machine (syslinux v4.02-3.fc14.x86_64). When I try to boot with that USB drive, I get a "vesamenu.c32 not a COM32R image" error message. But when I tried to use the same script on a Fedora 13 system (with syslinux 3.84-1.fc13.x86_64), the pendrive successfully boots. I suspect if there is a problem with syslinux 4.02-3.fc14.x86_64.
Version-Release number of selected component (if applicable):
Use syslinux to create a bootable USB drive.
Steps to Reproduce:
1. Create a USB disk with syslinux 4.02-3.fc14.x86_64
2. Boot with the USB disk.
An error message at the boot time "vesamenu.c32 not a COM32R image"
Should boot to GRUB menu.
If you press the "tab" key, a text menu
will be shown, and at least you can boot.
However, this is not what I would like to see.
I would like to have my graphical menu back...
Therefore, I am using F12 to create bootable USB drivers for now.
Upgrading to syslinux 4.03 in F14 did not change anything.
(In reply to comment #0)
> Created attachment 468312 [details]
> The mkusbinstall used to create the bootable USB drive.
Not part of Fedora. is it?
> Description of problem:
0) See http://syslinux.zytor.com/wiki/index.php/Common_Problems#Modules : "Syslinux v4+ is strictly incompatible with older COM32 modules as the format has had a significant change (COM32 to COM32R), generating a "not a COM32R image" error."
1) Try replacing the vesamenu.c32 on that USB drive with the version shipped with syslinux-4.02-3.fc14.x86_64.
2) Assuming 1) does work: CLOSED/NOTABUG of CLOSED/WONTFIX?
(In reply to comment #2)
> (In reply to comment #0)
> > Created attachment 468312 [details]
> > The mkusbinstall used to create the bootable USB drive.
> Not part of Fedora. is it?
It is actually a part of the Syslinux component of Fedora.
> > Description of problem:
> 0) See http://syslinux.zytor.com/wiki/index.php/Common_Problems#Modules :
> "Syslinux v4+ is strictly incompatible with older COM32 modules as the format
> has had a significant change (COM32 to COM32R), generating a "not a COM32R
> image" error."
> 1) Try replacing the vesamenu.c32 on that USB drive with the version shipped
> with syslinux-4.02-3.fc14.x86_64.
Replacing the vesamenu.c32 file on the USB worked. But I think the "syslinux -d" command that we are using should put the correct vesamenu.c32 file in there?
> 2) Assuming 1) does work: CLOSED/NOTABUG of CLOSED/WONTFIX?
(In reply to comment #3)
> (In reply to comment #2)
> > Not part of Fedora. is it?
> It is actually a part of the Syslinux component of Fedora.
I'm afraid I still can't find a tool called "mkusbinstall" shipped by Fedora (not via rpm, not via yum, nor in any other way). What file, in what package is this all about?
The mkusbinstall is a custom shell script which uses syslinux to write Fedora derived linux iso (OLPC XS) to USB drive. I have attached the script file for reference purpose only. All the problem discussed in this bug-report is about syslinux writing an incompatible vesamenu.c32 image file to the usb disk. When you replace that file on the usb disk with the one at /usr/share/syslinux/vesamenu.c32 file, the problem is solved. But I am amazed at why syslinux is writing an incompatible vesamenu.c32 file to the disk.
Created attachment 472769 [details]
Script for using system-rescuecd on a pen drive
(In reply to comment #5)
> The mkusbinstall is a custom shell script which uses syslinux to write Fedora
> derived linux iso (OLPC XS) to USB drive.
So it's not part of Fedora's sylinux component
> All the problem discussed in this bug-report is about
> syslinux writing an incompatible vesamenu.c32 image file to the usb disk.
syslinux doesn't install modules. It only installs ldlinux.sys to the usb stick.
The script basically seems to convert an isolinux setup to a syslinux setup. Apparently you used it on an iso image that uses a pre 4.00 syslinux version so any modules used in that isolinux setup are incompatible with syslinux 4.00 (and later) you used (when running it on F14).
It might be possible adapt the script to check for modules in the isolinux setup and update these. Anyhow, this looks CLOSED/NOTABUG to me.
In my case, I was using syslinux to produce a bootable
pen drive with system rescuecd:
I attached the script, and at the end there is a call to syslinux.
If I write the pendrive on F14 and then just call syslinux again
on another computer running F12, the graphical menu is back.
I did not try copying /usr/share/syslinux/vesamenu.c32 to the pen drive,
but it should work, I guess. But the real problem is syslinux writing
the wrong file. There are plenty of complaints about syslinux on Ubuntu fora too.
LiveUSB Creator and Fedora-mini iso reproduces this same behavior... got a fresh download of both and ran creator on windows... on booting (vaio vpc) from USB, same message.... don't have a place to copy the file from... so currently stalled.
(In reply to comment #9)
> LiveUSB Creator and Fedora-mini iso reproduces this same behavior...
What version of LiveUSB Creator exactly and what version of "Fedora-mini"? Chances are you are using version 3.93 or later of Fedora LiveUSB Creator (which uses syslinux 4.*) with a F13 or earlier Fedora .iso image (which are syslinux 3.* based).
I was just getting around to add that information... sorry I didn't get into my original comment: LiveUSB Creator: 3.9.3 and fedora(13)-mini just as you predicted. So, I should grab USBLive < 3.9.3 if I want to use f13, zat right?
(In reply to comment #11)
> So, I should grab USBLive < 3.9.3 if I want to use f13, zat right?
0) Yes (unless I'm misreading my earlier comments).
1) Feel free to add a "ticket" to LiveUSB's "ticket" system at https://fedorahosted.org/liveusb-creator/ (that "ticket" system appears to hold rather a lot of spam). Please ask LiveUSB to check for syslinux setups (in the Fedora images it uses to do its trick) that are incompatible with syslinux 4.* (which LiveUSB currently uses).
2) Can this issue be set to CLOSED/NOTABUG (or whatever)?
This message is a notice that Fedora 14 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 14. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 14 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here: