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