[wplug] Modify SuSE modules

Robert Coutch robert.coutch at verizon.net
Thu Jan 8 21:38:21 EST 2004


You're right.

SuSE keeps some of its settings in specialized files and then pulls data from 
those files when building configuration files.

A good example is if you edit XF86Config by hand and later run Sax2,
you'll lose the changes you made by hand.

You can edit the config files manually and then just avoid using Yast2 and any 
of its modules ( same goes for Sax2 for X configuration).

Yast2 runs a whole bunch of scripts when finishing up and you can see them by 
watching the dialog box.

You could remove the card by using Yast2 and then editing modules.conf and the
network scripts under /etc/sysconfig/network/ .

Just for the record, I use Nvidia's drivers on my system for video and they 
not only work but are recognized by Sax2 during confguration.

It sounds like the drivers added for Nvidia were for a motherboard with the 
Nvidia chipset (audio, video, network).

That sounds like how nvnet got into modules.conf.

You could hand edit modules.conf to remove stuff you don't think should be 
there and if Yast2 is working, try to readd the network card.

SuSE puts a LOT of crap in modules.conf that's usually commented out
making it hard to find duplicate entries.  You might have "alias eth0" in more 
than one place because of the Nvidia scripts.

If your Yast2 is trashed from a bad install, it's an RPM that could be 
reinstalled.  I'm guessing you'll need to do some --force and --nodeps to do 
it since almost everything on the system is tied into Yast2.


Is this helping at all?
If not, I'll just shut up or you could email me a copy of his modules.conf.


-Bob


On Thursday 08 January 2004 08:24 am, Vanco, Don wrote:
> Robert Coutch [robert.coutch at verizon.net] wrote:
> > Just to see what happens..........
> >
> > If the system runs a desktop, fire up Yast2 and see what it shows
> > for network cards installed and configured.
> >
> > Add your card in if it's not there and see if that
> > helps/hurts the situation.
> >
> > Yast2 will handle ALL the config files but I don't know what will
> > happen if you compiled a device into the kernel that it normally
> > loads a module for.
>
> 	The issue is that YaST2 was FUBAR / doing stoopid things (or
> possibly user intervention after install mucked things up for YaST2 /
> module handling)
>
> 	We used YaST2 to set up the NIC - it detects it fine as an Intel Pro
> 100 - so we just """assumed""" that the rest of it was a cakewalk.  Upon
> further investigation (i.e. pressing a few more buttons to look at manual
> config settings) we found that the module YaST2 was calling was "nvnet"
> WeverTF that is....
> 	We resolved this by simply editing the module in the YaST2 screen.
> Sure enough - this made the change in modules.conf.
>
> 	HOWEVER - this explains nothing really - as Jeremey stated in his
> original post, editing modules.conf by hand did NOTHING for him.  So -
> there's some additional "secret sauce" that SuSE relies on.
>
> 	I noted that when we saved changes in YaST2 that it runs of bunch of
> blah blah blah messages when setting the config - but the last this it does
> is run "suse config" - I have to believe that this is where the "secret
> sauce" lives, and that there's more to modules under SuSE than simple flat
> editing modules.conf.
>
> 	As far as the "user intervention" - Jeremey (for reasons as yet
> unknown by me) loaded some nVidia driver that did some scripted crap that
> mucked with modules and / or modules.conf - I noted drivers called out in
> modules.conf like the aforementioned nvnet and also nvaudio, etc.....
> Weird, but NMP.
>
>
> 	I continue to hate SuSE for it's seeming unnecessary complexity and
> it's inability to get the most mundane of hardware working (e.g. ATI Rage
> chipset on an IBM StinkPad).  Unfortunately RH are becoming such @-holes I
> have little doubt I'm going to have to learn to love it.  Blech.  There's
> just no distro to love for me these days - perhaps I need a year in a cave
> to give me some perspective.
>
> Don
>
> > On Wednesday 07 January 2004 10:00 am, Wise, Jeremey wrote:
> >> The issue was that I tried to compile a custom kernel and did the
> >> 'make install' which removed the e100 module reference in
> >> /etc/modules.conf because I compiled it into the kernel. The kernel
> >> had too much stripped out so I canned it. Problem was when I
> >> rebooted to the old one no network. If I did a 'modprobe e100' then
> >> ran /etc/rc.d/network start' the network came up fine. I added 'eth0
> >> e100' back into modules.conf thinking this would allow all to work
> >> again but network still fails at boot. I am still getting use to the
> >> "SuSE way of doing things" and so figured their was another approach
> >> to getting startup dependencies fixed.
> >>
> >> Thx.
> >>
> >> Jeremey Wise (440)-519-6006
> >> Systems Consultant(CNE,MCSE,CSE)
> >> Agilysys, Inc.
> >> Jeremey.Wise at Agilysys.com
> >>
> >> IBM ED PACK -Part # SB033 $4,500 ... SP Discount 11%
> >> IBM ED CARD - Part # SB218 $8,995 ... SP Discount 8.5%
> >>
> >> -----Original Message-----
> >> From: wplug-admin at wplug.org [mailto:wplug-admin at wplug.org] On Behalf
> >> Of Robert Coutch Sent: Tuesday, January 06, 2004 10:22 PM
> >> To: wplug at wplug.org
> >> Subject: Re: [wplug] Modify SuSE modules
> >>
> >> The SuSE way is just like the RedHat way but maybe we could get a
> >> better idea of what you mean, describe the situation.
> >>
> >> What module are you loading for what reason?
> >>
> >> SuSE used to use the rc.local method similar to BSD but has since
> >> changed to the System V type /etc/rc.d/ type init scripts.
> >>
> >> Yast2 will add/modify entries in modules.conf for you so you will
> >> see warning statements in the file where you should not make changes.
> >>
> >> Let us know what you are trying to do.
> >>
> >>
> >> Thanks,
> >>
> >> Bob
> >>
> >> On Tuesday 06 January 2004 05:17 pm, Brian Sammon wrote:
> >>>> Without going into great detail I need to understand 'the SuSE
> >>>> way' of re-enabling a module. In my past RedHat days I would
> >>>> simply vi /etc/modules.conf and all was well. That does not appear
> >>>> to be the way
> >>
> >> to
> >>
> >>>> get the module to initialize at boot now. What am I missing.
> >>>
> >>> Do you want the module to load at boot or do you want it to load
> >>> only when needed.  I don't know "the SuSE way", but based on my
> >>> experience with
> >>
> >> other
> >>
> >>> distributions, I'm pretty sure that /etc/modules.conf is only for
> >>
> >> on-demand
> >>
> >>> module loading by kerneld or kmod.  /etc/modules.conf generally
> >>> works that way regardless of the distribution.
> >>> If you want a module to always load on boot, regardless of whether
> >>> it is needed, then most of the distributions have a way of doing
> >>> that.  It's usually a file like
> >>> /etc/<something>/init.d/module<something>
>
> _______________________________________________
> wplug mailing list
> wplug at wplug.org
> http://www.wplug.org/mailman/listinfo/wplug




More information about the wplug mailing list