similar to: [syslinux:disklib] disklib: make CHS calculation match core/fs/diskio.c

>From the earlier patches - that simple fix for indexes not counting non-data partitions in gpt and mbr cases. Patches don't touch any other parts of the code at this stage - bigger stuff later for disklib as we agreed - but this is potentially useful right now. Michal Soltys (1): chain.c: fix public index value in mbr and gpt iterators

On Tue, Dec 2, 2014 at 8:27 PM, Michal Soltys <soltys at ziu.info> wrote: > Hi, > > For 6.xx: > > git://hasevolq.net/syslinux.git sys6 > > Michal Soltys (3): > chain/partiter: call notsane_gpt_hdr() per header > chain/partiter: add options to ignore GPT crc checks > chain: year update in commments (trivial) I'm not sure "Copyright

This is a bit updated set of chain.c32 changes that simplifies a few things (and in partiter part), fixes few minor issues and adds a few new features. Details are in the following commits, below is the summary and pull details at the end. Shao - any chance to peek over them ? Most of those are relatively simple changes and well tested, though of course something might have slipped my attention.

This small set fixes few bugs, improves gpt handling (under buggy conditions) and implements strict flag with more fine grained control which should fix issues with sanity checks against disk sizes. If this set is allright I'd want to do what I mentioned in older discussion with Ady - backport missing patches from 6.x to 5.x and 4.x so all versions have up to date chain version. Michal

Hi, For 6.xx: git://hasevolq.net/syslinux.git sys6 Michal Soltys (3): chain/partiter: call notsane_gpt_hdr() per header chain/partiter: add options to ignore GPT crc checks chain: year update in commments (trivial) Main addition here are separate options from 'strict' to ignore crc checks against gpt header and/or gpt partition list, so the user can force booting

Sorry for a bit longer delay than I anticipated, I was stuffed with the work. This is the next iteration of the patch adding some functionality to apcsmart driver, and relying on 'ignorelb' recently added. Follow up from previous thread: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02331.html Main differences is that V3 is split into many small patches, so the

Hi Michal, I've cc'ed -upsdev, since some info could be interesting for everybody. 2011/5/27 Michal Soltys <soltys at ziu.info> > On 11-05-25 09:35, Arnaud Quette wrote: > > Hi Michal, > > > > 2011/5/25 Michal Soltys <soltys at ziu.info <mailto:soltys at ziu.info>> > >(...) > > > > I'm preparing larger patchset with

This patch introduces extra functionality to chain.c, mainly with reference to BPB adjustments, but not only that. It expects 3 small patches I sent earlier (they are included for easy reference, patches 1-3/4). The changes introduced are: 1) file and boot sector use separate options to control load address and jump address (if applicable). Options are as described below: *

Hello Erwan, You will find below a pull request for the bug reported by Robert Jordan in the disk library. The first patch is the one he tested (see http://syslinux.zytor.com/archives/2010-September/015341.html) and the second one is a sanity check for the number of sectors written by call ( see http://syslinux.zytor.com/archives/2010-September/015342.html). Thanks, The following changes

Inital tests with two apc units (2005 and pre-2000) seem to go well. See commit message for details. I'll add more detailed rationale after getting some sleep :) Michal Soltys (1): apcsmart: switch processing to ICANON + minor fixes drivers/apcsmart.c | 270 +++++++++++++++++++++++++++++++++++----------------- drivers/apcsmart.h | 127 ++++++++++++++++--------- 2 files changed, 267

Arnaud, I was finally able to get back to this issue and would recommend adding these items to the FAQ #37 about recalibrating the UPS: 1a. It's important that the UPS be at 100% charge before starting the procedure; starting at lower will not work at all, not just produce inaccurate numbers. ? ? ? [I started the procedure when the UPS was at 91% charge. After that it would never report

So last week I was wondering if XFS was still working -- even with its last on-disk structure changes -- and it _suprisingly_ worked as expected. Right, now I can finally get rid of GRUB and use Syslinux to boot my Linux on EFI from a rootfs with xfs. Shit, I have two partitions (the first one being the required ESP) so there is no way to access the other partitions since because Syslinux does not

Hello, the following patches should get multidisk access working. The syntax accepted is the following: (hdx,y)/path/to/file where x is the disk number and start at 0 and the y is the partition number starting at 1. So (hd0,1) is the first partition of the first disk. the other accepted syntax is using MBR's 32 bits disk signature so for example: (mbr:0x12345678,2)/foo/bar would address

Namely something like: ups.runtime - amount of seconds since powering up The reason is essentially "side effect" of this bug report: http://article.gmane.org/gmane.comp.monitoring.nut.user/7705 Where T denotes total time since ups' power up. On upses with AP9612TH it's used for dual temperature sensors (which top of apcsmart branch should gracefully support). Either way,

This is 2nd version of the earlier patch featuring a few new features and fixes to the apcsmart driver, following the remarks in: http://www.mail-archive.com/nut-upsdev at lists.alioth.debian.org/msg02294.html Major changes from v1: - handle battery.charge and battery.runtime checks at main.c level - handle "immutable but writable" conflict gracefully at driver level -

Configurations with multiple shared namespaces can trigger a bug where the first argument of strcmp() invocation is NULL. This patch adds an explicit check, analogously to how the second argument is sanitized. --- src/lib-storage/mail-storage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/lib-storage/mail-storage.c b/src/lib-storage/mail-storage.c index

Hi I was thniking about that chaindev branch I see slowly rotting in my git - and I was wondering: would it be acceptable to change it from "replace existing chain.c32" to "provide alternative altchain.c32" ? The rationale for such request: - chaindev resides in its own directory under com32, so there're no conflicts possible - the dependency on disklib is trivial

> > Message: 6 Date: Tue, 18 Sep 2007 10:44:42 +0200 From: Michal Soltys > <nozo@ziu.info> Subject: Re: [LARTC] I''m having an issue with u32 > masking To: lartc@mailman.ds9a.nl Message-ID: > <46EF8FFA.6070707@ziu.info> Content-Type: text/plain; > charset=ISO-8859-1; format=flowed Vadtec wrote: >> > Is this how tc is supposed to work? Does it only

I'm preparing a few simple patches that will cleanup few things regarding new chain - in particular the ones I mentioned in Januray during discussion with Shao (tone down overkill abstractions, etc.). One question on a formal side though - which license is preferred at the top of the source files ? Currently there're two present - either something bsd-ish (on parts derived from

1) public index in gpt iterator should not skip empty partitions, e.g. if we have 1st and 3rd gpt entry used, we expect the numbers to be 1 and 3, not 1 and 2 (similary to how linux sees it e.g. /dev/sda1 and /dev/sda3). It's analogous to index / mbr_index fix. 2) free(ebr_part); in mbr iterator was not reachable. ebr iterator takes care of freeing itself and its parent. 3) in ebr iterator,