Need to rebuild my kernel *really* from scratch, please help

[xenon]

Ok, all was almost fine, then suddenly my kernel stopped properly compiling, I tried a

[darktux]

You should pust the errors you're getting so that we can help you out properly.
_________________
Lego my ego, and I'll lego your knowledge

www.tuxslare.org - My reborn website

[otulp]

That's a lot of questions...

If you're using the 'gentoo-sources' or any other kernel source that has been patched, performing 'make mrproper' will destroy the source. Well, that is my experience, anyway. It does more than simply deleting '.config' -- it tries to make sure that everything in the kernel source is looking the same way it did when it was unpakced. This means deleting old object files and stuff... But it apparently also means doing Bad Things to the patches.

In short: don't do 'make mrproper' if you are not using a vanlilla kernel. Be happy with 'make clean'

When the kernel is done building it doesn't say anything special, but there is a very notable lack of error messages. Best thing to do if you're in doubt is just to check if the kernel is present in arch/i386/boot/bzImage (assuming you are using a x86 architecture and did 'make bzImage' for a compressed kernel). If it is there - great If not - sure there were no error messages?

And just to be sure - The procedure for kernel compilation is:
1. make menuconfig (or xconfig, config or oldconfig (if upgrading using an old .config))
2. make dep
3. make bzImage
4. make modules
5. make modules_install

...and then comes that business of installing the kernel into the boot partition.

Those problems with /lib/modules/_kernelversion_... If you get a kernel built and installed, with modules, problems originating from that directory should be gone as well, as your new modules installastion ought to have cleaned that directory for you.

...not the one wich contains modules for your previous kernel, though. That one you can safely delete by hand. After you are sure your new kernel works.

Hope this helps. I am not quite sure I really understood what you meant by all you wrote. Also, its getting a bit late for me here. *off to bed with book*

[xenon]

First of all, #darktux: I know it'd help to be able to post the exact errors, but I'm having a hard time detecting all of them. At least, I'm sure that at kernel-compile time, errors start to show while processing the modules that populate the "misc" directory I was talking about before. They are mobo-related modules,chipset support and monitoring, if I'm not wrong.

And then...

I've recompiled the kernel many times in the last days, and at least once I must have screwed it really hard. Something like doing a make mrproper and then compiling without doing menuconfig. I obviously don't remember doing such a dull thing, but the results look compatible. The first error ever was about an unresolved dependency with sis.o, but I definitely never enabled such a chipset support. And then those mobo-monitoring modules - same thing. Please note, though, that the bzImage file gets built correctly. I guess it's all about the modules.
So a make mrproper should completely destroy and reset everything? I should be fine then, I did it at least two times, but... I can't believe I'm making such bad mistakes in menuconfig, while I didn't make them the first time I built the kernel. I don't have a "previous" kernel, my Gentoo box is a week old. I understand those modules should be somehow ignored, but I've read in many places about "stale" .o files that prevent things from working correctly. Could it be the case?

One last thing: I've always used the

[IWBCMAN]

