On Tue, 08 Jul 2014 15:54, H. Peter Anvin wrote: > >On 07/08/2014 11:26 AM, Ady wrote: >> >> It's interesting that you ask this, because every document related to >> newmkfloppyimg.sh specifically recommends adding: >> floppy c=$CYLINDERS s=$SECTORS h=$HEADS >> to the MEMDISK arguments. >> > >It would be important for floppies to know if the geometry that MEMDISK >guesses is the one that you actually intended. This will be in the >information that was snipped out. Ah, this might explain things although I don't know what is meant by "intended". First, to clarify, newmkfloppyimg calls mkdosfs 3.0.12, and grabs H/S from the output and then computes C. For all the sizes I've tried, newmkfloppyimg always tells me H=64 S=32 and then C is the approximately the number of MB. And MEMDISK auto-determines those exact same numbers. But if I manually call mkdosfs there's a lot more output, most of it ignored by newmkfloppyimg. In particular, the output for 8203K and 8204K is different: mkdosfs -I -v -C test8203 8203 mkdosfs 3.0.12 (29 Oct 2011) test8203 has 64 heads and 32 sectors per track, logical sector size is 512, using 0xf8 media descriptor, with 16406 sectors; file system has 2 12-bit FATs and 8 sectors per cluster. FAT size is 8 sectors, and provides 2043 clusters. There are 8 reserved sectors. mkdosfs -I -v -C test8204 8204 mkdosfs 3.0.12 (29 Oct 2011) test8204 has 64 heads and 32 sectors per track, logical sector size is 512, using 0xf8 media descriptor, with 16408 sectors; file system has 2 16-bit FATs and 4 sectors per cluster. FAT size is 16 sectors, and provides 4085 clusters. There are 4 reserved sectors. In both cases, newmkfloppyimg says to use "C/H/S=8/64/32", and that's what MEMDISK is using. So I believe I'm "intending" those values. Or are they not correct? Alex
On 07/09/2014 01:54 PM, Alexander Perlis wrote:> > Ah, this might explain things although I don't know what is meant by > "intended". First, to clarify, newmkfloppyimg calls mkdosfs 3.0.12, and > grabs H/S from the output and then computes C. For all the sizes I've > tried, newmkfloppyimg always tells me H=64 S=32 and then C is the > approximately the number of MB. And MEMDISK auto-determines those exact > same numbers. But if I manually call mkdosfs there's a lot more output, > most of it ignored by newmkfloppyimg. In particular, the output for > 8203K and 8204K is different: > > mkdosfs -I -v -C test8203 8203 > mkdosfs 3.0.12 (29 Oct 2011) > test8203 has 64 heads and 32 sectors per track, > logical sector size is 512, > using 0xf8 media descriptor, with 16406 sectors; > file system has 2 12-bit FATs and 8 sectors per cluster.FAT12...> FAT size is 8 sectors, and provides 2043 clusters. > There are 8 reserved sectors. > > mkdosfs -I -v -C test8204 8204 > mkdosfs 3.0.12 (29 Oct 2011) > test8204 has 64 heads and 32 sectors per track, > logical sector size is 512, > using 0xf8 media descriptor, with 16408 sectors; > file system has 2 16-bit FATs and 4 sectors per cluster.FAT16...> FAT size is 16 sectors, and provides 4085 clusters. > There are 4 reserved sectors. > > In both cases, newmkfloppyimg says to use "C/H/S=8/64/32", and that's > what MEMDISK is using. So I believe I'm "intending" those values. Or are > they not correct? >So this would seem consistent that this is the FAT12/FAT16 boundary that breaks stuff. Perhaps FreeDOS has a problem with FAT16 on floppies? You can experiment with this by explicitly specifying -F 12 to mkdosfs, which forces it to stick to a 12-bit FAT. -hpa
On 07/09/2014 01:54 PM, Alexander Perlis wrote:> file system has 2 16-bit FATs and 4 sectors per cluster. > FAT size is 16 sectors, and provides 4085 clusters.It is worth noting that 4085 is literally the smallest number of clusters that a FAT16 filesystem can have, and the FAT format is determined by the cluster count, so an off-by-one error in FreeDOS could definitely cause a crash here. In fact, the FAT specification recommends avoiding generating FAT filesystems which are within ?16 clusters of the cutoff values of 4084/4085 and 65524/65525, at the very least by default. This might be worth introducing in mkdosfs. I have to admit to having written a chunk of that code long ago. It is pretty darn hideous. -hpa
On 07/09/2014 04:00 PM, H. Peter Anvin wrote:> > So this would seem consistent that this is the FAT12/FAT16 boundary that > breaks stuff. Perhaps FreeDOS has a problem with FAT16 on floppies?If I understand things correctly, a bootable floppy has two key pieces of executable code: the 512-byte boot sector, and the kernel loaded by that boot sector. The kernel can be large, and thus could perhaps in principle auto-detect FAT12, FAT16, FAT32, whereas the boot sector code is limited to around 460 bytes (as file system config data is also stored in there), so perhaps that's not enough space for auto-detection code? Perhaps there simply have to be 3 different boot sectors, depending on whether you've got FAT12, FAT16, or FAT32? That would explain what's happening here: newmkfloppyimg called mkdosfs, who made a different file system, yet newmkfloppyimg copied over the old file system's boot sector... Does anyone know whether it is possible to have a "universal" boot sector and "universal" kernel? Then if one starts with a base floppy image containing those, then newmkfloppyimg should create something bootable no matter what size is specified. Alex
On Wed, Jul 9, 2014 at 5:00 PM, H. Peter Anvin <hpa at zytor.com> wrote:> On 07/09/2014 01:54 PM, Alexander Perlis wrote: > > > > Ah, this might explain things although I don't know what is meant by > > "intended". First, to clarify, newmkfloppyimg calls mkdosfs 3.0.12, and > > grabs H/S from the output and then computes C. For all the sizes I've > > tried, newmkfloppyimg always tells me H=64 S=32 and then C is the > ... > > mkdosfs -I -v -C test8203 8203 > ... > > file system has 2 12-bit FATs and 8 sectors per cluster. > > FAT12... > > > FAT size is 8 sectors, and provides 2043 clusters. > ... > > file system has 2 16-bit FATs and 4 sectors per cluster. > > FAT16... > > ... >> So this would seem consistent that this is the FAT12/FAT16 boundary that > breaks stuff. Perhaps FreeDOS has a problem with FAT16 on floppies? > > You can experiment with this by explicitly specifying -F 12 to mkdosfs, > which forces it to stick to a 12-bit FAT. > > -hpa > > The issue appears to be the boot sector then. FreeDOS has multiple bootsectors, one for FAT12, 16, and a couple for FAT32 (LBA or CHS). The floppy disk image has a FAT12 boot sector, so it will not correctly interpret a FAT16 filesystem. The differences are minor so the FAT12 and FAT16 boot sectors are in the same source file, but 2 sectors are generated when building. I would suggest using syslinux and chain load the FreeDOS kernel, otherwise something like http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/sys/sys-freedos-linux/sys-freedos-linux.zip may be of help for updating the boot sector on images that use FAT16. Kenneth J. Davis
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