similar to: Structure of VBR in FAT32?

> 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

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

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,

> 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

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

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

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

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!

My problem is that whenever I try to copy a large file from a client machine to a fat32 partition (ext3 works fine) mounted under samba, the host linux machine will lock up completely. I can, however, copy small files to the fat32 partition just fine (ie. 1 KB to 1 MB size file), it's only when I copy files that are about 200 MB and larger, that the computer will lockup. NAT still

Hi, I am not an engineer or linux expert but I have been using syslinux to boot live disk filesets (extracted from iso's) residing on fat32 and NTFS volumes. In FAT32 there has been no problem going with larger cluster sizes up to the nominal maximum of 64K however, with NTFS it has not been possible to exceed the cluster size of 4096. With NTFS formatted using clusters of 8192 or larger,

Hi... I decided to delete my fat32 partition (sda1, with win2k on it). I did that with fdisk and added a linux partition, then formated it with "mkfs -t ext3 /dev/sda1" ... Everything seemed to work fine... I can even mount it with "mount -t ext3 /dev/sda1 /mnt" ... but there seem to be some fat32 rubbish left because when I do "mount /dev/sda1 /mnt" it seems to

Hi, I have been using rsync for over ten years. Thank you! It is a great tool. Recently I had the misfortune to have to use it to sync files to a USB stick that is for a platform that only supports FAT32. After missing the point a few times and having it copy some of the same directories and files needlessly I saw the timestamps on the source files (in reasonable filesystems like JFS, XFS,

Hi, I have a problem backing up my music collection, that is stored on a fat32 formated hard drive to my ext3 formated backup drive (ext3 to ext3 works like a charm :) ). The problem is, that rsync always transfers all of the files and not only the one that were changed/added. I know of the limitations fat32 has but I can't find the correct options to run the backup. Thanks Thomas

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 computed by the unpatched code, hence the check

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

https://bugzilla.samba.org/show_bug.cgi?id=10675 Summary: rsyncing >2GB file onto fat32 partition should fail earlier Product: rsync Version: 3.1.0 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: core AssignedTo: wayned at samba.org