Modules and runlevels.

Andy Peeters andy.peeters at advalvas.be
Fri Jan 12 09:34:28 PST 2001


On Thursday, January 11, 2001 10:43 PM, Simon Perreault wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday 11 January 2001 15:28, Andy Peeters wrote:
> > nls_cp437 is normal because I use the codepage iso_8859-15 (something
like
> > this). The only thing I want to get rid of, is that message in the log
> > file. Any idea how I can do this? Do I need to add a line to
modules.conf?
>
> Are you accessing FAT filesystems? If so, chances are that codepage 437
was
> used, and that the kernel is trying to access that module to decode the
> filenames. If the module isn't found, you still see the filenames, but
maybe
> there could be some strange characters that the kernel isn't able to
> identify. Compile nls_cp437 as a module and you will be rid of that.
Without
> compiling the module, I don't know how you could get rid of that log
message.
>

But I'm using the iso_88859-15 codepage module to access my Win partition.
And I changed the default codepage to iso_8859-15 in the kernel
configuration. Well, I'll check that again.

> > The second module is unknown to me. What is its purpose? And in case I
> > don't need it, same question as above: how can I get rid of the log
> > message?
>
> - From Documentation/Changes in the 2.4 kernel:
> If you build ppp support as modules, you will need the following in
> your /etc/modules.conf file:
>
> alias char-major-108    ppp_generic
> ...
>
> The kernel is trying to use PPP. Or maybe this was used for some other
thing
> in 2.2 kernels. Anyway, do
> cd /usr/src/linux/Documentation
> grep -r char-major-108 *
> and you should quickly find your info.
>

I'm using PPP because I have a PPPoE connection. I think that I have even
put that alias line in modules.conf. Oh well, I'll check that one again,
too.

>
> > Now, I was thinking about using the 3 runlevels: 3, 4 and 5 to achief
these
> > goals. The only problem is: how can I set the correct runlevel code? Is
> > there a kernel option to set the runlevel or are there other ways to do
> > this?
>
> The way runlevels are handled is in user-space, ie. not in kernel-space.
All
> the scripts for all the runlevels are contained in /etc/init.d. The
symlinks
> in /etc/rc{0123456}.d are what define what each runlevel does. First, the
K
> scripts are run, as "<script> stop", in the order defined by the two
numbers
> next to the K. Then the S scripts are run as "<script> start". You can use
> /etc/init.d/template as a template for new scripts. Just change the
symlinks
> in /etc/rc?.d to define what each runlevel does.
>

I do know the system about those symlinks and the rc directories. But I need
actually something else. I'll try to make it more clear.

My PC boots and Lilo shows up with 4 entries:
1) booting Windows
2) booting LFS to burn CD's
3) booting LFS with network support but no servers
4) booting LFS with network support and servers

When I choose one of the LFS options, Lilo chooses automatically the right
kernel. The kernel of option 3 and 4 are the same kernel, only the kernel
for burning CD's is optimized and has no network support (except loopback).
But at boot up, option 4 requires some daemons to get loaded. I thought that
this could get solved with the runlevels. In that case, something (Lilo,
kernel) needs of course to set or pass through the right runlevel.

So, the question is actually: is there a way to set the runlevel dynamically
instead of statically in inittab?
Or, is there another way to solve my problem?

Andy.

PS: Did me thinking on the quote of Gerard (not sure):
"If Linux doesn't have the solution, you have the wrong problem."
Well, I hope that I don't have the wrong problem :-)


-- 
Unsubscribe: send email to lfs-apps-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message




More information about the blfs-support mailing list