Building 3.10.x kernel, got warning for certain modules "needs unknown symbol"

slacker_ · 09-05-2013, 05:57 PM

I'm receiving a warning for a few different modules, it's different for each module, but it's only 11 modules, and maybe 70 lines all together. Here's an example for ceph.ko:

Code:

WARNING: /lib/modules/3.10.9/kernel/fs/ceph/ceph.ko needs unknown symbol ceph_get_snap_context

It's a lot of different symbols as they're called and I dunno what any of them are.

ReaperX7 · 09-05-2013, 08:24 PM

It's probably some internal dependency that requires a special module to be loaded. Unless it's an outright error which stops the build process, it's generally safe to ignore.

slacker_ · 09-05-2013, 08:39 PM

Thanks, I'll go ahead and get onto final installation.

Question for you regarding lfs though, from start with bare drive and system, to fully configured installation, about how long did it take you? Just the kernel building and compilation for slack has taken me near 2 days (a day to configure, a day to build).

ReaperX7 · 09-05-2013, 09:51 PM

LFS-7.4_RC2 took me about 3 days to build including installing the following packages to give extra functionality while I now focus on building X.Org:

Lynx
openssl
GPM
dhcp (client)
wget
parted
lvm2

The largest packages you'll deal with are the Kernel (imported Slackware64's kernel config), Perl, glibc, and gcc. Which all of these can take the better part of several hours.

I also HIGHLY recommend that you skip the tests for autoconf and automake as they take a horrendous amount of time to complete and the packages are fairly small.

I also am running this configuration:

AMD Athlon X2 5000B 2.5 GHz
ASUS-HP Narra3 Nvidia nForce 430 Motherboard
BFGTech GeForce 9800 GT O.C. 1GB PCIe x16
ASUS Xonar DX 7.1 DDTS PCIe x1
4GB Dual Channel Kingston DDR2-800 RAM

Having a multi-core system helps with compile times especially if you set the export MAKEOPTS='-j X' flags to 2, 4, or what ever number of CPU cores you actually have. More cores will cut down the compile times significantly.

I also recommend you at least complete Chapter 3 of Beyond Linux from Scratch also to give yourself a true base Linux system to build from.

http://www.linuxfromscratch.org/blfs...fs/config.html

I also highly recommend you avoid a package manager and stick to using the /source directory to version track your system as needed and save your final configurations using only make clean rather than make clear or rm -rf to allow make install and make uninstall have the control of your software with source references.

jon lee · 09-05-2013, 11:32 PM

Reaper, I've tried several times to compile Xorg. The LFS configure is obviously different than Slackware's. I can't get keyboard input to work on my compiled versions and end up having to revert back. I would love to know your ./configure options for it.

And about the kernel, if you continue to have difficulties, you may want to recompile module tools to match your kernel.

ReaperX7 · 09-06-2013, 12:13 AM

It is definitely different than Slackware's compile, but it's very similar. However, you seriously have to have your kernel and system fully prepared for all the drivers you'll need or think you'll need, and make sure and certain that you follow every instruction for X.Org's compile down to the letter, or it'll be useless.

This is why I recommend importing Slackware's kernel-configuration for usage as Patrick is very thorough in what drivers are needed for the majority of workstations, situations, servers, and needs.

I highly recommend if this is your first time installing BLFS and that if you want X.Org, starting from the beginning of Beyond Linux From Scratch and working your way through the book isn't going to hurt. X.Org will require a lot of libraries from the earlier chapters.

Although the BLFS book can read variably, and recommends you install only what you need, if it's your first time, start at the first page and work your way through carefully. Only skip around as you need to resolve dependencies, but make sure you install everything it asks for.

Make sure you at LEAST resolve both the Recommended and Required dependencies of each package. The optional packages aren't going to matter a whole lot, if any, but the recommended and required packages are a must-have.

This may take a few weeks to get everything done, but it's worth it.

Make sure that if you want to get a SVN style dated distribution of LFS/BLFS that you download a copy of both books for that day and work from those books only regardless of which versions are out online and may have been updated.

slacker_ · 09-06-2013, 03:17 AM

Quote:

