similar to: Structure of VBR in FAT32?

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,

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

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

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

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

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

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

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

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 :-) ). >>

> 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

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

> >Are you willing to dd such image (*not* using Windows OS) and provide > >feedback? > > Yes. More broadly, I am willing to dd and try *any* image you might > ask me to try. > Hi Ronald, You posted in a recent email in this same email thread, about successfully booting an ArchLinux USB. Among several differences in comparison to your prior tests, you used a

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,

Here's some reminders for various branches that are pending. All branches are at my public repo at git://git.zytor.com/users/genec/syslinux.git ( http://git.zytor.com/?p=users/genec/syslinux.git;a=summary ) HPA, I'd appreciate a response in the direction of a status like on hold, under review, denied or to be completed soon. Branch win64-mingw32-ubuntu-for-hpa adds more prefixes in

> > You will be happy to know that your test image _does_ appear to boot OK > on my GA-M55Plus-S3G, from either/both of my test sticks (4GB & 8GB). > > Whatever magic you did, it seems to have worked. (Please _don't_ go > into too much technical detail, but... in layman's terms... what did > you do?) > > Here is what I got after booting from the 8GB

Hi all, I was using grub2 for booting Archlinux x86_64 in my GPT Internal HDD (/dev/sda) then I switched to syslinux/extlinux. It was working fine but suddenly it staring showing "Boot Error" message on screen. I googled for a solution and tried all syslinux versions from 4.04-pre4 down to 4.03-stable but non of them worked. I don't know what suddenly changed caused this

A proposal for changing the LDLINUX.SYS layout and flow: The current situation ("old style"): ldlinux.bin's physical layout: - VBR - 512 bytes of padding (never lands in memory) - ldlinux.sys, which is: - Sect1 code (494 bytes, leaving enough room for at least one extent, as planned) - Extent pointer patch space (1920 bytes) - The rest of the code

On Tue, Jan 21, 2014 at 2:41 PM, mike setzer <qualityana at sbcglobal.net> wrote: > hello Gene, > > good to get your message > > I have not seen a link to reply to a particular thread, > so I am replying to you right now > hopefully the thread can be made to look right, also I double posted since my connection was lost > right during the first posting. Sorry, I

> > In message <BLU0-SMTP2805E16A0E7A33B925EDF458BB80 at phx.gbl>, > Ady <ady-sf at hotmail.com> wrote: > > >Now, to move forward with Clonezilla in your USB drive, we need to > >proceed with some steps that are not as simple as dd'ing an image. > > Apologies for my impertinence, but I have one question: Why? > > I was under the impression