sfdisk problem?

[justin]

Ok, that binary seemed to resolve one of the issues that I had to mangle
some code over.  However, I'm stilling getting a bad input error from
sfdisk.  The input looks fine however.  I'm going to keep looking into it.

-justin


On Fri, 1 Feb 2002, Marc Martinez wrote:

> On Fri, Feb 01, 2002 at 05:27:05PM -0500, justin wrote:
> >
> > Hey Marc,
> >
> > I'd definitely be interested in testing the sfdisk package.  What I've
>
> the problem is that the 'util-linux' package includes lots of
> important things, and sfdisk is a fairly rarely used program among
> them.  this is why I'm reluctant to put together a full package
> release, and I'm not sure if I finished the backport work to the
> regular fdisk program and such (which would definitely be desirable
> for a packaged version).  to get you up and rolling for the time being
> I'll send along a gzip'ed binary privately so as not to bloat the list
> archives.
>
> > been spending the last 45 minutes or so doing has been patching the patch
> > to work w/ my configuration.  One bug that I found was the patch wasn't
> > taking empty partitions into account.  i.e. There are a couple zero size
> > partitions on my current install client.  This errors out setup_harddisks
> > because it attempts to divide by zero via:
> >
> > $PartOldStart{$device} = int ($2 / $DiskUnits{$disk});
>
> actually I don't think this has to do with my patch, or at least the
> parts of it I originally worked out .. I saw odd zero handling as well
> in the beginning when I was trying to preserve partition 3, with 1 and
> 2 populated for the fai-boot and root filesystems.  no disk space was
> allocated for the first 2 partitions, but all the extended area ones
> came out fine.  since the damn smart-start utilities couldn't seem to
> keep a consistent partition number allocated across the existing
> servers I had installed to reference with, but did use a predictable
> area of the disk, I hacked up a seperate script to relocate the system
> partition to #1 using the same block areas.  after that the
> setup_harddisks was able to lay out everything fine according to my
> size guidelines.
>
> > However this throws off the script in a couple areas so I'd rather get a
> > good binary than tear it apart any further :-D
>
> yes, the script is quite "fragile", and I saw lots of areas for small
> improvements and things that made me go "ugh", but thankfully Thomas
> has decided to re-implement it in the future, and it sounds like the
> replacement will be much nicer to work with.
>
> in any case, it sounds like you're getting really close, shouldn't be
> much left to sort out from here..
>
> Marc
>