Originally Posted by ReaperX7

I also highly recommend you avoid a package manager and stick to using the /source directory to version track your system as needed and save your final configurations using only make clean rather than make clear or rm -rf to allow make install and make uninstall have the control of your software with source references.

Isn't it true that not all source installs have a make uninstall? Or is there a workaround that you use?

ReaperX7 · 09-06-2013, 05:23 AM

Yes not all will use the traditional install/uninstall scripts so keep your book as a reference.

colorpurple21859 · 09-06-2013, 09:48 AM

Quote:

I also HIGHLY recommend that you skip the tests for autoconf and automake as they take a horrendous amount of time to complete and the packages are fairly small

Thanks for the info. I've been working on LFS since this past Saturday. I had a rough start Saturday with gcc pass 1 failing on slackware64-current. Then I swapped over to Slackware-14 32 bit as the host and have had no problems since. I'm about half way through chapter 6 with just finishing installing perl last night.

H_TeXMeX_H · 09-06-2013, 09:51 AM

This may be of interest:

Code:

  ┌──────────────── Enable unused/obsolete exported symbols ────────────────┐
  │ CONFIG_UNUSED_SYMBOLS:                                                  │  
  │                                                                         │  
  │ Unused but exported symbols make the kernel needlessly bigger.  For     │  
  │ that reason most of these unused exports will soon be removed.  This    │  
  │ option is provided temporarily to provide a transition period in case   │  
  │ some external kernel module needs one of these symbols anyway. If you   │  
  │ encounter such a case in your module, consider if you are actually      │  
  │ using the right API.  (rationale: since nobody in the kernel is using   │  
  │ this in a module, there is a pretty good chance it's actually the       │  
  │ wrong interface to use).  If you really need the symbol, please send a  │  
  │ mail to the linux kernel mailing list mentioning the symbol and why     │  
  │ you really need it, and what the merge plan to the mainline kernel for  │  
  │ your module is.                                                         │  
  │                                                                         │  
  │ Symbol: UNUSED_SYMBOLS [=y]                                             │  
  │ Type  : boolean                                                         │  
  │ Prompt: Enable unused/obsolete exported symbols                         │  
  │   Defined at lib/Kconfig.debug:73                                       │  
  │   Location:                                                             │  
  │     -> Kernel hacking                                                   │

jon lee · 09-06-2013, 03:04 PM

Speaking of LFS, what I would really like to do is compile sip/PyQt against Python3 and the new Qt-5.1.1 (which has the newer gstreamer-1.0 bindings). I'm not real sure Clementine music player or KDE phonon will work with gstreamer-1.0, but I wouldn't mind testing it anyway. Has anyone tried this yet?

slacker_ · 09-06-2013, 04:13 PM

Quote:

Originally Posted by H_TeXMeX_H

This may be of interest:

Code:

  ┌──────────────── Enable unused/obsolete exported symbols ────────────────┐
  │ CONFIG_UNUSED_SYMBOLS:                                                  │  
  │                                                                         │  
  │ Unused but exported symbols make the kernel needlessly bigger.  For     │  
  │ that reason most of these unused exports will soon be removed.  This    │  
  │ option is provided temporarily to provide a transition period in case   │  
  │ some external kernel module needs one of these symbols anyway. If you   │  
  │ encounter such a case in your module, consider if you are actually      │  
  │ using the right API.  (rationale: since nobody in the kernel is using   │  
  │ this in a module, there is a pretty good chance it's actually the       │  
  │ wrong interface to use).  If you really need the symbol, please send a  │  
  │ mail to the linux kernel mailing list mentioning the symbol and why     │  
  │ you really need it, and what the merge plan to the mainline kernel for  │  
  │ your module is.                                                         │  
  │                                                                         │  
  │ Symbol: UNUSED_SYMBOLS [=y]                                             │  
  │ Type  : boolean                                                         │  
  │ Prompt: Enable unused/obsolete exported symbols                         │  
  │   Defined at lib/Kconfig.debug:73                                       │  
  │   Location:                                                             │  
  │     -> Kernel hacking                                                   │

Awesome explanation, thanks for providing that!