similar to: Structure of VBR in FAT32?

> 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"

> You might want to read Wikipedia's articles about "FAT32" and "Design of the FAT file system", Good pointer. I spent far far too long on that page figuring out how fat32 is designed. But the reserved sectors, there is the key. > reserved sectors Right! Immediately after the FSIS before the FAT.And it usually is 32 sectors for fat32. Take off the VBR and the FSIS,

> > > 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

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

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,

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

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 >> >

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? >>

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 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, > > 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 >

In the following text, I am about to use terms such as "inaccurate". I don't mean to question what some code does, but rather to compare the expressions against what I think is a more accurate one, in theory. I mean no disrespect, and I am not saying that developers are doing the wrong thing. In addition, of course I could be wrong (or type in incorrectly, or some formatting

On 2016.02.26 15:32, Ady via Syslinux wrote: > Regarding the "+1", when talking about the math (not the computer code > to achieve a result as accurate as it can be) Well, sorry, but I will not dissociate the context of application from the formula itself. I thought this was implied into what I wrote, which was in the context of fixing a computation algorithm bug. The sole

> 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 > The expression: "...as there is an extra sector being

> > instead of _always_ adding "+1" (which would be > > incorrect and inefficient from the point of view of the resulting > > allocatable size). > > I carefully considered this, and I dispute the fact that this is incorrect. > (snip) > Still, I won't prevent you (or anybody else interested) to provide a > proper formula if you want. ;) >

> 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

> Hello, > > Ady via Syslinux said on Sun, Oct 25, 2015 at 08:15:37PM +0200: > >_ Creating filesystem that _does_ conform to ISO-9660; > > I think the only issue is with a tag. That same image boots with grub > 0.99 I understand. My point is, in theory, "everything" is frequently expected to work as it was designed; in practice, it is not. So my suggestions

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

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!