A few mistakes ...
|
| Author | Content |
|---|---|
| jesperjuhl Apr 14, 2006 5:04 AM EDT |
You are perpetuating some (long) outdated things in your article.
I'll describe the mistakes below and quote Linus's own words on these things from an email he posted on LKML back in the year 2000 - http://uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html - I suggest you read the entire email as well, it's a good one :-) 1) You tell people to configure and build the kernel as root. That is not the proper way to do it and has not been for years. The proper way is to configure and build the kernel as a normal user. You need to be root only to install the kernel and modules, but that's a different thing. 2) You tell people that they should build their kernels in /usr/src/linux . That's about as wrong a location to pick for that task as you can possibly choose. The recommended location is somewhere in your regular user homedir. 3) It's nice of you to tell people about "zcat /proc/config.gz > /usr/src/linux/.config", but you should probably also mention that whenever you base a new config on an existing config file you should always run "make oldconfig" as the very first thing after putting a .config file in place. "make oldconfig" will read the .config, make sure it matches the current source and prompt the user for selections if any options have changed - even if your old .config is from the same kernel version you are recommended to still run "make oldconfig" after copying it to the source tree. Here's a blockquote from Linus's email on these things : " I would suggest that people who compile new kernels should: - NOT do so in /usr/src. Leave whatever kernel (probably only the header files) that the distribution came with there, but don't touch it. - compile the kernel in their own home directory, as their very own selves. No need to be root to compile the kernel. You need to be root to _install_ the kernel, but that's different. - not have a single symbolic link in sight (except the one that the kernel build itself sets up, namely the "linux/include/asm" symlink that is only used for the internal kernel compile itself) And yes, this is what I do. My /usr/src/linux still has the old 2.2.13 header files, even though I haven't run a 2.2.13 kernel in a _loong_ time. But those headers were what glibc was compiled against, so those headers are what matches the library object files. And this is actually what has been the suggested environment for at least the last five years. I don't know why the symlink business keeps on living on, like a bad zombie. Pretty much every distribution still has that broken symlink, and people still remember that the linux sources should go into "/usr/src/linux" even though that hasn't been true in a _loong_ time. Is there some documentation file that I've not updated and that people are slavishly following outdated information in? I don't read the documentation myself, so I'd never notice ;) " Note that he says "... this is actually what has been the suggested environment for at least the last five years ..." and that email was written more than 5 years ago, so as of now that has been the way for more than 10 years (and it's also what's described in various files in Documentation/ with any halfway recent kernel source, if you read them). |
| zebul666 Apr 14, 2006 10:30 AM EDT |
i tried to do what you say some time ago.
decompress the src of the kernel in one directory in my $HOME but what i dislike is the link /lib/modules/$(uname -r)/build which points to where the src are ... and in my $HOME when you install the kernel i revert back to the use of /usr/src/linux ... |
| hkwint Apr 14, 2006 3:27 PM EDT |
JesperJuhl: Thanks for the comments. I didn't know about that. The way I told it just works for me, and it's the way it's in the Gentoo Docs http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=... If I emerge a kernel, it goes to /usr/src, NOT to my home_dir. To be honest, I don't care that much about it. Nonetheless, I believe there are reasons to put it in /home, but it is just easier to do it the old way. Can you give me some useful reasons to do it in your home_dir? Furthermore, when compiling the closed nvidia drivers (graphics / nvnet / nvsound) they rely on /usr/src/linux as far as I know. About the "make oldconfig": I forgot that part. Don't forget: This article was meant as a Linux kernel review, NOT as a "kernel compiling HOWTO". Some people may find it useful as a HOWTO, though they should look at the documentation their distro's provide. Looking at what Linus told, the Gentoo docs are outdated. I believe, if compiling as root in /usr/src/linux really was that bad, the distro's already would have changed it, so I don't think it gives big problems. This article however explains how most users can _view_ their kernel configuration. |
| grouch Apr 16, 2006 1:44 AM EDT |
NVidia relies on the symlink /lib/modules/$(uname -r)/build to find the source. |
| jesperjuhl Apr 16, 2006 1:59 AM EDT |
To hkwint: "The way I told it just works for me, and it's the way it's in the Gentoo Docs" Those docs seem to be outdated. "Can you give me some useful reasons to do it in your home_dir?" Well, for one there are the file permissions. If you extract the kernel source as root (as you would tend to do if you are using /usr/src/ , since on most dists that dir has perms like this "drwxr-xr-x 3 root root 4096 1993-11-24 21:33 src") then you'll get a kernel source tree with world writable files due to the way the tarballs are made : -rw-rw-rw- 1 root root 18693 2006-03-20 06:53 COPYING On the other hand, if you extract the source tarball as a normal user (in which case doing so somewhere in your homedir is the logical location), then you get files with more sane perms : -rw-r--r-- 1 juhl users 18693 2006-03-20 06:53 COPYING ofcourse you could just manually chmod the files after extraction as root, but I doubt very many people will do that, and as a consequence they will have a source tree that everyone can muck around with - that's a nice and easy way to crack a system, modify the kernel source to install a backdoor, then wait for the admin to build and install the new vulnerable kernel - instant root privileges to ordinary users - whoops! You don't even need to wait for a vulnerable kernel to actually be installed. Since you can write to any of the files and the admin will likely run 'make' as root, then you have plenty of oppotunity to write a Makefile that will grant your user root privs and then continue building the kernel as normal. So all you really need is for the admin to run "make clean" , "make menuconfig" or "make" or whatever. Another good reason to do it in your homedir as a normal user is that $PATH is usually setup differently for root and ordinary users. On some distributions, not all the tools needed to build a kernel are in root's PATH while they are in ordinary users PATH's (granted, this is rare, but I've come across it a few times over the years). "Furthermore, when compiling the closed nvidia drivers (graphics / nvnet / nvsound) they rely on /usr/src/linux" Wrong, the nvidia drivers rely on the /lib/modules/$(uname -r)/source symlink to find the kernel source for the currently running kernel. On my box that link looks like this : $ ls -l /lib/modules/$(uname -r)/source lrwxrwxrwx 1 root root 47 2006-04-09 14:41 /lib/modules/2.6.17-rc1-mm2/source -> /home/juhl/download/kernel/linux-2.6.17-rc1-mm2/ So the nvidia drivers (that need to be installed as root and thus won't have any problems reading files in the oridnary user juhl's homedir) won't have any trouble whatsoever. "Don't forget: This article was meant as a Linux kernel review, NOT as a "kernel compiling HOWTO"." I realize that, but that still doesn't mean that the article shouldn't strive to be accurate and should not provide outdated info. "This article however explains how most users can _view_ their kernel configuration" Wrong. The articles instructions assume everyone has root access to the machine they work on, that's a flawed assumption. Obviously the largest set of users is those with access to a regular user account - everyone who has root access also has access to a regular user account or can easily create one. Those who don't have root access only have access to a regular user account. So by giving instructions in the article that require root, you limit the usefulness of the article to those who have root access and leave those who don't out in the cold. Had the article given instructions that could have been followed by a regular user, then both those with and those without root access could have followed the instructions to view a kernel configuration (obviously only those with root access could view the current configuration stored in /proc/config.gz, but more people would be able to view *a* configuration, even if only the default one). |
| hkwint Apr 16, 2006 2:26 PM EDT |
Grouch and JesperJuhl: Ok, thanks very much for your comments, I really learned something. I will send people to this discussion for a better way to do things, since I'd say changing the article all over after this amount of time isn't fair. Update: I changed the cd command to Quoting: cd /lib/modules/$(uname -r)/source Maybe I'll post a bug on the Gentoo docs. Some last notes: Gentoo portage fixes the permissions BTW, and my root user has a more elaborate PATH then the normal user. Furthermore, it doesn't sound right to me that kernel files, which I consider as system files, should go to the /home directory, which I consider as all my 'private', 'not needed for system maintenance and update' files. What I learned is that a lot (maybe even most) of kernel info on the net is outdated, since you are the first person telling me to not do it in /usr/src (ALL articles I read tell you you most likely will find it there), so obviously there is something wrong somewhere. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!