> On 2014-01-03 08:07, Ady wrote: > > The following boot entries: > > # > > COM32 chain.c32 > > APPEND fs ntldr=/bootmgr > > # > > > > or: > > # > > COM32 chain.c32 > > APPEND hd0,1 ntldr=/bootmgr > > # > > > > might result in the following error: > > > > # > > Insane primary (MBR) partition. > > Can't find myself on the drive I booted from. > > # > > 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. Indeed the patches for chain.c32 of 2013Feb14 were applied to the elflink and firmware branches, but not to the 4.xx branch. Simultaneously, chain.c32 included in 4.06-pre2 (just before the application of the patches in the other branches) still works, and the one included in 4.06-pre3 (just after the patches in the other branches) fails as I previously described. Performing a web search of this issue, the "solution" is always the same: to replace the chain.c32 file with the one from v.4.05, even when originally booting with Syslinux 4.06 or 4.07. Probably, there are patches (not only for com32/chain) that were originally prepared for the 4.xx branch but were re-based for the elflink branch and applied to the latter. So perhaps some patches should be applied to the 4.xx branch too. TIA, 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.
> 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.