similar to: Structure of VBR in FAT32?

> > > Is the build process documented? Or am I just going to have to plod > through > > the makefiles? > > I don't think so. > Oh well... > > 1. Run installer > > 2. Installer loads ldlinux.sys onto the filesystem (and copies > ldlinux.c32, > > but irrelevant for now). > > 3. Installer calculates which blocks in the filesystem contain

Gene, thanks for doing "Reply-All". I only get digest, so this keeps me in the loop. Appreciated. > which appears to be included in diskstart.inc. I will have to dig in and > see > > how this all gets compiled (pointers always appreciated :-) ). > > Yes. > Is the build process documented? Or am I just going to have to plod through the makefiles? > As Ady said,

> You are thinking GRUB-like, among (too) many others. Heh, at least I am in good company. > A "sector" is not necessarily 512-bytes long. Fair enough, e.g. Advanced Format 4k sector disks. > The VBR, or Volume Boot Record, is not necessarily 512-bytes long. > Also, the VBR doesn't need to be restricted to the first sector of the volume alone. The "Design"

Sorry for the late response. I am set to digest on this list. One of my chief complaints about mailman (besides non-searchable archives), is that you can either get every message or digest, but not "digest except for threads to which I have responded for which I want every message directly". > The command line installers have the core module and the bootloader file, all embedded

Hi Syslinuxers, I am trying to understand the basic load chain in fat32 and ext4. I dug into the assembly for MBR, which is pretty straightforward: 1. Find boot partition (or use the pre-defined one at byte 440 for altmbr.bin) 2. Load the first 512-byte sector of the partition (VBR for fat32, Block Group 0 padding for ext). 3. Execute that code The code that is loaded, however, has to be too

Thanks for the response, Gene. Much appreciated. I didn't get all of it; mind if I follow on below? ldlinux.sys is ldlinux.bin without the VBR (Volume Boot Record) code. > Makes sense. > > 1. Where is the code that goes in the VBR or Block Group 0 padding? > > diskboot.inc. > which appears to be included in diskstart.inc. I will have to dig in and see how this all gets

On Sat, Jan 6, 2018 at 12:34 PM, Avi Deitcher <avi at deitcher.net> wrote: >> > Is the build process documented? Or am I just going to have to plod >> > through >> > the makefiles? >> >> I don't think so. > Oh well... >> > 1. Run installer >> > 2. Installer loads ldlinux.sys onto the filesystem (and copies >> >

> A simple test would suffice: execute the official installer and compare > the "new" ldlinux.sys file (that the installer just put there) with the > original one included in the official archive. This simple test could > be performed on an empty, FAT12-formatted 1440KiB floppy image. Will do. Makes sense. It will show the difference, although not how it works. > People

On Wed, Jan 3, 2018 at 2:38 AM, Avi Deitcher <avi at deitcher.net> wrote: > Gene, thanks for doing "Reply-All". I only get digest, so this keeps me in > the loop. Appreciated. > >> > which appears to be included in diskstart.inc. I will have to dig in and >> > see >> > how this all gets compiled (pointers always appreciated :-) ). >>

On Tue, Jan 2, 2018 at 1:03 PM, Avi Deitcher <avi at deitcher.net> wrote: > Thanks for the response, Gene. Much appreciated. I didn't get all of it; > mind if I follow on below? > >> ldlinux.sys is ldlinux.bin without the VBR (Volume Boot Record) code. > > Makes sense. > >> > 1. Where is the code that goes in the VBR or Block Group 0 padding? >>

I'm trying to add boot support to https://github.com/libguestfs/nbdkit/tree/master/plugins/floppy This NBD server plugin generates a completely virtual FAT filesystem and partition table. Nothing is ever written to a file, and it must run without anything needing to be root, loop mounting etc. Running "syslinux --install <something>" is a non-starter. So I've looked at

On Mon, Jan 1, 2018 at 11:06 AM, Avi Deitcher via Syslinux <syslinux at zytor.com> wrote: > Hi Syslinuxers, > > I am trying to understand the basic load chain in fat32 and ext4. I dug > into the assembly for MBR, which is pretty straightforward: > > 1. Find boot partition (or use the pre-defined one at byte 440 for > altmbr.bin) > 2. Load the first 512-byte sector of

Hi Ady, I won't comment on the reasons why the original computation was wrong, but thanks for the detailed analysis. On 2016.02.26 08:05, Ady via Syslinux wrote: >> Thus we can finally get a formula for Fs that satisfies the above: >> >> Fs = (To - Rs + Nf * Cs) / ((Ss * Cs / Fe) + Nf) + 1 > > I believe such formula is slightly inaccurate too. > > My

I know syslinux supports FAT16 and works very well, but how about FAT32? Does syslinux support FAT32? If so, which version? eg., 3.11 and above Thanks!

> Hello, > > Gene Cumm said on Thu, Oct 22, 2015 at 06:39:44PM -0400: > >On Thu, Oct 22, 2015 at 1:56 PM, Bruno Cornec via Syslinux > ><syslinux at zytor.com> wrote: > > > >> 3/ Using syslinux.efi in a FAT32 image (similar to the previous 2 > >> confs) stored on a iso9660 media by genisoimage and its > >> -eltorito-alt-boot -efi-boot

I have some concerns about the Syslinux boot process, which I'm now investigating in connection with my work on booting Live-CD images from USB flashdrives. Some of these are related to what seems to be inadequate documentation, but I think that there are also aspects of Syslinux operation which could be fairly easily improved. quoting from the official documentation: Since version 5.00,

When trying to installing Syslinux on a FAT32 drive formatted using Ridgecrop's Large FAT32 formatting tool [1], the installer will bail due to the minfatsize check, as there is an extra sector being used. This fix addresses that. [1] http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm -------------- next part --------------

Windows uses several sectors in the _partition_ for booting. Windows only uses sector 0 of the Disk (the MBR), and does not use any other sectors. Other boot managers and copy protection software (the stuff that comes with TurboTax this year uses track 0, evil...) For FAT16 filesystems, only the first sector is used. For FAT32, there are 32 sectors that are reserved by the FS, and I've come

Hi Ady, On 2016.02.25 02:08, Ady via Syslinux wrote: > There is an "extra" sector, in comparison to... what exactly? Sorry if I wasn't clear. I think I implied that the Large FAT32 fat size had an extra sector compared to minfatsize, when of course I meant the opposite (the Large FAT32 has one less sector than the minfatsize computed by the unpatched code, hence the check

Hi Ady, Your insightful post prompted me to to a little bit more digging as to how the Ridgecrop algorithm computed its FAT size, with the result of my investigations presented below. NB: For those who don't want to go through this whole part, there's a TL;DR near the end. For reference, the computation of the FAT size all done in the GetFATSizeSectors(), the code of which is at [1]