[syslinux] Possible memdisk issue
Alexander Perlis
aperlis at math.lsu.edu
Tue Jul 15 15:47:55 PDT 2014
On 08Jul2014--09Jul2014, Ady, Peter Anvin, Gene Cumm, Bernd Blaauw, Shao
Miller, Kenneth Davis, wrote:
> [...]
Thank you all for your responses. You helped me solve my problem. For
anyone else that runs into similar trouble and finds this thread, here
follow summaries of what I've learned.
To recap, our PXE server holds Dell BIOS updates in FreeDOS floppy
images booted via MEMDISK. For newer hardware those update programs are
huge, so require enlarged floppy images. (I prefer floppy images over
hard drive images because it seems easier to quickly loop mount and
modify a floppy image in Linux, than to loop mount a buried partition
from within a hard drive image.) To enlarge existing floppy images, I
originally learned of newmkfloppyimg.sh from this mailing list, and had
followed the procedure
http://www.syslinux.org/wiki/index.php/Large_floppy_images
to go from a current 1.44MB FreeDOS fdboot or fdoem to a 10MB version
thereof, but trying to boot the result with MEMDISK led to an infinite
loop of MEMDISK banners. That's where the discussion started, and turns
out I titled the thread poorly: it really has nothing to do with MEMDISK!
1) newmkfloppyimg.sh calls mkdosfs to create an enlarged floppy image
and then copies over the existing boot sector --- but the enlarged
floppy image might have a *different* underlying file system, in which
case that copied boot sector won't work.
2) That is to say, FAT12, FAT16, and FAT32 are different, and require
different boot sectors. (And in the case of FreeDOS, also require
different versions of kernel.sys.)
3) newmkfloppyimg.sh doesn't show the output from mkdosfs, so you won't
know whether the file system changed.
4) After-the-fact, you can determine whether two images have the same
underlying file system type by running "dosfsck -V imgfile" and looking
for the number in front of "bit entries".
5) Or look inside newmkfloppyimg.sh and run mkdosfs manually to look at
all the output for clues as to what was created.
6) To eliminate a change in filesystem, you can change the parameters
that newmkfloppyimg.sh passes to mkdosfs. For example, if your old image
was FAT12, include "-F 12" in the parameters that newmkfloppyimg passes
to mkdosfs. But be sure to inspect the output from mkdosfs, as it will
kick out a warning or error if the requested size is incompatible with
the imposed file system type, and newmkfloppyimg might not notice. In
other words, in some cases you cannot avoid changing file systems!
7) To remedy an unavoidable change in file system, you'll need to
replace the boot sector, and likely also some files. In the case of
FreeDOS, you can replace the boot sector from within Linux using the
Perl script at
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/sys/sys-freedos-linux/sys-freedos-linux.zip
--- it auto-detects the FAT type in your image file and puts in the
appropriate boot sector. You'll also need to go to fdos.org and obtain
the correct kernel.sys (there's one for FAT{12,16}, and a different one
for FAT32, and each flavor comes in x86 and x386 versions). If you told
the Perl script to put in an LBA version of a boot sector, and you're
going to boot the image with MEMDISK, be sure to also pass "edd" to
MEMDISK so that it will respond to the LBA-based INT13 calls.
8) If you don't want to use the Perl script from the prior paragraph,
you can instead use the SYSLINUX approach: running syslinux against a
FATxx image file will detect the FAT type and put a tailored syslinux
boot sector and syslinux kernel in the image, and then you'll also need
a small syslinux.cfg and chain.c32, to then chain over to your FreeDOS
kernel.sys. But note that if you run newmkfloppyimg.sh to enlarge such a
syslinux-based floppy and this causes a change in the underlying file
system, it seems you'll have to run syslinux again to update the boot
sector. (Although nearly identical, the FAT{12,16,32} syslinux boot
sectors do have a few bytes of difference.) And you'll also have to
update the FreeDOS kernel.sys. I played with the SYSLINUX approach per a
suggestion in this thread, as well as the approach from the previous
paragraph per another suggestion, and personally chose to settle on the
previous paragraph as being easier for my particular situation.
9) As an alternative to all this work, if you trust the source, there
are mostly blank superfloppies of many different sizes at various
websites, for example http://bootcd.narod.ru/images_e.htm . That is,
instead of enlarging an existing image, just start with a working one of
the size you need. I tried the 11.52mb one in a VM and it booted. Our
building's HVAC system mysteriously stopped running a minute later, but
I understand that can't be related.
10) Finally, having learned all this, it's not so hard to just construct
a superfloppy of your desired size from scratch entirely within Linux:
use mkdosfs to create an empty image file and hold on to the output for
FAT type and geometry info. Then use sys-freedos-linux.zip from
paragraph 7 to put boot code into sector 0 of that image. Finally, loop
mount the image and copy in an appropriate kernel.sys and command.com
from FreeDOS. Now PXE boot the result with MEMDISK and smile.
Again, thank you to everyone who responded and helped me get on the
right path.
Alex
More information about the Syslinux
mailing list