Upgraded kernel - Can't mount USB thumbdrive
 

I have upgraded my kernel to 2.6.23.8 and since doing so my USB thumbdrive is not assigned a /dev location. I see that it is recognized when I plug it in but that's it.
I have also noticed that my udev rules have also stopped working. I used the same config file from the previous kernel (2.6.21.5) so I don't think that's a problem, but maybe.

Any ideas?

I will begin by telling you I am not a guru. However, I have compiled a few kernels. As a matter of fact, I am getting ready to upgrade the kernel in one of my machines to 2.6.23.8.

My first question would be did you do a "make oldconfig"? The 2.6.23.x kernels have numerous new features that your original kernel does not. If you didn't use "make oldconfig", your .config file isn't right.

I have noticed that the 2.6.23.x kernels are a little flaky. I have one machine that I upgraded to 2.6.23.1 without a problem. Two others had nothing but problems because of 2.6.23.x's initial problem with ndiswrapper. I am actually going to see if that problem has gone away, which is why I am in the process of upgrading one of the trouble machines.

EDIT: Update...Alas, the 2.6.23.x kernels remain unstable as far as wireless networking is concerned. I guess I'll go up to 2.6.22.14 on that machine. No biggie.

Blessed be!
Pappy

When upgrading to a new version of kernel, I have always put my previous .config file into the new source directory and run make menuconfig. Doing it that way, all the previous settings are maintained and new features end the line with [NEW], so it is then easy to consider how to deal with any of the new kernel features as well as ones which are 'deprecated'.

Bill.

I compiled my kernel exactly the way Toods explained. I know that sometimes that can cause problems like the one pappy_mcfae mentioned but I hoped that since they're still in the 2.6 series, that wouldn't happen.
I _may_ try doing it using oldconfig but probably not. I don't really need the newer kernel and the time I had available to do a couple upgrades got eaten up with all of this!
Thanks for the replies. Any further help is also appreciated.

More important than make oldconfig is make mrproper.. did you do that ?

make oldconfig / make menuconfig shouldn't make MUCH of a difference, but you could have missed something necessary in the new config... could you just run make oldconfig anyways ?

Yes, I always run 'make mrproper', but for a brand new kernel, it's not necessary. Where in the kernel configuration would something like this be? I mean, what could I have missing that would cause (what seems to be) udev from working properly? I think I mentioned earlier that even my custom udev rules stop working with the new kernel.

Did you do make oldconfig too ? from your old .config?

the kernel is a dark and dreary place .... better off doing make oldconfig first ..

Having never upgraded to the latest and greatest kernel source without doing a make oldconfig, I really can't speak to how well not doing so may work. I can say that the document I used to learn how to configure and compile a custom kernel recommended the use of make oldconfig. Considering the times I have upgraded my kernel, and the successes I have had, I think that whoever wrote that article knew what he was writing.

The steps were:
1) make mrproper
2) make oldconfig (if upgrading and using your old .config file.
3) make xconfig (or gconfig or menuconfig, whichever you prefer for tweaking)
4) make
5) make modules
6) make modules_install

I have been doing it this way since I first tried my hand at it. The only problems I have ever had was when there was a problem with the kernel source and the way it interacted with my machines (such as 2.6.23.x and wireless network stability).

As duryodhan says, "the kernel is a dark and dreary place .... better off doing make oldconfig first .." I couldn't agree more.

Blessed be!
Pappy

Well, I have compiled many, many kernels but never that way. What I always did was:
make mrproper
make menuconfig
make
make modules_install
make install
I have never had problems but I am going to start using your method instead. Seems like a better way!
Thanks for the suggestions.

*sigh*

Okay, instead of just reciting a recipe without explanation, here's what the commands you need to know about actually do and when you should use them. I won't beggar off with some poncey disclaimer, I'll say flat out I've been doing this for over a decade so you can print this out if you like--these instructions will be correct.


Pre-Configuration Stage

