[syslinux] Possible memdisk issue

[Ady]

> 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
 
I'd like to point out some details, just in case some casual reader 
overlooked them.

Regarding the existence of different FreeDOS kernels for different 
FAT variants (FAT12/16/32), it should be noted that a FreeDOS kernel 
supporting FAT32 is also capable of supporting FAT12/16.

On the other hand, FreeDOS uses different boot code according to the 
filesystem (FAT12/16/32). This is one of the reasons for boot failure 
when changing the fs size. Moreover, the VBR includes values that are 
specific for its corresponding FAT volume; so when the size of a FAT 
image is changed these values should also be adequately changed.

Additionally, I would suggest to confirm/check you are using a 
FreeDOS _i386_ kernel, unless you really need the kernel to boot 
8086.

In practical terms, all this means that if you want/need to obtain a 
FAT12 image by using newmkfloppyimg.sh, the original image should 
rather also be a FAT12 one. If you want a FAT16 image by means of 
newmkfloppyimg.sh, you are better starting with another FAT16. BTW, 
the image size is (indirectly) one of the parameters that influence 
whether the fs is FAT12 or FAT16 or FAT32.

Finally, when using MEMDISK to boot floppy images, these images 
should not use partial "cylinders". In other words, use exact CHS 
values for floppy images, instead of building the images by means of 
the desired megabytes size. Then use the selected CHS values as 
parameters for MEMDISK.

Regards,
Ady.