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, embedded within the syslinux/extlinux installer. >Got it. And I did a byte comparison of ldlinux.bin/ldlinux.sys. Identical except for the first 1024 bytes. First 512 are the VBR, as you described, next 512 are all zeros (I assume for using with ext?).> Actually, mildly more complex but similar. Setup some basics, the > first sector of ldlinux.sys, execute it. > > The first sector of ldlinux.sys sets up some more stuff, loads the > rest of ldlinux.sys, checks integrity then continues. >So... VBR (i.e. first 512 bytes of ldlinux.bin) contains code that knows to find and load first sector of ldlinux.sys. That in turn knows how to find the rest of ldlinux.sys, and loads that. ldlinux.sys itself understands fat32 well enough to find the rest of its modules, syslinux.cfg, etc.> Actually, only the first sector of ldlinux.sys, computed after > ldlinux.sys is copied and patched into the VBR by the installer. The > block map is in ldlinux.sys. > > >> At least one record stating N sectors at volume offset M > >> needs to live in the VBR. Often, only 1 record is needed. > > > > I didn't get this part. Record? > > It's more of a list. The list has rows or records. Each record > indicates data about a block of the file ldlinux.sys. This data is in > fields for offset sector number of start and how many sectors are > within the block.Let me see if I get this. 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 ldlinux.sys 4. Installer modifies first sector of ldlinux,sys to contain a list of all of the other locations of ldlinux.sys 5. Installer puts the first 512 bytes of ldlinux.bin into the boot sector 6. Installer modifies code in VBR (a specific byte?) to indicate which block contains first 512 bytes of ldlinux.sys On boot: 1. VBR is run (first 512 bytes of ldlinux.bin) 2. VBR knows how to find first block of ldlinux.sys 3. VBR loads first block of ldlinux.sys into memory and executes it 4. Code in memory and executing has map of all other blocks of ldlinux.sys, so it loads them. 5. Now have all the code we need to read fat32 filesystem, so it does, reads syslinux.cfg, loads c32 files, etc. Is that roughly it? I assume extlinux does the same thing, just has some more knowledge about other filesystems? -- Avi Deitcher avi at deitcher.net Follow me http://twitter.com/avideitcher Read me http://blog.atomicinc.com
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 :-) ). >> >> Yes. > > Is the build process documented? Or am I just going to have to plod through > the makefiles?I don't think so.>> As Ady said, embedded within the syslinux/extlinux installer. > > Got it. And I did a byte comparison of ldlinux.bin/ldlinux.sys. Identical > except for the first 1024 bytes. First 512 are the VBR, as you described, > next 512 are all zeros (I assume for using with ext?).I believe so.>> Actually, mildly more complex but similar. Setup some basics, the >> first sector of ldlinux.sys, execute it. >> >> The first sector of ldlinux.sys sets up some more stuff, loads the >> rest of ldlinux.sys, checks integrity then continues.> So... VBR (i.e. first 512 bytes of ldlinux.bin) contains code that knows to > find and load first sector of ldlinux.sys. That in turn knows how to find > the rest of ldlinux.sys, and loads that. ldlinux.sys itself understands > fat32 well enough to find the rest of its modules, syslinux.cfg, etc.Yep.>> Actually, only the first sector of ldlinux.sys, computed after >> ldlinux.sys is copied and patched into the VBR by the installer. The >> block map is in ldlinux.sys. >> >> >> At least one record stating N sectors at volume offset M >> >> needs to live in the VBR. Often, only 1 record is needed.I'm mistaken. Due to the size, about 3 should be normal.>> > I didn't get this part. Record? >> >> It's more of a list. The list has rows or records. Each record >> indicates data about a block of the file ldlinux.sys. This data is in >> fields for offset sector number of start and how many sectors are >> within the block. >Sect1Ptr0 > > Let me see if I get this. > > 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 ldlinux.sys > 4. Installer modifies first sector of ldlinux,sys to contain a list of all > of the other locations of ldlinux.sysAlmost. The blockmap MUST have at least one record in the first sector but the subsequent blockmap records may exist later. See "SectorPtrs" and "rl_checkpt_overflow". I believe 192 entries are currently allocated.> 5. Installer puts the first 512 bytes of ldlinux.bin into the boot sector... by reading the existing VBR, modifying ONLY the bytes allowed for code, then writing the modified VBR back.> 6. Installer modifies code in VBR (a specific byte?) to indicate which block > contains first 512 bytes of ldlinux.sysIt's 8 bytes for a 64-bit address located at the labels "Sect1Ptr0" and "Sect1Ptr1". These are NOT at fixed offsets and might move based on revisions of diskboot.inc. I'd suggest against trying to make a script to install. If you do that, you'd need to have detailed knowledge of how some of these structures work and how they've changed over time.> On boot: > > 1. VBR is run (first 512 bytes of ldlinux.bin) > 2. VBR knows how to find first block of ldlinux.sys > 3. VBR loads first block of ldlinux.sys into memory and executes it > 4. Code in memory and executing has map of all other blocks of ldlinux.sys, > so it loads them. > 5. Now have all the code we need to read fat32 filesystem, so it does, reads > syslinux.cfg, loads c32 files, etc. > > Is that roughly it? I assume extlinux does the same thing, just has some > more knowledge about other filesystems?extlinux lets the Linux kernel do all of the heavy lifting of installing the file then finding its blocks then performs the same modifications as syslinux does on FAT12/FAT16/FAT32. extlinux has less knowledge about ext2/ext3/ext4 and FAT12/FAT16/FAT32 file systems (basically 0 outside the FAT32 VBR format) than syslinux does about FAT12/FAT16/FAT32. -- -Gene
> > > 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 > ldlinux.sys > > 4. Installer modifies first sector of ldlinux,sys to contain a list of > all > > of the other locations of ldlinux.sys > > Almost. The blockmap MUST have at least one record in the first > sector but the subsequent blockmap records may exist later. See > "SectorPtrs" and "rl_checkpt_overflow". I believe 192 entries are > currently allocated. >I will look at the code to try and get it. All of this basically is, "how do we bootstrap a program that knows how to read FAT filesystem, when it itself is on that filesystem and we don't know how to read it yet." 192 entries = 192 potential sectors for ldlinux.sys?> > 5. Installer puts the first 512 bytes of ldlinux.bin into the boot sector > > ... by reading the existing VBR, modifying ONLY the bytes allowed for > code, then writing the modified VBR back. >So as not to ruin the EBPB or signature, e.g.?> > 6. Installer modifies code in VBR (a specific byte?) to indicate which > block > > contains first 512 bytes of ldlinux.sys > > It's 8 bytes for a 64-bit address located at the labels "Sect1Ptr0" > and "Sect1Ptr1". These are NOT at fixed offsets and might move based > on revisions of diskboot.inc. >That works. I will read it.> I'd suggest against trying to make a script to install.I have been looking at trying to leverage the installation without the installer. How did you know? :-) If you do that, you'd need to have detailed knowledge of how some of these> structures work and how they've changed over time. >That was what I was afraid of...> extlinux lets the Linux kernel do all of the heavy lifting of > installing the file then finding its blocks then performs the same > modifications as syslinux does on FAT12/FAT16/FAT32. extlinux has > less knowledge about ext2/ext3/ext4 and FAT12/FAT16/FAT32 file systems > (basically 0 outside the FAT32 VBR format) than syslinux does about > FAT12/FAT16/FAT32. >"kernel do all of the heavy lifting", i.e. it doesn't actually try to modify sectors and find blocks, but instead relies on the mounted filesystem and driver? Ah, is *that* why extlinus requires the filesystem to be mounted to run install? Thanks again to both of you! -- Avi Deitcher avi at deitcher.net Follow me http://twitter.com/avideitcher Read me http://blog.atomicinc.com