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
>
