sfdisk problem?

[justin]

Hey Marc,

I'd definitely be interested in testing the sfdisk package.  What I've
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});

I'm going to try out compiling a good sfdisk binary per your instructions
as I found that I could get sfdisk to output the correct information by
explicitly appending the device name to the end of the line, for example:

sfdisk -g -q /dev/ida/c0d0

as opposed to just:

sfdisk -g -q

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

If you have a package ready to go let me know if not I'll just go ahead
and put together my own.

btw I'm using potato

Thanks,

-justin

On Fri, 1 Feb 2002, Marc Martinez wrote:

> On Fri, Feb 01, 2002 at 01:45:00PM -0500, justin wrote:
> > When I run this in the bash shell it returns the following error:
> >
> > "modprobe: Can't locate module block-major-36"
> >
> > I'm pretty sure this is because I'm using a modified kernel.
> > I'm curious if anyone knows what I need to satisfy this dependency, or if
> > there is another way to do this.  I'm attempting to install this on a
> > compaq DL380 w/ the SMART2 RAID Controller.  I've grabbed the latest
> > 'setup_harddisks' and 'subroutines' from cvs.debian.org w/ the /dev/ida
> > patch as well.
> >
> > Let me know what you think, especially if you're thinking that the problem
> > is something completely different.
>
> actually I think the "block-major-36" message is harmless in this case
> and not the actual source of your problem.  you don't mention if
> you're using potato or woody as the base for all this, but I'll take a
> guess at potato and explain the final piece to the raid controller
> puzzle.  I believe I mentioned having to use a patched sfdisk binary
> before, but no details were expounded upon, so here goes..
>
> the util-linux package in potato doesn't have the same level of
> support for raid devices that the current stuff in testing/sid does.
> my solution was to pick apart the source from sid and backport the
> raid device naming routines to the potato sources.  getting a clean
> build of the newly patched sources though proved to be tricky, see
> http://bugs.debian.org/util-linux for the "cannot build from source"
> issue.  I should look that one up again and add the workaround I
> found, which was: go back to 2.2r0 (I just needed to find my cd set,
> and grab the third disc) and get the kernel-headers-2.2.17 package
> from there.  with those installed the nfs issues caused by the
> transition to nfsv3 in 2.2.18 will no longer affect the build process,
> and you should be able to produce a new pkg fairly easily afterwards.
> in my haste, I only copied the resulting sfdisk binary out to the fai
> nfs root to get things rolling, I still intend to go back at some
> point and get a clean diff against it for my personal fai cvs archive.
>
> the device naming routines used in the newer util-linux sources are
> what I based my patch to setup_harddisks off of, on the premise that
> "we're only as broken as the tools we rely on" this way.
>
> I can post a patch here later today for what I modified the util-linux
> sources with.  if it proves to be very difficult to get the right
> headers installed and the new binary built, I'll see about posting a
> binary for sfdisk somewhere publically accessible.  I'm very leary of
> publishing or deploying a new full pkg until I have time to test it
> out in a few different places, but again, if there's enough demand for
> a pkg and people are willing to test it blindly I'll try and accomodate.
>
>
> Marc
>