[syslinux] chain.c32 Insane primary (MBR) partition

[Ady]

> 
> > On 2014-01-08 16:48, Ady wrote:
> > >>
> > >> The first line has been adjusted in later patches, but they are in
> > >> elflink and firmware branches only. Currently it would report:
> > >>
> > >> Primary (MBR) with invalid offset and/or length.
> > >>
> > >> This often happens if the disk/image is used on different computers
> > >> (e.g. on usb stick) and bios reports different disk sizes (usually +/- 1
> > >> sector). This is a bios bug (potentially nasty one, imagine GPT which
> > >> stores backup data at the end of the disk as well).
> > >>
> > >> As current version of chain loader supports a good few potentially
> > >> dangerous operations - mostly related to fixing chs geometry to match
> > >> the one reported by bios - it's very strict at testing if everything is
> > >> OK before proceeding.
> > >>
> > >> Current version also supports 'relax' option which turns off most sanity
> > >> checks, but it was added a good while after the v4 syslinuxes.
> > >>
> > >> v4.05 works fine, as it was before merging new version of chain.
> > >>
> > >
> > > I am not sure to which release(s) you are referring to when you say
> > > "current" chain.c32, but that's just a detail.
> > 
> > I meant 5.x/6.x branches (the ones that have all chain.c32 changes, as 
> > opposed to 4.x which stopped at some time).
> > 
> > Anyway, the changes to chain that landed on 5.x+ can be easily applied 
> > (or just squashed and applied as a single backport patch). On top of 
> > that I could use the opportunity to adjust that one dreaded thing - 
> > differing disk sizes and failing sanity checks - in perhaps more 
> > lenient/flexible manner.
> > 
> > Current approach is to expect relax flag to be added to chain module 
> > invocation while assuming more strict behaviour (and not possible on 4.x 
> > branch due to lack of patches).
> > 
> > Perhaps it would be better to simply detect this situation, issue a 
> > warning - but otherwise proceed without hiccups (which would be 
> > perfectly possible, save perhaps some corner cases that would fail 
> > either way - e.g. GPT layout, data at the begining of the disk failing 
> > crc checks, and backup data at the end of the disk incomplete / at wrong 
> > offset due to the sector difference).
> > 
> > It should be safe this way, as nosave is assumed by default - so has to 
> > be explicitly enabled to allow any writes. So we would have (asterisk 
> > denotes default):
> > 
> > save
> > *nosave
> > 
> > relax
> > *strict (allow differences on sanity checks vs. disk size + warning)
> > stricter
> > 
> > Or something similar / analogous. Perhaps 'save' could imply 'stricter' 
> > at the same time, unless explicity overridden.
> > 
> > Then minor number in 4.x series could be just bumped up, perhaps with 
> > some other pending fixes or so.
> > 
>  
> Hello Michal,
> 
> Just to discard any possible doubt, there are users and distros that 
> would welcome these patches / improvements applied to the 4.xx 
> branch:
> 
> http://git.zytor.com/?p=syslinux/syslinux.git;a=shortlog;h=refs/heads/
> syslinux-4.xx
> 
> There are already patches in the syslinux-4.xx branch that were 
> committed after the official release of 4.07.
> 
> The ideas you posted in your email sound very reasonable to me.
> 
> One thing is not *that* clear to me. Would backporting the later 
> patches from Syslinux 5/6 to Syslinux 4.xx (including the "relax" 
> option) be possible while still adding the latter concepts / 
> behaviors you posted in your email?
> 
> One thing I am sure of is that users currently using Syslinux 4.06 or 
> 4.07 are replacing chain.c32 with older versions, not updating 
> Syslinux. One reason for this behavior is the simplicity of replacing 
> one file vs. updating Syslinux.
> 
> There are features present in Syslinux 4.xx that are yet not 
> supported by Syslinux 5/6, so having chain.c32 working as expected 
> for these users and distros is important for them (including myself).
> 
> Thank you,
> Ady.

Hi Michal,

Any news about chain.c32 for the 'syslinux-4.xx' branch?

TIA,
Ady.