Red Hat Bugzilla – Bug 174186
diskboot.img: support of several USB-boot standards
Last modified: 2007-11-30 17:11:17 EST
There is diskboot.img file, suitable for booting from a USB flash (or other
bootable media larger than a floppy).
There are several USB-booting standards: USB-HDD, USB-FDD and USB-ZIP.
Currently, diskboot.img seems to have support for USB-FDD only.
I hope there is a really possibility to support all 3 formats simultaneously. It
can be done using "makebootfat" utility (which now is pending for review to be
included into Fedora Extras, see bug #170504 ).
The USB-HDD (Hard Disk Drive) standard requires the presence of a partition
table in the first sector of the disk.
The USB-FDD (Floppy Disk Drive) standard requires the presence of a filesystem
starting from the first sector of the disk.
The USB-ZIP (ZIP Drive) standard requires the presence of a device with
some specific geometry and partitioning.
Generally these standards are incompatible, but using "makebootfat" with
the "-m", "-F" and "-Z" options one can create a disk compatible with all of them.
This report is not a request for review of the review-pending package (:)), just
use makebootfat to make universal diskboot.img for final FC5!
Appropriate links to "makebootfat" can be found here: bug #170504
Makebootfat has already appeared in Fedora Extras repository!
These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks
Nothing changed yet.
(It is not an upstream-related thing, therefore it was a bad idea to close this
ticket automatically... :( )
I specifically excluded reports with severity set to enhancement. Might be
better to mark this one as a enhancement request rather than a bug report and
set product version to devel . Agreed?
> Might be better to mark this one as a enhancement request
Maybe. I thought of it when wrote this ticket...
But IMHO the situation is:
- there is a "diskboot.img" file, intended to boot from the USB flash. Currently
this image supports only one (from three) of the possible USB boot standards.
If it was support in 80% of cases, and I would suggest to support the rest of
20%, then it would be an enhancement. But it supports only 1 from 3 (say 30%),
and a lot of people can be confused by this... IMHO, it is more bug rather than
USB floppy should be the type used for, eg usb keys as this image is intended to
be used on. All of the hardware I have access to works exactly as expected with
things as they are now.
My ThinkPad X60s does not boot from USB drives because of this. It supports
USB-FDD and USB-HDD (and USB-CD, which works), but insists that my USB drive is
a USB-HDD device, and thus fails to boot from the image on the stick.
let's try to reopen this now (for fc7)
requested by Jams Antill
Ok, lets get this going :)
I need something to test it with. Can the reported please give me specific
models of usb keys that comply with each specification. In that way I can ask
for them, test the patches and get this feature/bug fixed :)
It is not related to the model of USB flash. IMHO you can try any USB flash
Actually you should find a computer which does the usb boot using USB-FDD
standard, a computer which uses USB-HDD standard and so on.
Initially, I had a computer with USB-HDD (some HP Compaq?), and hence was not
able to boot it using diskboot.img (because currenlty it is for USB-FDD only).
After the preparing of diskboot.img, it was possible to boot it.
Maybe it is better to search Internet for "Cannot boot Linux from USB" etc.?
mhm.. which makes stuff that much harder :) if you have the specific model of
the box in which it failed it would help a lot. It gives me a starting point :)
Maybe better to focus not on a particular model, but on the "well-known
standard" instead? USB-HDD seems not a corner case, just find a doc about it in
I hope the things can be done a simpler way:
- Read more about USB-FDD, USB-HDD and USB-ZIP (perhaps at makebootfat's home
page as well)
- Implement/create a new "universal" diskboot.img
- Check that this new diskboot.img is OK for the hardware you already have
(guess USB-FDD )
- And wait for user reports, like comment #7
IOW the usb boot standards are described good enough, do not search for a
hadrware by all means...
I did want to get some personal tests before anything. I'll create a blind
patch and through it to the community and see what happens. :)
I have tried a various number of combinations with the makebootfat application
to generate and I cannot boot from usb. I will describe the process I followed
in the hope the someone can tell me what I'm doing wrong :(.
1. Take the diskboot.img from the fedora installation tree and mount it some
place that I can have access to the files.
[root@dhcp-lab-188 table0]# ll diskboot
-rwxr-xr-x 1 root root 292 2007-09-26 13:04 boot.msg
-rwxr-xr-x 1 root root 919 2007-09-26 13:04 general.msg
-rwxr-xr-x 1 root root 5697523 2007-09-26 13:04 initrd.img
-rwxr-xr-x 1 root root 10932 2007-09-26 13:04 isolinux.bin
-r-xr-xr-x 1 root root 10092 2007-09-26 13:04 ldlinux.sys
-rwxr-xr-x 1 root root 817 2007-09-26 13:04 options.msg
-rwxr-xr-x 1 root root 517 2007-09-26 13:04 param.msg
-rwxr-xr-x 1 root root 490 2007-09-26 13:04 rescue.msg
-rwxr-xr-x 1 root root 32270 2007-09-26 13:04 splash.jpg
-rwxr-xr-x 1 root root 813 2007-09-26 13:04 syslinux.cfg
-rwxr-xr-x 1 root root 117152 2007-09-26 13:04 vesamenu.c32
-rwxr-xr-x 1 root root 1902435 2007-09-26 13:04 vmlinuz
2. Make sure that the usb is partitioned to be bootable. and has a fat16
partition type (I'm following the livecd wiki
3. create an image directory:
[root@dhcp-lab-188 table0]# ll image0/
-rwxr-xr-x 1 root root 292 2007-09-26 13:05 boot.msg
-rwxr-xr-x 1 root root 919 2007-09-26 13:05 general.msg
-rwxr-xr-x 1 root root 10932 2007-09-26 14:03 isolinux.bin
-rwxr-xr-x 1 root root 817 2007-09-26 13:05 options.msg
-rwxr-xr-x 1 root root 517 2007-09-26 13:05 param.msg
-rwxr-xr-x 1 root root 490 2007-09-26 13:05 rescue.msg
-rwxr-xr-x 1 root root 32270 2007-09-26 13:17 splash.jpg
-rwxr-xr-x 1 root root 117152 2007-09-26 13:17 vesamenu.c32
4. Run the makebootfat command
makebootfat -o usb -Y -Z -b /usr/share/makebootfat/x86/ldlinux.bss -m
/usr/share/makebootfat/x86/mbrfat.bin -F -c diskboot/ldlinux.sys -c
diskboot/syslinux.cfg -c diskboot/vmlinuz -c diskboot/initrd.img image0/
5. Test the USB boot:
The error shown in the screen reads
Additionals: The test machine that I'm using is a Dell Precision 490 (info on
tech specs can be found at
More over, when doing a dd if=diskboot of=/dev/sdb bs=1M count=13 and booting
from that usb, the boot works.
First of all,
Did you read the /usr/share/doc/makebootfat-1.4/README.usbboot file?
- Don't use '-c' options, just copy all needed files to your image0/
- As I remember, the partition table are created by makebootfat (some special
way). We can add more partitions later, but not create the initial table by hand.
- NEVER work with the usb flash immediately! Just work with losetup(8)'ed image.
Then copy the generated image (including partition table etc.) to the flash,
i.e. dd bs=512 <image.img >/dev/sdX
- Follow README.usbboot -- it worked! (at least a year ago... :) )
Can you confirm that the process described in the readme still works for you.
It spit out an error that it didn't find the ldlinux.sys file (the file is in
the directory and makebootfat is not seeing it for some reason). When using the
-c option to include the file the boot fails with the message described in
1. Put the info contained in the README in the man pages :), The manpages are
my usual point of reference and IMO this is the case for most people. As I
didn't see any reference to this file in the man pages, nor the bug report, I
had no idea this file existed.
2. I'm a little confused with the information in the current man page and the
README file. You say in comment 16 to not use the -c option, but in the man
page this behavior is encouraged when creating the usb boot image. What gives?
Moreover the process described in the manpage is very different from the one
described in the readme.
3. I tried to make the image to a file and then put it in usb, when that didn't
work I did it directly :) (This is not a suggestion, just clarification)
> Can you confirm that the process described in the readme still works for you.
Since syslinux version 3.x, it is not working for me... :(
But it seems to work when we use ldlinux.sys file from the makebootfat tarball.
I'll do further checking and release an updated makebootfat package, with proper
ldlinux.sys and README.usbboot .
> Put the info contained in the README in the man pages :)
Certainly nope. :)
It is an upstream task to change their manual page "so considerable", but I'm
not the upstream maintainer. I may just add an additional README.fedora or
similar file to docs.
> The manpages are my usual point of reference
> and IMO this is the case for most people.
Consider Fedora packages now -- all of them have something useful in
/usr/share/doc/name-version/*, as well most of them have something in
/usr/share/man/* . But normally noone mentions in their manuals that users
should go to doc dir...
It is obvious for "skilled" users and admins that there can be something in the
doc dirs... ;)
Initially I proposed makebootfat idea for Fedora gurus, hence I hoped they
understand me without extra words. But unfortunately they was too busy to hear
I successfully boot from usb an image prepared by makebootfat from F7's diskboot.img
- I have to use "ldlinux.sys" from the makebootfat tarball (test/ subdir).
To be sure I take "ldlinux.bss" there as well.
- I have to comment out "default vesamenu.c32" and use "default linux" in
Perhaps makebootfats ldlinux.sys (version 3.08) still not supports this feature
(diskboot.img has ldlinux.sys from version 3.36)
The commands I use:
dd bs=1M count=16 </dev/zero >image.img
makebootfat -v -o image.img -b ldlinux.bss -m mbrfat.bin -F -c ldlinux.sys -Y
dd bs=512 <image.img >/dev/sdX
Could you confirm that this way (or similar) works for you too?
Nice :), it worked, but as expected the graphical menu is not shown and the F
keys don't work :(. mmm... wait... My keyboard does not work either :(.
do you see the same results ???
My keyboard works fine :)
I just type "linux text" and enter...
sorry Dmitry no dice :(
I would say that the behaviour of the created image is somewhat puzzling. I
tested the makebootfat image in other boxes and it booted fine. I retested on
my test box and it didn't boot :( (again the model is a dell precision 490).
Moreover when I used the original diskboot.img on my test machine it booted up.
I will give the situation the benefit of the doubt and test on another dell of
the same model and see what happens (once I get my hands on one :) but the fact
that the original diskboot.img works does not give me a lot of hope.
could this be a makebootfat bug. Have you tested on this machine?
> I tested the makebootfat image in other boxes and it booted fine
Well, can those boxes be booted by the original (USB-FDD only) diskboot.img?
Just to know what is bad exactly...
> I retested on my test box and it didn't boot
You mean the keyboard still did not work, or something else?
> the fact that the original diskboot.img works
Fine, it means that your machine uses USB-FDD standard. And my test machine uses
USB-HDD. We have to find USB-ZIP somewhere ;)
- We should not use ldlinux.sys from diskboot.img, just use "clean" one from the
syslinux source tarball
- We should use ldlinux.bss from the same version of syslinux tarball.
Perhaps "ldlinux.sys" in diskboot.img are prepared some magic way ("cmp -l"
shows some differencies with the original syslinux one), which prevents it to be
used for makebootfat. Previously (at syslinux-2.x time) all works fine...
OK, just get the proper ldlinux.* files and use it for makebootfat.
F7's diskboot.img has its own ldlinux.sys of version 3.36 . Therefore goto
download syslinux-3.36 and extract ldlinux.sys and ldlinux.bss from it.
I have to think how to package all this stuff into makebootfat... :|
...and surely uncomment "default vesamenu.c32" -- it works fine for me.
I've created new makebootfat package; could you look for it (and do the further
tests with it)?
It worked. It also worked with the vesamenu.c32 (please confirm). AFAICS the
makebootfat has to have very specific ldlinux files (talking about the .bss and
the .sys) I'll give it a try and see what I find :)
OK, we have them running :)
This is the line I used to create the image :). and probably the one I will use
in the anaconda code.
makebootfat -v -o usbimage.img -Y -b /usr/share/makebootfat/x86/ldlinux.bss -m
/usr/share/makebootfat/x86/mbrfat.bin -F -c
Since we are in fedora8 freeze I will hold this change for f9 :) This also give
you time to get the package into the repos :)
> It also worked with the vesamenu.c32 (please confirm)
> It worked.
Well, USB-HDD is booted by this image for me.
Does any USB-FDD host (which was booted OK by the original diskboot.img) boot by
the new image as well?
> makebootfat -v -o usbimage.img -Y -b /usr/share/makebootfat/x86/ldlinux.bss -m
/usr/share/makebootfat/x86/mbrfat.bin -F -c
For Anaconda, you should just get ldlinux.bss/ldlinux.sys from the syslinux
package (as it was done, IMHO, when the original diskboot.img was created).
Anyway, it is better to use the latest syslinux, because makebootfat's files
might be obsoleted a little.
Certainly mbrfat.bin is from makebootfat only :)
I have some successful tests even when build with "-Z" option (but I have no
USB-ZIP machine). On the other hand, such a format requires some special
geometry on the "disk" and the boot partition must be number 4. Perhaps it makes
the result image capable to create "flash for boot only", but not "flash for
boot and general use".
"-F" variant (USB-FDD + USB-HDD only), where we have only one "bootable"
partition (number 1) initially, allows us to create additional partitions (by
fdisk etc.) on the remaining space on the flash. For example, I have 2Gb flash,
with 2 partitions: first 16Mb for boot, and second ext2 with all available
space. (I frist dd image to the flash, and then add second partition).
In result, it seems possible to create both "boot and general use" flash, and
even place on the second partition some yum repository. This way (if Anaconda
supports local disk's yum reposiroties) we can boot and install from the same
media (majecticly looked for a small flash among coins in a pocket :) ).