[Sussex] On the Other hand

Steve Dobson SDobson at manh.com
Mon Nov 18 18:13:01 UTC 2002


Nik

On 11/18/2002 Nik Butler wrote:
> Well it cant last can it... 

Not on a cosmic time scale - and everything else runs to fast for me; I'm
not the speed junky that Geoff is ;-)

> After sucessfully rebuiling sickpuppy and bringin it upto date ive hit a
> wall with dselect ( q'uell suprise eh ! ) 

I didn't think there was anyone out there still using dselect; aptitude is 
the replacement.  It'll take a bit of getting use to but....

>                                            ive gone and selected and
> munged up the options . This has resulted in dselect prompting to remove
> stuff I dont want it to as part of a install. Of course ive gone well
> past the point of simply copy status-old over status and what I really
> want to do is tell Dselect to look at my current configuration and
> forget attempting to install any new items. effectively allowing me to
> select install and not be prompted to remove/add/update every item. Any
> one got any ideas.

Personally (as a Debian user) I don't use aptitude/dselect because I've
found that I can use apt-get to do all the work for me.

To find a new feature:
  $ apt-cache search <keyword>

To find out more about a package
  $ apt-cache show <package-name> ...

To install a new package
  # apt-get install <package-name> ...
If there are any packages that need to be installed/upgraded that were
not on the command line the installation reports and waits for user
acceptance.

I've looked at aptitude but I find the above simpler to use.

> Any while we are at it, how the hell have I brain deaded my kernel
> compile resulting in continous unresolved symbols in every module ....
> theres the Eponamous One thing ive missed and damned if I can remember
> what it is ! 

I've seen things like this myself.  I have managed to track them back to
debug symbols that don't appear in the kernel.  Try the following:
  $ grep <missing-symbol-name> /proc/ksyms
     Example: $ grep console_print /proc/ksyms
              c0117544 console_print_Rv714a981
If the grep reports nothing than you KNOW that that symbol is missing 
from your running kernel.

First question: When changing configuration have you moved some driver
from module to kernel?  Have you configured out some modules?  If the
answer to either of these questions is "Yes" then I recommend doing a
fresh kernel build [$ make clean && make dep && make bzImage && make
modules].  Then purge the old modules from the system [# rm -rf
/lib/modules/<kernel-version>] and then install your new kernel.
[# cp arch/i386/boot/bzImage /boot/bzImage; lilo; make modules_install]
This may work, but it doesn't always.

If you still have problems then it is because one of your flag is including
a symbol definition in a header file that isn't been defined in the
kernel itself.  Tracking these down is a little bit more complex.

First find the header file that defines the symbol [$ find . -name \*.h |
xargs grep <symbol_name>].  Then view the file and find the name after the
#ifdef that pulls in that definition.  That name maps to the config option.
Finally you can remove that config from your kernel config set, rebuild
and install has above.

Hope this helps

Steve




More information about the Sussex mailing list