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

[Michal Soltys]

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.