Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I am having a problem that seems to occur sporadically, where I have a custom kernel I build from a tarball I downloaded off kernel.org, 2.6.33.2. It boots smoothly, I have the initrd generated for it, and when I try to install the nvidia driver v256.53 & v260.19.12 it errors. I have gotten it to compile with the same kernel and same configuration before, so I think I missing some piece of software. The error I get is "the source tree is not clean, run make mrproper". When I do that I get an error message saying version.h is missing, the kernel is not configured. SO then I clean the source tree, copy a backup of version.h into the tree, and then I get an error saying the kernel source cannot be found. Every time I have gotten it to build has been right after I built the kernel and not cleaned out the source tree. What am I missing?
I finally got it to work. What I did was backed up the .config file, ran make mrproper, copied .config back into the source tree, ran make prepare then make modules, then I ran the nvidia installer and it worked without a hitch.
You are using some strange commands to build a kernel. There are many files that
come with the Linux kernel source. README in particular is one that you need to
read before going further. With your 2.6.33.2 version kernel you DO NOT run
"make prepare" or "make modules". Where did you even get those ideas? There is
no "make prepare" command and the modules are built with "make".
After unpacking your new kernel source, or patching your old source, you run as
a normal user "make <some_option>config". After configuring the kernel, save
the file, then you run only "make" and "make modules_install" -- and that last
command only if you have configured anything as a module (M) in the kernel.
IF, and that is one big IF, you only did what you wrote in your last post, then
it is a miracle IF you installed the Nvidia driver with a new kernel; because
what you report defies all logic.
Actually, there is *some* logic to what the OP was doing in posts #1 and #3, but between those two posts, the sequence of operations was pretty much all out of whack. As Bruce says, it sort of defies logic, it's something of a fluke that the driver build worked in the end.
Bruce: there is a `make prepare` function with the kernel, all it does is check/refresh/whatever the version files for the kernel (version.h and utsrelease.h) and runs a script called `checksyscalls.sh`. Some old sketchy out-of-tree drivers (like modem drivers) used to suggest running `make prepare` if one was having trouble building the driver due to missing the version.h file. I haven't needed the `make prepare` command in a long time.
To clarify my previous post, "there is no 'make prepare' command listed in the
kernel source README file." It is called by "make" from Makefile when someone
has fubared their config ... which is what he had done.
My point was there is a proper way to build a kernel, and the OP forsook it in
favor of some other method.
If we had actually seen the logs from his fubar, and his kernel source directory,
and his nVidia driver version and kernel version no doubt we would have a little
better idea of the true picture ... but it's miraculously [SOLVED].
As I like to say, "All's well that ends!"
However, one day he might like to build another custom kernel ...
yes, I'm happy that it's solved, but you're right, OP will want to get the command sequence sorted out or else will have difficulties of this nature again.
I'm sorry for the confusion I created, what I did was for installing the nvidia kernel module only, to build my kernal I unpack it in /usr/src/linux, run make xconfig to configure it, then execute make;make install;make modules;make modules_install. Then I boot the new kernel, run geninitrd and reboot again. After that process is when I would run the NVIDIA installer, and sometimes it would work just fine, and others I would run into the errors I described in my initial post. If you would like I can recreate those errors and post the subsequent logs for your perusal.
Now I am certain of your problem. Since my first computer build in 1984
I have seen this problem many, many times. You have failed to read the
instructions and follow them ...
Quote:
Originally Posted by brenainn
what I did was for installing the nvidia kernel module only
If you build a new kernel, to reinstall the Nvidia kernel module:
Code:
mingdao@jeremiah ~ $ man nvidia-installer
<snip>
ADVANCED OPTIONS
<snip>
-K, --kernel-module-only
Install a kernel module only, and do not uninstall the existing driver. This is intended to be used to install kernel modules for
additional kernels (in cases where you might boot between several different kernels). To use this option, you must already have a
driver installed, and the version of the installed driver must match the version of this kernel module.
With a new kernel this is the command to issue to re-install the Nvidia module:
Code:
sh /home/mingdao/configs/NVIDIA-Linux-x86_64-256.53.run -K
I have used it for years, and will testify that It Just Works (TM).
Quote:
Originally Posted by brenainn
to build my kernal I unpack it in /usr/src/linux, run make xconfig to configure it, then execute make;make install;make modules;make modules_install. Then I boot the new kernel, run geninitrd and reboot again.
From the kernel source README file:
Code:
mingdao@jeremiah ~ $ less kernel/linux-2.6.33.2/README <- NB: the kernel build directory under /home
Linux kernel release 2.6.xx <http://kernel.org/>
These are the release notes for Linux version 2.6. Read them carefully,
as they tell you what this is all about, explain how to install the
kernel, and what to do if something goes wrong.
<snip>
INSTALLING the kernel source:
- If you install the full sources, put the kernel tarball in a
directory where you have permissions (eg. your home directory) and
unpack it:
gzip -cd linux-2.6.XX.tar.gz | tar xvf -
or
bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf -
Replace "XX" with the version number of the latest kernel.
Do NOT use the /usr/src/linux area! This area has a (usually
incomplete) set of kernel headers that are used by the library header
files. They should match the library, and not get messed up by
whatever the kernel-du-jour happens to be.
<snip>
CONFIGURING the kernel:
Do not skip this step even if you are only upgrading one minor
version. New configuration options are added in each release, and
odd problems will turn up if the configuration files are not set up
as expected. If you want to carry your existing configuration to a
new version with minimal work, use "make oldconfig", which will
only ask you for the answers to new questions.
- Alternate configuration commands are:
"make config" Plain text interface.
"make menuconfig" Text based color menus, radiolists & dialogs.
"make xconfig" X windows (Qt) based configuration tool.
<snip>
COMPILING the kernel:
- Make sure you have at least gcc 3.2 available.
For more information, refer to Documentation/Changes.
Please note that you can still run a.out user programs with this kernel.
- Do a "make" to create a compressed kernel image. It is also
possible to do "make install" if you have lilo installed to suit the
kernel makefiles, but you may want to check your particular lilo setup first.
To do the actual install you have to be root, but none of the normal
build should require that. Don't take the name of root in vain.
- If you configured any of the parts of the kernel as `modules', you
will also have to do "make modules_install".
<snip>
- Keep a backup kernel handy in case something goes wrong. This is
especially true for the development releases, since each new release
contains new code which has not been debugged. Make sure you keep a
backup of the modules corresponding to that kernel, as well. If you
are installing a new kernel with the same version number as your
working kernel, make a backup of your modules directory before you
do a "make modules_install".
Alternatively, before compiling, use the kernel config option
"LOCALVERSION" to append a unique suffix to the regular kernel version.
LOCALVERSION can be set in the "General Setup" menu.
- In order to boot your new kernel, you'll need to copy the kernel
image (e.g. .../linux/arch/i386/boot/bzImage after compilation)
to the place where your regular bootable kernel is found.
<snip>
If you boot Linux from the hard drive, chances are you use LILO which
uses the kernel image as specified in the file /etc/lilo.conf. The
kernel image file is usually /vmlinuz, /boot/vmlinuz, /bzImage or
/boot/bzImage. To use the new kernel, save a copy of the old image
and copy the new image over the old one. Then, you MUST RERUN LILO
to update the loading map!! If you don't, you won't be able to boot
the new kernel image.
Reinstalling LILO is usually a matter of running /sbin/lilo.
You may wish to edit /etc/lilo.conf to specify an entry for your
old kernel image (say, /vmlinux.old) in case the new one does not
work. See the LILO docs for more information.
After reinstalling LILO, you should be all set. Shutdown the system,
reboot, and enjoy!
There is no longer a "make modules" step -- that is done by the "make" command.
I think we read in the paragraph that begins with:
Do NOT use the /usr/src/linux area!
where you destroyed your headers and created your initial problem.
The kernel README file does not mention an initial ramdisk image. Your "geninitrd"
must obviously stand for "generate initrd", which would mean generate initial ramdisk.
If your / filesystem, or the disk controller that your / filesystem mounts on are built
as modules (M) in your kernel, then you will need an initrd. There are a few other esoteric
options where you would need an initrd. If brenainn requires an initrd, then you must issue
"geninitrd" BEFORE you reboot with the new kernel. If you don't, how will the kernel
have an initrd, and how will it boot if it requires an initrd? Either in your case it does
not require an initrd, or you won't boot the new kernel.
I tried to read about PLD and geninitrd at the PLD website, but their page for English
documentation does not load. The FAQ does not seem to have anything related to a
kernel rebuild. The only other English kernel documentation on the site was out of date.
I don't read or think in Polish so can't help further with that issue.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.