make mrproper - This attempts to revert the source tree to a pristine by deleting all stale object files, all configuration data, and anything resembling backup files it finds in the tree. On general principle, many people run this the moment they untar a new kernel source, just to be certain nothing hinky came along with it (and this is not a bad thing). Note that if you run this command, it will blow away whatever configuration you were working on. (...and yes, it's pronounced "Mister Proper")

make clean - This is similar to make mrproper but less aggressive. It will delete stale object files, but leave the configuration intact. If, after you've compiled (and installed) your new kernel and modules, you want to free up a little disk space but still want to be able to do things like say, build the nVidia binary drivers, you can run this--your configuration will stay intact.

Note: If you are modifying a kernel configuration in an already-built tree in a manner that adds or removes from the core (non-modular) part of the kernel, or that changes an option from being in the core kernel to being a module, or vice-versa, you must run one of the two commands above (preferably `make clean`) to eliminate the stale object files or the kernel and modules you get will likely not be sane and will very likely misbehave horribly.

Configuration Stage

make config - Pretty much the oldest configuration tool there is. It will ask you about every single option and whether you want it or not, one at a time, seemingly endlessly. If you answer something wrong once you get to start over at the beginning. Primarily only of interest to hardcore masochists.

make menuconfig/xconfig/gconfig - Much more user-friendly configuration tool. "menuconfig" uses an ncurses (text-based) configurator, "xconfig" uses a Qt-based configurator, and "gconfig" uses a GTK+-based configurator. All of these present the exact same information, just with a different face on it. These generate the /usr/src/linux/.config kernel configuration file in a way that is supposed to always result in a compilable kernel.

Note: Manually tampering with the .config file can result in a file that is missing options that need to be set, or containing options that should no longer be set and can muck things up--meaning your build could fail at some point with a very cryptic error, if you're lucky.

make oldconfig - If you already have a configuration file and would like to apply it to an existing source tree, first clean up the source tree with make clean, copy your configuration file to the root of the kernel source tree as ".config", and issue this command. Your screen will scroll madly as the make config configurator is called and fed all the existing options from your .config file.

make silentoldconfig - This is similar to make oldconfig but less spammy on your screen. This makes it very handy for people configuring over a laggy ssh connection.

Note: The two options above are very useful for upgrading between reasonably similar kernels (for example, 2.6.20 to 2.6.22.3) because they will both stop when an option is reached that requires a decision to be made. Usually these options are new features in the kernel, and you can generally assume that if the existing kernel you are trying to recycle was working for you then you can simply hit 'm' to set the new code to be built as a module without having to worry too much about it.

Compiling Stage

make all - With the 2.6.x kernels, this is pretty much the "do it all" command. Gone is the need to type `make dep` or any of that other stuff. Like any good Makefile would provide, make all will cause everything you'd reasonably want to be compiled to be compiled, including both the kernel and it's modules. If you'd like to know what specifically is going on, type `make help | less` and all the targets that 'all' invokes will be listed with an asterisk next to them.

make - Running make with no target mentioned is synonymous with running make all. Use either one you like.

make vmlinux - This compiles the core kernel and only the kernel.

make modules - This compiles just the modules and not the kernel (parts or all of which may actually get compiled anyway if it's needed to build the modules). If you used make menuconfig to alter your kernel configuration and only added new modules that were not on at all before and everything else is already built, you can simply run make modules and it will quickly figure out which new module wasn't built yet, build it, and you can move on to the final stage rather quickly.


Installation Stage

make bzImage - Not really an installation target, per se, but close enough since there's not really an option to "just" install the kernel. This will give you a compressed kernel image as arch/i386/boot/bzImage that you can then copy to wherever you want.

make modules_install - This will blow away the entire contents of the /lib/modules/`uname -r` directory (/lib/modules/2.6.22.2-smp for example) and then install all the modules in there.

make headers_install - This is a command you do not run, ever. The only people who should ever run this are people who build distributions from the ground up who just rebuilt glibc. People reading quick HOWTOs on building a kernel are categorically not such people. Doing this will screw your machine up.

make install - Running this command will likely not do what you want. Without special preparation, this is just going to lob the System.map and kernel into somewhere which is probably not the place you want them to be. If you have done this "special preparation" then this will install both your kernel and the modules in one step. The "special preparation" I mention is that the kernel Makefile looks for a script called 'installkernel' in either ~/bin or /sbin (whichever it finds first) and runs that to install your kernel and re-run lilo. Such a script has been written and can be downloaded from here which you can chmod executable, copy to your /sbin directory and use immediately. It will copy the kernel, the System.map file, and a copy of your config to /boot using symlinks exactly as Pat does so everything stays nice and tidy. It's code is blisteringly simple to avoid any confusion about what it's doing. Your new kernel will be stored as /boot/vmlinuz-x.y.z with a symlink pointing to it from /boot/vmlinuz and so on.


Don't forget that if you didn't use `make install` you will likely need to edit your /etc/lilo.conf to point at wherever your new kernel is, and run lilo again to update the bootloader. Usually I make the default kernel image for lilo be the symlink of /boot/vmlinuz, and the second item explicitly /boot/vmlinuz-2.6.whatever. After awhile if the new kernel works properly I go back and update the explicitly-named image to point at the new kernel as well. If you are rebuilding the exact same version of the kernel as you did before, feel free to change the $EXTRAVERSION setting slightly, which is the first item under General Setup. This will be reflected in the final filenames and avoid accidentally overwriting a build you intended to keep while fine-tuning things.


Overview

Now that we've covered all that, you can pretty much go from the top to the bottom of this list, and things should more or less make sense. Each of the four stages should be performed in order, and I can't stress enough how useful it is to enable (not as a module, you want <*>) "Kernel .config support" and "Enable access to .config through /proc/config.gz" are under General Setup. If you do this, and you want to upgrade at some future point, you don't have to guess which iteration of the kernel you might be running... You can type `zcat /proc/config.gz > .config` and it will dump the configuration for the kernel you are using right then into place, ready to be absorbed with make oldconfig. Considering how unbelievably important it is to build your kernel and your modules with the same configuration, this can be a lifesaver if you need a new module some months down the road and don't have a copy of the configuration you used previously.

The last hint really worth mentioning is that if you have a SMP machine (either dual-CPU, dual-core, or hyper-threaded--if /proc/cpuinfo believes you have multiple CPUs you do for this purpose) you can use the -j switch to speed things up a bit. Simply specify the number of CPUs you have (plus or minus one at the most, there is a point of diminishing returns you quickly reach using say, -j9 when you only have two cores) like `make -j2 all` when you build and things will go much faster as make will spawn two children at once when building instead of just one (the default).

(Yes, this is all from a document I already had written, although it was a bitch to reformat it to use bbcode--and no, I don't do initrds.)

evilDagmar,

Just a quick note of thanks for posting your Makefile target explanations, I have been compiling kernels myself for a while and still found it helpful, especially the clarification on make oldconfig and make install. I should be using oldconfig and never really made good use of make install.

JW

Thanks for a great explanation. Several questions:

1) Why make clean is required when you change only the core of the kernel?


2) What's the difference between those two?

That is an excellent write-up. Thanks for taking the time to do it. I will definitely reference it every time I attempt to build a custom kernel, as will many other people I'm sure.

imho, this could be stickied cause a lot of people just run commands, without really knowing what they actually do

Yes, that particular post should be copied over to its own thread and stickied.