similar to: Dell machine boots a Windows formatted FAT16 USB drive not a Ubuntu formatted FAT16 drive.

> Hi All, > First post and hopefully someone can steer me in > the right direction for this problem. I did a bit > of googling and found some hints but nothing concrete. > > We are using Syslinux and a FAT32 USB thumb drive > (single partition) to boot a customized Debian OS > which works very well with newer motherboards. > However we have a few older Dell

>I tried the commands that you have presented and I running into >problems. I tried the ideology that you presented with both 32 and 16mb >configurations with no luck. Is there something that I'm missing? > >The win98se boot disk boots (just downloaded it from bootdisk today) so >I used that as a based for the boot file. > >Item 8c works fine (1.44 image) but 8b

Thanks for Remko for his help to solve the fractional cylinder problem. But there is the second problem, the boot disk failure (see below << [B]) ... command line: initrd=disk.img harddisk c=2 h=256 s=63 BOOT_IMAGE=memdisk Disk is hard disk, 16128K CHS=2/256/63 <<<< [A] ... Loading boot sector... booting... SYSLINUX 2.04 welcome! boot: 1 [single dot]

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

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.

On 07/15/2014 06:57 PM, Ady wrote: > > 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. > If you have a proper set

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

On 02/26/16 09:54, Gene Cumm via Syslinux wrote: >> >> I'm not exactly sure how that would work (how would you mark those clusters >> as wasted when my understanding is that the FAT's can't provide any >> knowledge about them in the first place?) and unless it is automatically >> integrated and ran during the Syslinux installation, it sounds quite >>

On 07/08/2014 05:55 PM, H. Peter Anvin wrote: > On 07/08/2014 03:05 PM, Alexander Perlis wrote: >> >> Question: what's special about the transition from 8203KiB to 8204KiB? >> Both have CHS=8/64/32 and both involve a fractional end cylinder. > > Fractional cylinders with floppy disks is almost certainly a very bad thing. > Agreed, but that doesn't appear to

On 01/21/2014 11:13 AM, Thomas Schmitt wrote: > > My current theory is that vendors prefer to record > a cylinder aligned end CHS address over recording > an end CHS address which exploits the whole capacity. > This is used as an (inofficial ?) protocol to publish > the CHS factors H' and S'. > Indeed it is -- at least some BIOSes "deduce" the H/S to use

> > Both sticks show very unusual factors for heads and sectors > > which are hardly intentional. If BIOS gets confused like fdisk, > > then the failure to find files is quite plausible. > > > > ------------------------------------------------------------- > > > > Could you please exercise what is described for Linux in > >

Hello, there is a "fdboot.img" floppy drive image included with FreeDOS ISO file. It's a floppy image file: root at debian64:~# file -s /home/martin/FreeDOS/isolinux/fdboot.img /home/martin/FreeDOS/isolinux/fdboot.img: x86 boot sector, FREE-DOS BEta 0.9 Bootloader KERNEL.SYS, code offset 0x40, OEM-ID "FreeDOS ", sectors/cluster 2, root entries 112, sectors 720 (volumes

Hello Marc I am having the same issue mentioned below. I ran the mkdosfs, and received the following: /dev/sdb contains a mounted filesystem Can you help? On Tuesday 10 July 2007 11:16, Visar Zejnullahu wrote: >* hi I'm new to this, and already havin some trouble :( *>* *>* I tried to make my usb pen drive bootable with sysliux, but I got this *message: >* *>* syslinux: this

Quick summary: Syslinux stops at "Boot failed". Which, from a quick look at the raw disk image, seems to indicate that the boot sector loads but it fails to load the .sys loader. The details: I've been trying to load Linux (or etherboot...or anything at all that is not NT embedded) into a set of Compaq Evo T20 48/64 for a while now. What I finally managed to do is using the

At: http://www.serverelements.com/naslite.php the following command is supplied near the bottom: **fdformat /dev/fd0u1722 ** I have plugged in my USB floppy drive and have a /media/floppy I get no such file or directory with this command. And what is this with a 1722 formatted floppy. What I do a man fdformat, 1722 is not listed....

As I said before, booting is bigger than one bootloader. I am replying to what I think was asked. I might have misunderstood the questions. Whichever the case, this email is less about Syslinux itself. If this is considered too far off-topic in the Syslinux Mailing List, please receive my apologies. > > I still have the factory-set contents of my three USB sticks. A small

[disclaimer: I am the author of Rufus] Hi, On 2014.01.15 10:10, Thomas Schmitt wrote: > As producer of MBRs i wonder where that LBA-flag is located. > In bit 0 to bit 6 of byte 446 (where bit 7 means active/bootable) ? I haven't looked at what GParted does, so I may be off mark, but I have a strong suspicion that this LBA "flag" is a fake flag that simply indicates if a

Hi, Ady wrote: > If a specific BIOS' CHS/LBA translations cannot cope with the above, it > is no surprise that we get some mess, somewhere. Currently my suspicion is that the isohdpfx.S code simply mishandles the two conversion factors which it correctly got from BIOS call INT 13H AH 8. > Boot System ID : First : Last : Relative : Number of: > Flag

Hello, are there known issues with some bioses not booting from Superfloppy format? All I get is the Syslinux (c) line and nothing else happens afterwords. Everything works fine if a partition is added to the device. Unfortunately however the target device can not be partitioned. Any hint? Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters

Hi, funny or enlightening observation: With my qemu-system-i386 it would work if the detected Heads/Cylinder and Sectors/Head factors would change positions ! The effective read operation seems to use H/C = 32 , S/H = 63. The correct LBA would be addressed by H/C = 63 , S/H = 32. -------------------------------------------------------------------------- Reasoning: I have transplanted the