[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