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