[nSLUG] Another debian issue resolved

Donald Teed donald.teed at gmail.com
Wed Jun 15 07:53:03 ADT 2005

I'm sharing these in case anyone else moving to Debian sarge
is puzzled by the same thing, especially those who are
used to Gentoo, Redhat and others that come with inits
already set up with dependencies.

By default, anything set up with update-rc.d gets
a sequence code of 20.  There are a bunch of network
related inits set as 20.  I probably added some of those
via the update-rc.d defaults.  I can't think of an distro I've
used before where I've ever had to play with the sequence
codes, except picking one for a package alien to that distro.

For some odd reason, bind came in as sequence order 15.
But networking was set as 20, so bind was always bombing out
on start up.  I set up networking init script as sequence order
13, and now bind is happy on boot up.

Debian could use two concepts Gentoo has: a dependancy line
at the top of the init, to prevent it from running too early, and
a tool like rc-status - which prints all init daemons currently
running, as well as showing which are set to boot/default/off,
which rcconf partially handles in Debian.

Now a question:

Does anyone know why I get this sort of error in dmesg output:

mtrr: no MTRR for f2000000,800000 found
mtrr: no MTRR for f2800000,400000 found
mtrr: no MTRR for f2c00000,200000 found
mtrr: no MTRR for f2e00000,100000 found
mtrr: no MTRR for f2f00000,80000 found
mtrr: no MTRR for f2f80000,40000 found
mtrr: no MTRR for f2fc0000,20000 found
mtrr: no MTRR for f2fe0000,10000 found
mtrr: no MTRR for f2ff0000,8000 found
mtrr: no MTRR for f2ff8000,4000 found
mtrr: no MTRR for f2ffc000,2000 found
mtrr: no MTRR for f2ffe000,1000 found
mtrr: base(0xf2000000) is not aligned on a size(0xfff000) boundary

Or alternately, simply how to fix whatever it is.  I believe I had
mtrr enabled in my Gentoo kernel config, and still have it set up
in Debian.  The mtrr error doesn't seem to effect the running
of the system.

I briefly tried a stock Debian kernel image for 2.6.8 and ran into
2 issues: everything is a module, it seems, and 2.6 might not
like an existing mdadm raid set up from a 2.4 kernel.
The second part might be resolved by giving it a config
in mdadm.conf (but 2.4 doesn't need it).

In my opinion, md and raid* have little to no practical use
as modules. They should always be compiled into the kernel.
I can easily work around that by building my own kernel, but
for those who don't, this would be much more useful.



More information about the nSLUG mailing list