If you have not altered your kernel sources(ie. through editing of .c or .h files) make mrproper returns the kernel source tree to its original state(ie. like it was when you first emerged it)(I don't think mrproper can undo any patches you may have applied, because the original files no longer exist...). All module files and /usr/src/linux/.config are erased. BEFORE USING MAKE MRPROPER BE SURE AND BACK UP YOUR .CONFIG FILE(ie. cp /usr/src/linux/.config /home/user/CONFIG.gentoo-sources.rX)· Make Mrproper is sometimes necessary and eliminates many problems with module errors on bootup-ie. I always uses mrproper....Once you have done a make mrproper you cannot compile the sources without a) running "make oldconfig" against a .config file present in /usr/src/linux or b) by running make menuconfig saving a new .config file.

my procedure looks likes this:

cp /usr/src/linux/.config
/home/****/CONFIG-kernelversionY.ZZZZ

cd /usr/src/linux
make mproper
cp /home/****/CONFIG-kernelversionY.ZZZZ /usr/src/.config

make oldconfig(which sets up all of the header files based on the contents of your .config file)

then

make menuconfig
(changing whatever needs to be changed)

then
make dep clean modules modules_install

then

mount /mnt/boot
cp /usr/src/linux/arch/i386/boot/bzImage /mnt/boot/bzImage-kernelversion-Y.ZZZZ

then
nano -w /mnt/boot/grub/menu.lst
(adding a new entry to the the grub boot loader and/or deleting old entries)

then
umount /mnt/boot

shutdown -hr now

[xenon]

Hmm, no I didn't personally patch or alter the source tree, just took the gentoo one and used it, so I guess make mrproper is kinda overkill for me.
So in my situation, deleting my .config file is more than enough to lose all my menuconfig settings (I know one usually wants to preserve them, not to lose them, but this is a bad case), right?
Last thing I need to know: could deleting stuff (in other words, modules) from "/lib/modules/2.4.20-gentoo-r1" make things even worse?

I would have one more question, but I'll better get a grasp on all this before actually asking it.

[sarnold]

Deleting modules will make them unavailable for loading, whether at boot time or run time. You can put back the last version you compiled by doing "make modules_install" again from /usr/src/linux. But they have to match the kernel version you're running. Also, the above module install will only wipe the previous module tree when it's the same version. You can have different kernel versions installed (at the same time) and their module trees are independent.

[xenon]

I'll definitely reemerge the source and start over, and do things step by step. I think I'm stuck in some kind of "modules-submodules" hell. Gonna try and post the results. Thanks a lot, btw.

[otulp]

Good luck an that fresh kernel source, xenon

Just one thing I want to ask IWBCMAN or sarnold (or someone else browsing this thread): Is my memory of destroying the 'gentoo-source' kernel source code by doing a mrproper sort of ... wrong? I mean, I could be mistaken, I just want to be aboslutely positive.

You know, just curious.

[xenon]

I deleted all the .o files in the already overmentioned directory, and went through the whole process from emerge gentoo-sources to make modules_install. The result is... nothing.
Everything went fine (make bzImage told me about the size at the end), until make modules_install. I mean, I didn't see an error, but the operation ended with an "if.... fi" on the screen, and the above line was like mkdir pcmcia. Should I consider this as positive? I don't think so, since "modules-update" gives a whole bunch of error of unresolved symbols of every kind. Then, trying to reboot, none of the (few) modules I had on autoload works, and if I try to modprobe them, I get a hell of unresolved dependencies again. I'm stuck. I just can't understand how I've been able to screw a decently working system in such a bad way. Any kind of help is of course very welcome, but I guess I'll start considering the idea of restarting from a / format and installing again. Shouldn't I? Is there still a way to save my Gentoo?

[IWBCMAN]

otulp,

make mrpoper simply deletes the contents of /lib/modules/kernel-version and all of the files generated during the build process of your last build and your .config file. mrpoper is not dangerous and does not hurt anything, except of course if you forget to back up your .config file

xenon,

if...fi

sounds good, looks like you succeeded in recompiling your kernel....yes the error messages you are getting about modules are correct- this happens because it is checking your module dependencies while the old built kernel is still running along with its modules and their dependencies...after your next boot it should be fine. As for deleting your .config file, it is far easier to modify an existing .config than it is creating a new one from scratch, and you have to painstakingly go through menuconfig checking every damned option just to make sure you machine will boot the next time-definitely keep your old bzImage on /mnt/boot and put a new line into grub giving you the option of booting from the old kernel, even though your old modules are now gone, unless your filessystem is dependent on modules-you should still be able to boot the system to the command prompt, in case you forgot to turn on, for example, the correct settings for your filesystem in your new kernel

[xenon]

Nah, the only vital function that's modules-based here is my USB mouse. Are you sure that make mrproper deletes all contents from /lib/modules/kernel-version? I'm not questioning your knowledge, but I never really saw that dir empty... Now I'm running Windows (dual booter...), and with a nice tool I can see the right modules are there. So now I will boot Gentoo, ignore all errors and update-modules. If it fails again (I have a feeling it will)... it's formatting time!

Thanks a lot for your help, even if I end up shredding /, I've learned a lot tonight.

[darktux]

[IWBCMAN]

from the /usr/src/linux/Makefile

[otulp]

I just had to test. If it ain't broke, you don't learn anything. darktux is right: mrproper does not delete the /lib/modules/*kernelversion* directory, only modules_install does that.

...and mrproper did not kill my source, as you said it wouldn't, IWBCMAN Guess I was just making things up...

[rac]

Could you post a few of the symbols that are considered unresolved? If nothing necessary to boot your system is compiled as a module, yes you can safely blow away /lib/modules/kernelversion. What I usually do is move it to /lib/modules/kernelversion-jail before I "make modules_install" if I am compiling a kernel that is the same as the running version.
_________________
For every higher wall, there is a taller ladder

[xenon]

I ended up rebuilding the system from scratch, but I really want to thank you all for your support, I learned a lot from this, and need to learn more. Thanks!

Btw... for example, if I compile my kernel with a module, then recompile without that module, does the file itself get deleted in the process? Just "unlinked" somehow? Untouched at all, just not built again?

[bos_mindwarp]

btw, make dep is not needed anymore for development-sources.

[otulp]

The files in /lib/modules/*kernelver* are deleted on 'modules_install', just before the new modules are installed from the kernel source directories.

As far as I can remember, though, unless you did 'clean', 'mrproper' or 'distclean', before the new compilation, the compiled modules from last session are still hanging around in the kernel source somewhere.

If the module you decided to drop in the new compilation was loaded into the kernel at the time you did 'modules_install', no harm is done - it is already loaded into memory, and on next reboot you decided to go without it anyway, so it doesn't matter that it is gone from the disk.

[xenon]

Ok, thanks for the info. All is almost fine here now , just DRI/DRM/OpenGL seem out of reach.

[sarnold]

Just a follow-up on the /lib/modules build stuff. Other than the kernel size and other stuff at the end of 'make bzImage' there is something else to look for.

Although a successful 'make modules' ends with something like "leaving directory foo, nothing to be done for make..." (and no error messages), you should see one more sign of success at the end of 'make modules_install' when it runs the depmod command. This command is run on the just-compiled modules, using the matching kernel's System.map file.

So even if you're running a different kernel config or even a different kernel version, any module version errors you see are real, or else your System.map file was missing (which shouldn't happen, since it's created when you build a kernel).

Some unreslolved symbol errors with driver modules are harmless, unless you actually have the hardware (and the driver isn't seeing it correctly).

For example, in general it's okay to compile things as modules, even if the hardware isn't present (as long as the overall kernel config is okay). Everything in the multimedia config (ie, the v4l and radio card drivers) section compiles and installs fine, except the miropcm radio module. It always has unresolved symbol errors, but I'm not sure if the code is borked, or there's some other kernel config option it needs (and I don't care, since I don't have the hardware).

If you really have a proper (or correct) kernel config, then there should not be any errors at the end of the modules install. Unless it's just a buggy module, in which case I wouldn't use it anyway...

Steve