sfdisk problem?

[Marc Martinez]

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