similar to: Chain module - chaindev branch

Hi, Can chaindev of Michal Soltys, finally be merged? http://www.syslinux.org/archives/2011-August/016777.html - Gert Michal Soltys message Mon Aug 1 16:38:16 PDT 2011: http://www.syslinux.org/archives/2011-August/016777.html ------------------------------------------------------------------------------------------------------------- On 11-08-01 20:07, H. Peter Anvin wrote: > On

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

While playing with some less than usual configurations, I've got bitten few times by geometry settings in case of, usually, microsoft[ish] systems. First two examples, then the improvement idea. Example #1 My usb stick has zip-compatible geometry, which should work fine both in hdd and zip modes. It usually does, at least as far as syslinux and normal software is considered - excluding

On Mon, Feb 20, 2017 at 2:17 PM, Ady Ady via Syslinux <syslinux at zytor.com> wrote: > Correct the "seg=" value(s) corresponding to the "reactos=" option > for chain.c32. > > The correct segment parameter should be "seg=0x0F80", > instead of the incorrect / failing ones "seg=0:0x8000:0x8100". > > References: >

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: *

(snip) > > It's a bit more complex. At the time of writing, the data was perfect. > > https://git.reactos.org/?p=reactos.git;a=blob;f=reactos/boot/freeldr/freeldr/include/arch/pc/x86common.h;hb=28e58e6d01892c1f2f0e1d323745e6463cb9e6c9 > dated 2011-06-14 > >

Correct the "seg=" value(s) corresponding to the "reactos=" option for chain.c32. The correct segment parameter should be "seg=0x0F80", instead of the incorrect / failing ones "seg=0:0x8000:0x8100". References: https://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/notes.txt?revision=73859&view=markup&pathrev=73859#l24

This is a set of few chain post-merge patches - mostly revolving around simple adjustments, though a few are somewhat larger and/or introducing new features (nothing particularly complex though). Fetch details at the bottom. I didn't spam the list with mass of mostly banal patches, though of course I can send them any moment if necessary. Summary of a few more important ones: -

git://git.zytor.com/users/genec/syslinux.git Branch handoff-mbr-for-hpa This is a piece of code that can be used in place of a MBR or VBR/PBR (master boot record; volume/partition) in order to examine the data handed to the respective boot code. AX, SS, and SP are destroyed before examining anything. I set an internal restriction that limits it to 420 bytes such that it could be used with a

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

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.

On 12/2/18 10:33 AM, Richard W.M. Jones wrote: > The cow and cache filters both use a bitmap mapping virtual disk > blocks to status stored in the bitmap. The implementation of the > bitmaps is very similar because one was derived from the other when > the filters were implemented. > > The main difference is the cow filter uses a simple bitmap (one bit > per block), whereas

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

It's useful to be able to search for the next non-zero entry in a bitmap. This commit adds a ?bitmap_next? function to do that. Because the bitmap is just a uint8_t buffer, using fast string functions we should be able to do this quickly even if the bitmap is sparse. (However the actual implementation is not optimized since that is quite complicated - see to-do comments in

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

On 10/13/2010 08:36 AM, syslinux-bot for Michal Soltys wrote: > Commit-ID: 9c8db7560e2dc83d1191bb2f90b4d4d0ae3d37d6 > Gitweb: http://syslinux.zytor.com/commit/9c8db7560e2dc83d1191bb2f90b4d4d0ae3d37d6 > Author: Michal Soltys <soltys at ziu.info> > AuthorDate: Wed, 13 Oct 2010 10:57:36 +0200 > Committer: Michal Soltys <soltys at ziu.info> > CommitDate: Wed, 13

The cow and cache filters both use a bitmap mapping virtual disk blocks to status stored in the bitmap. The implementation of the bitmaps is very similar because one was derived from the other when the filters were implemented. The main difference is the cow filter uses a simple bitmap (one bit per block), whereas the cache filter uses two bits per block. This commit abstracts the bitmap

Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this always causes problems because VDDK comes bundled with broken replacements for system libraries, such as libcrypto.so and libstdc++.so. Two problems this causes which we have seen in the real world: (1) User does ‘export LD_LIBRARY_PATH=vmware-vix-disklib-distrib’ and that breaks lots of ordinary utilities on their system. (2)

On 2/13/20 8:01 AM, Richard W.M. Jones wrote: > Do not use LD_LIBRARY_PATH to locate the VDDK library. Setting this > always causes problems because VDDK comes bundled with broken > replacements for system libraries, such as libcrypto.so and > libstdc++.so. Two problems this causes which we have seen in the real > world: > > (1) User does ‘export