Knoppix v3.4 kernel 2.6.6 - files get overwritten ?

[Cuddles]

First, the background:

Knoppix v3.4, with kernel 2.6.6 - which was re-compiled from source to include NVidia video drivers...

Hard drive installed, using knoppix-installer, Debian Style...

After finally getting i2c and lmsensors working, I added the required additions to /etc/modutils for the alias line, and then went to putting the two required "modprobe" lines into /etc/modules file...

After rebooting, I did a lsmod, and was surprised to find my i2c-isa and via686a not in the listing... So, I manually did the modprobe lines again, did a lsmod, and found them in the list...

This is the strange thing, I went into /etc/modules to make sure I entered my two modprobed modules lines correctly, and found that they WEREN'T there... So, I put them back in the file, saved it, exited the editor, and even did a "cat" on the file to ensure the changes were "actually" made to the file, which they were - and then did another reboot...

It appears that since v3.4 of Knoppix has the two kernel version, something is "copying" configuration files to the disk during boot - and the /etc/modules file is one of those... Because after I rebooted again, again, the /etc/modules file was replaced with a version that did not have my changes in them...

I only boot the kernel 2.6, and I don't think I will ever boot the 2.4 kernel - how can I release Knoppix from always overwritting my config files when I boot??? ( this is getting nerve-racking ) - sometimes you need to change some config files to get devices, or in this case, a feature of the motherboard, working, and you can't if the durn OS keeps copying an outdated file on top of the updated one....

Thanks for any assistance,
Ms. Cuddles

[baldyeti]

I think that in order to allow botting either from a 2.4.x or 2.6.x kernel, knoppix keeps two release-specific copies of some key config files, then picks the correct one at boot time. Try "ls -al /etc/modul*''; I wouldn't be surprised if you saw several modules files. Too lazy to check the specifics, sorry.

[eco2geek]

It appears that since v3.4 of Knoppix has the two kernel version, something is "copying" configuration files to the disk during boot - and the /etc/modules file is one of those... Because after I rebooted again, again, the /etc/modules file was replaced with a version that did not have my changes in them...

If you take a close look during the bootup process, shortly after Knoppix gives you the "Welcome to KNOPPIX HD-installation!" message (use your scroll lock key to halt the process and the "any" key to resume ), you might see lines like this:

Found hardware profile in /etc/modules-2.6.5.
Copying hardware profile to /etc/modules.

So try making your changes to /etc/modules-2.6.5 and they should "stick."

That whole "alias" business in /etc/modutils is kind of a mystery to me. If you know of a site that explains it, please post.

[Cuddles]

No problem BaldYeti...

I did check, myself, and it appears the "bigest", and only one, is the "modules" file, I think they did that because the two kernels would have two seperate needs, and requirements, for certain modules to be fired off -=- but, its still a pain in the rump...

Eco2Geek, you got it... I had seen the message go by on the screen, but, by the time I could "see" it, it would just fly off the top of the screen... All I knew was "config found [something]"... ( and it doesn't show up in the dmesg output - so, my question is, if things don't show up in the dmesg output, should I still be looking in that? Or, is something else a better place to find these messages from??? )

I found the /etc/modules-2.6.6 file, noticed it was identical to the /etc/modules file - so I removed my /etc/init.d/bootmisc.sh entries that should have been in modules, and placed my modules that needed to be modprobed into the /etc/modules-2.6.6 file, and rebooted - it worked flawlessly... So, for future referance, I modified the modules-2.6.6 file to state that with kernel 2.6.6 in Knoppix v3.4 - that you should not make changes in the /etc/modules file, but rather, in the /etc/modules-2.6.6 file - that way this problem doesn't happen again, when I need to make a module change...

Thanks again to both of you, never thought to look for a "...-2.6.6" file for the resolve... I don't touch files I have no clue about ( learned that from years of being in Windows support )

