> > > 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
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 >> > 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?Correct.>> > 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.?EBPB. Without it, a FAT file system is near impossible to reliably read.>> > 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? :-)There's only 2 reasons to know this depth of information. 1) Coding. 2) Install outside the installer. Why do you want to install the VBR and ldlinux.sys without the syslinux/extlinux installer? You realize the installer can be recompiled without rebuilding SYSLINUX itself? In theory, I believe you could do a syslinux installer for some arm9 Linux OS.>> 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...TL;DR: Your work might only install a certain version. Without the history, you might fail other versions.>> 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?Correct.> Thanks again to both of you!-- -Gene
> > I have been looking at trying to leverage the installation without the > > installer. How did you know? :-) > > There's only 2 reasons to know this depth of information. 1) Coding. > 2) Install outside the installer. >Well, there is always the third, which is most likely for me: insanely curious and just *have* to know how it works. But in this case, Gene is correct. :-)> Why do you want to install the VBR and ldlinux.sys without the > syslinux/extlinux installer? >I might need to install in an environment where I don't have syslinux available. Most of the time, at the very least, I can "docker run -v myimg.img:/data/foo.img ..." and run syslinux against that volume-mounted image, even if I am not running on a normal standard linux distro, but there have been cases where I need to manipulate the bits directly. Not many, but some.> TL;DR: Your work might only install a certain version. Without the > history, you might fail other versions. >Got it. Not sure which path I will take it, but at the very least, very interesting. Much appreciated. -- Avi Deitcher avi at deitcher.net Follow me http://twitter.com/avideitcher Read me http://blog.atomicinc.com