[syslinux] [syslinux:disklib] disklib: make CHS calculationmatch core/fs/diskio.c

[Shao Miller]

Gene Cumm wrote:
> On Mon, Oct 18, 2010 at 00:14, Shao Miller 
> <Shao.Miller at yrdsb.edu.on.ca> wrote:
> >> On 10/14/2010 09:08 AM, Shao Miller wrote:
> >>>
> >>> Somewhat unrelated: Some day in the far, far future, it might be 
> nice to
> >>> "re-image"[1] computers using INT 13h via one or more COMBOOT32
> >>> programs.  - Shao
> >>>
> >>> [1] Apply a disk or filesystem snapshot/saved-state.
> >>
> >> That's not even very hard at all, at least not for the whole-disk case.
> >
> > Andrew Bobulsky wrote:
> >>
> >> Hello Shao, hpa,
> >>
> >
> > Hello.
> >
> >> I thought it was really ironic that you guys mentioned this.  I 
> remember
> >> back when I was imaging XP, I was trying to work out specifically 
> what I'd
> >> want to do to get gPXE/PXELINUX/COMBOOT to simplify our imaging process
> >> which at the time was using a very clunky XP live CD that took 
> forever to
> >> boot up...  I ultimately ended up booting DOS from iSCSI and 
> imaging via
> >> INT13 with Ghost 8, which worked pretty well.
> >
> > That seems very familiar...  Until (for Windows) working out a 210 
> MB non-PE
> > XP RAM disk image and including NIC and SATA drivers; then there was a
> > definite gain from 32-bit network drivers.
> >
> >> Still, while I was wrapping my head around the concepts I was trying to
> >> exploit, I was browsing through all of these com32 modules in the 
> SYSLINUX
> >> package then hopped on IRC and said, "Hey guys, is there a COM32 
> module for
> >> imaging disks?  Something like DD.c32?"
> >
> > That seems interesting, and as H. Peter mentions, probably fairly
> > straight-forward to implement for sector imaging.  FS manipulation 
> would be
> > a different story. :S
> >
> >> While several people (you guys included I think) remarked that it 
> was an
> >> interesting idea, I never found anything...  Hence the Ghost 8 use :-D
> >
> > Well if we [Syslinux users/enthusiasts] had a DD.C32 COMBOOT32 
> module that
> > did something useful like write an image from the Syslinux 
> filesystem (TFTP:
> > hmm...) to a disk via INT 0x13, that might be a tiny start.  There 
> might be
> > a challenge if a RAID/SCSI adapter was a BEV device

Oops.  I'm pretty sure that I meant BCV rather than BEV.

> and if the user
> > PXE-boots but if that prevents the adapter's ROM from establishing 
> an INT
> > 0x13 hook.  I guess there's one way to find out.
>
> Most (but probably all) of the disk controllers (built-in
> RAID/SCSI/SAS/SATA, add-in Fibre Channel and RAID/SCSI) and
> PXE-enabled NICs (always LoMs; LAN On Motherboard) I've used load
> their BIOS extension before any boot entry is processed, granting
> access to the RAID volume from any boot (CD, HDD, RAID, FC or PXE) via
> INT 13h (until a driver is loaded, of course).

That's good news to read.  I might be superstitious due to running gPXE 
and iPXE "early" from their "early" CLI prompts, which indeed has 
inhibited SCSI adapters BCVs from hooking INT 0x13.  But that's my fault.

> ... ... ...

- Shao Miller