Eco2Geek, as for the "alias ..." lines in /etc/modules.conf, and in the files that are used to build that file, in /etc/modutils/* -=- I haven't a clue how they work, why, what they do, I just know that for some things, you got to have them - like alsa, and my i2c / lmsensors stuff... I found an entry for "alias" in the "man modules.conf" -=- I guess it makes "some" sense:

       alias alias_name result
              The "alias" directive  can  be  used  to  give  alias  names  to
              modules.  A line in /etc/modules.conf that looks like this:

                alias iso9660 isofs

              makes it possible to write modprobe iso9660 although there is no
              object file for such a module available.
              Note that the line:

                alias some_module off

              will make modprobe ignore requests to load that module.  Another
              special alias is:

                alias some_module null

              which  will make requests for some_module always succeed, but no
              module will actually be installed.  This can be used as  a  base
              for stacks created via the above and below directives.

              It  is  possible  to  have  a  large  number  of levels of alias
              directives, since all aliases will be  recursively  expanded  in
              order  to  find the physical module actually referred to.  There
              is an arbitrary limit of 1000 on alias  depth  to  detect  loops
              like:

                alias a b
                alias b a

              If  the final result of an alias mapping does not match the name
              of any module then modprobe applies probe and probeall  mappings
              to  the  result.  If those do not succeed then the module is not
              found.  This makes constructs like this  give  sensible  results
              (from devfs).

                alias           /dev/sg*        /dev/sg
                probeall        /dev/sg         scsi-hosts sg

              It  is  legal  for  an alias to map module A to module B and for
              module A to exist  at  the  same  time  but  this  construct  is
              ambiguous  and  is not recommended.  For historical reasons, the
              kernel sound system has a module called sound.o  but  the  sound
              developers  also  want an alias from sound to the module for the
              user's sound card, e.g.  "alias sound sb".   In  an  attempt  to
              support this requirement but still maintain the defined behavior
              where options can be applied to aliases, modprobe bypasses alias
              expansion when processing a module name if the name was obtained
              via modules.dep, otherwise aliases are expanded.   This  is  not
              guaranteed  to give the expected behavior on all combinations of
              aliases and real modules, you should avoid using an  alias  with
              the same name as a real module.

Ms. Cuddles

[j.drake]

I really wish they'd cut this double-kernel nonsense out. It invites error, and you shouldn't have to be putting up with this rewriting on a Debian-style install anyway. Hopefully, when they release the next version, they'll standardize on the most recent kernel. After all, if Fabian's remastering utility is half as good as he claims, those who really want a different (older) kernel can either use an older version of Knoppix or adapt the new one. My theory is that the complexity of the double-kernel directories are largely responsible for the large number of posts about problems with detecting and configuring wlan cards.

I feel kind of bad that you're having so many troubles, since I recommended changing to 3.4/2.6 to you. Hope you're at least having some fun poking under the hood.

jd

[Cuddles]

j.drake,

If you did suggest me going to v3.4, I don't hold you responsible... ( but, I think I had the idea already. It was getting hard to support Knoppix, from a "previous" release. )

Anyway, about the only problems, really, were ALSA, NVidia, i2c and Lm_Sensors, and getting my "old" files into the "new" version - I think I fared well, actually... I think I'm ready for the next version to come out now - just so, I can do it all over again ( sarcasim at extreme level here ).

But, I do agree with this whole Dual-kernel issue --=-- its getting to be a real pain... I don't use the 2.4, I don't plan on it, I don't want it, but, I still have it, "lurking" to muck up anytime it decides. My guess is, I can blow away all the 2.6.6 specific stuff, copy it to a "normal" boot naming convention, get rid of the LILO 2.4, and the boots for it, and just run "standard" 2.6.6, as it should be... ( my guess ) i.e. delete the -2.6.6 modules file, delete the 2.4 boot files, rename the 2.6.6 boot files to linux files, then "copy" them to 2.6.6 files ( for a backup kernel boot ), change LILO to just Linux and 2.6.6 backup - and I think the kernel "dual" issue will be gone ( ??? )

Just my thoughts,
Ms. Cuddles