search for: sect1ptr1

...good kernel and image. But all the following reboot (without call to extlinux -i), roll back to the previous linux image (the one used before the previous call to extlinux -i). I'have check the boot sector content of the Ext4 partition. The pointers (found with offset computed with sect1ptr0, sect1ptr1) to the extlinux configuration change between reboot without calling extlinux. I have backup the Ext4 partition boot sector between each reboot with this command: dd if=/dev/sda2 of=$VERSION_DIR/boot/syslinux/bootsector.bak ibs=60928 count=1 conv=notrunc The file comparison show an unwanted chang...

...t;> But all the following reboot (without call to extlinux -i), roll back to the previous linux image (the one used before the previous call to extlinux -i). >> >> I'have check the boot sector content of the Ext4 partition. The pointers (found with offset computed with sect1ptr0, sect1ptr1) to the extlinux configuration change between reboot without calling extlinux. >> >> I have backup the Ext4 partition boot sector between each reboot with this command: >> dd if=/dev/sda2 of=$VERSION_DIR/boot/syslinux/bootsector.bak ibs=60928 count=1 conv=notrunc >> The fil...

...s "libinstaller/syslxmod.c" to modify the content (boot sector and ldlinux). > The question, is there a way to simulate the work that syslinux does > in a reasonably supportable way that won't break on future updates of > syslinux? > > Rich. > The Sect1Ptr0_VAL and Sect1Ptr1_VAL magic values didn't change in almost a decade. So a simple search and replace approach should work for a while. On the other hand the required offsets are embedded in "ldlinux.sys" (Sect1Ptr0, Sect1Ptr1 with Sect1Ptr0Ptr and Sect1Ptr1Ptr in the extended patch area). Since "ld...

...d image. > But all the following reboot (without call to extlinux -i), roll back to the previous linux image (the one used before the previous call to extlinux -i). > > I'have check the boot sector content of the Ext4 partition. The pointers (found with offset computed with sect1ptr0, sect1ptr1) to the extlinux configuration change between reboot without calling extlinux. > > I have backup the Ext4 partition boot sector between each reboot with this command: > dd if=/dev/sda2 of=$VERSION_DIR/boot/syslinux/bootsector.bak ibs=60928 count=1 conv=notrunc > The file comparison sh...

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

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

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,

git://git.zytor.com/users/genec/syslinux.git Branch core-diskstart-boot-for-hpa. I found that INT 13h AH 08h in BOCHS used ES, DI, at least when using a partitionless HDD, causing "Boot error" from the magic check as it was loaded to the wrong location. HPA suggested wrapping INT 13h with the push/pop for ES's safety. This then lead to checking over for all int 13h calls in

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

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