Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 183346 - Building kernel: Why not make && make modules_install && make install ?
Summary: Building kernel: Why not make && make modules_install && make install ?
Status: VERIFIED WONTFIX
Alias: None
Product: [OLD] Docs on www.gentoo.org
Classification: Unclassified
Component: Installation Handbook (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Docs Team
URL:
Whiteboard:
Keywords:
: 188089 196916 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-06-26 23:41 UTC by Kevin Worth
Modified: 2009-01-11 14:08 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Worth 2007-06-26 23:41:33 UTC
I always followed the guide's advice of copying arch/i386/boot/bzImage to /boot, blah blah blah, but then one day, just to see if it worked, I typed "make install" and to my surprise it nicely copied my new kernel to /boot, created a "vmlinuz" symlink (along with config and System.map), and moved the existing ones to vmlinux.old (config.old, System.map.old, etc)... That way my GRUB entry can just point to "vmlinuz" and I never have to mess with it again. 

This is super-convenient for people new to Gentoo/linux and it is the method I always use now... why not include it in the handbook?

Reproducible: Always

Steps to Reproduce:
1.cd /usr/src/linux
2.make install


Actual Results:  
symlinks and copies of kernel, config, etc in /boot
Comment 1 nm (RETIRED) gentoo-dev 2007-06-27 00:14:18 UTC
Because make install doesn't work right on all architectures ... it might not always have the desired behavior.

I discussed this with the GDP some time ago when I was updating the handbooks for 2007.0, but the answer was no.
Comment 2 Jan Kundrát (RETIRED) gentoo-dev 2007-06-27 00:22:13 UTC
Kernel, do you want us to recommend using `make install` for installing kernel image? Is it supported on all our arches? Does it still copy unneeded files like System.map?
Comment 3 Jan Kundrát (RETIRED) gentoo-dev 2007-06-27 00:23:19 UTC
Josh, I've read through all docs-team bugs mentioning `make install` and actually there were no clear reasons. I'd prefer out kernel people to have a look at those.
Comment 4 nm (RETIRED) gentoo-dev 2007-06-27 00:30:26 UTC
(In reply to comment #3)
> Josh, I've read through all docs-team bugs mentioning `make install` and
> actually there were no clear reasons. I'd prefer out kernel people to have a
> look at those.
> 

I never said it was on a bug. Go back and re-read our gentoo-doc ML:

http://thread.gmane.org/gmane.linux.gentoo.documentation/2660/focus=2667

This thread is when I mentioned doing it, and there were enough responses from devs who are familiar with it to decide against doing it. There shouldn't be any need to reopen the bug, since it's already been talked about and voted against.
Comment 5 Jan Kundrát (RETIRED) gentoo-dev 2007-06-27 00:38:48 UTC
(In reply to comment #4)
> I never said it was on a bug.

I never said you did :), we were handling this bug at the same time, I vaguelly remembered some chat about this topic and tried to locate it on bugzilla.

> Go back and re-read our gentoo-doc ML:

Yup, I remember that now, thanks for a link. My memory sucks. Sorry for noise, closing back.
Comment 6 Daniel Drake (RETIRED) gentoo-dev 2007-06-27 01:44:58 UTC
Another point for the record: "make install" depends on debianutils, or at least acts different when debianutils is present. debianutils breaking in the past has hassled our users.
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2007-06-27 07:15:49 UTC
(In reply to comment #6)
> Another point for the record: "make install" depends on debianutils, or at
> least acts different when debianutils is present. debianutils breaking in the
> past has hassled our users.

A recent example: Bug 177576
Comment 8 Jan Kundrát (RETIRED) gentoo-dev 2007-08-08 12:00:56 UTC
*** Bug 188089 has been marked as a duplicate of this bug. ***
Comment 9 Jan Kundrát (RETIRED) gentoo-dev 2007-10-24 17:59:36 UTC
*** Bug 196916 has been marked as a duplicate of this bug. ***
Comment 10 Tamas Szabo 2009-01-02 05:51:51 UTC
I just wanted to add the same bug, but I found that it already has been added a few times, so I just list my points below:

- make install backs up the previous kernel image to vmlinuz.old and copies the new image to vmlinuz. It keeps your previous image for safety and you don't have to edit grub.conf (if you follow the convention) when upgrading kernels. Very elegant and user-friendly IMHO.

- problems caused by people forgetting to mount their /boot partition come up all the time on #gentoo. A lot of time could be saved if a Gentoo specific /sbin/installkernel could make a sanity check before installing the kernel and warning the user if they have a /boot partition but it isn't mounted.

- make install shouldn't depend on debianutils. make install uses /sbin/installkernel to allow distributions to provide a distribution specific way of installing the kernel. If Gentoo had it's own installkernel script the all the arguments against debianutils installkernel (doesn't work on all architectures, debianutils breaks etc.) can be solved by Gentoo devs and wouldn't be a problem anymore.


 

Comment 11 Nicolas Sebrecht 2009-01-05 09:43:23 UTC
(In reply to comment #10)
> I just wanted to add the same bug, but I found that it already has been added a
> few times,

Good !

> so I just list my points below:
> 
> - make install backs up the previous kernel image to vmlinuz.old and copies the
> new image to vmlinuz. It keeps your previous image for safety and you don't
> have to edit grub.conf (if you follow the convention) when upgrading kernels.
> Very elegant and user-friendly IMHO.

Not that much. Playing with vmlinuz is not safe. This file is not the whole kernel which has to do with the modules (and initramfs sometimes).
The safe way to upgrade your kernel is to set the CONFIG_LOCALVERSION option at compilation time.
From my point of view, the vmlinuz symlink hack sounds poor as it could leave the user with a non-bootable system.

> - problems caused by people forgetting to mount their /boot partition come up
> all the time on #gentoo. A lot of time could be saved if a Gentoo specific
> /sbin/installkernel could make a sanity check before installing the kernel and
> warning the user if they have a /boot partition but it isn't mounted.

Note that this feature already exists and is part of the genkernel package.
Comment 12 Tamas Szabo 2009-01-06 14:05:30 UTC
 (In reply to comment #11)
> > 
> > - make install backs up the previous kernel image to vmlinuz.old and copies the
> > new image to vmlinuz. It keeps your previous image for safety and you don't
> > have to edit grub.conf (if you follow the convention) when upgrading kernels.
> > Very elegant and user-friendly IMHO.
> 
> Not that much. Playing with vmlinuz is not safe. This file is not the whole
> kernel which has to do with the modules (and initramfs sometimes).
> The safe way to upgrade your kernel is to set the CONFIG_LOCALVERSION option at
> compilation time.

I might be missing your point here, but according to my knowledge setting CONFIG_LOCALVERSION will save you from overwrite your previous modules when you do make modules_install.
That is irrelevant here because we aren't discussing the installation of modules (which should stay the same) we are discussing replacing the part that recommends copying the kernel image with cp over make install.  
Setting CONFIG_LOCALVERSION is a safer way to update your kernel, but it can be used both if you copy your image manually or you use make install.

> From my point of view, the vmlinuz symlink hack sounds poor as it could leave
> the user with a non-bootable system.

I don't think that is true. Not anymore than copying the image file manually.

> > - problems caused by people forgetting to mount their /boot partition come up
> > all the time on #gentoo. A lot of time could be saved if a Gentoo specific
> > /sbin/installkernel could make a sanity check before installing the kernel and
> > warning the user if they have a /boot partition but it isn't mounted.
> 
> Note that this feature already exists and is part of the genkernel package.

Yes, but the problem occurs for people doing manual kernel configuration.
If the feature already exists than it would be even easier to use the same code for the manual kernel installation as well.

My point is that not mounting the /boot partition when installing the kernel happens a lot. 
If you do the installation of the kernel image as the handbook recommends it by a plain cp command, you can't add code that does sanity checks because you can't extend the cp command. If you use a Gentoo specific script instead of the cp command and recommend users do make install that uses that script, the script can contain more higher level stuff. You can add sanity checks, Gentoo specific stuff etc. Even if you started with the plain copy in the script you'll have the chance to extend the script anytime in the future without affecting the handbook.

Comment 13 Nicolas Sebrecht 2009-01-10 09:50:34 UTC
(In reply to comment #12)

> I might be missing your point here, but according to my knowledge setting
> CONFIG_LOCALVERSION will save you from overwrite your previous modules when you
> do make modules_install.

And it saves the user from having a system un-bootable because of having a vmlinuz symlink pointing to a broken kernel image. The manual says :
"cp arch/i386/boot/bzImage /boot/kernel-2.6.24-gentoo-r5". It's better because it uses a fully named kernel image.
If your last kernel image is broken, then you'll be able to boot with the previous kernel. Play with symlink doesn't prevent from this issue. 

> Setting CONFIG_LOCALVERSION is a safer way to update your kernel, but it can be
> used both if you copy your image manually or you use make install.

Yes, and it should be used for both.

> I don't think that is true. Not anymore than copying the image file manually.

Keep the compiling/installing/booting process in mind. The symlink hack encourages bad practices as you could have your only bootloader entry to fall into a broken kernel image.

> Yes, but the problem occurs for people doing manual kernel configuration.
> If the feature already exists than it would be even easier to use the same code
> for the manual kernel installation as well.

What you are saying here is that you would like to have features already integrated in the genkernel tool into the manual installation process. I see a huge contradictory here. The manual process is designed to do let you do the job in a *manual* way.

> My point is that not mounting the /boot partition when installing the kernel
> happens a lot. 

A manual installation assumes that you know what you are doing and that you are able to easily fix theses kinds of stuff.

> If you do the installation of the kernel image as the handbook recommends it by
> a plain cp command, you can't add code that does sanity checks because you
> can't extend the cp command. If you use a Gentoo specific script instead of the
> cp command and recommend users do make install that uses that script, the
> script can contain more higher level stuff. You can add sanity checks, Gentoo
> specific stuff etc. Even if you started with the plain copy in the script
> you'll have the chance to extend the script anytime in the future without
> affecting the handbook.

You can improve your "manual" installation process by writing your own scripts.

But please, don't ask to add some software crap on what should be manual.
Comment 14 Xavier Neys (RETIRED) gentoo-dev 2009-01-10 09:57:35 UTC
'CLOSED WONTFIX' should be obvious for everyone.
Comment 15 Tamas Szabo 2009-01-11 14:08:41 UTC
> > I don't think that is true. Not anymore than copying the image file manually.
> 
> Keep the compiling/installing/booting process in mind. The symlink hack
> encourages bad practices as you could have your only bootloader entry to fall
> into a broken kernel image.

You assume that make install it creates just one symlink, but that isn't the case. 
The script saves your previous kernel under vmlinuz.old and then it updates the vmlinuz link to the new kernel.
So, you don't have just one bootloader entry you will have 2 (at least, you could have more of course). One for the current kernel (pointing to vmlinuz) and one to the previous kernel (vmlinuz.old).
The only reason you have the links for is that it saves you from manually update your bootloader configuration every time you update the kernel.

> > Yes, but the problem occurs for people doing manual kernel configuration.
> > If the feature already exists than it would be even easier to use the same code
> > for the manual kernel installation as well.
> 
> What you are saying here is that you would like to have features already
> integrated in the genkernel tool into the manual installation process. I see a
> huge contradictory here. The manual process is designed to do let you do the
> job in a *manual* way.

I don't see that contradiction to be that huge. 
The manual process is it mainly about manual configuration not manual installation. There are obvious reasons why someone chooses to configure their own kernel manually to tune it to their system instead of using a generic kernel. On the other hand I don't see what is the big advantage of manually installing the image instead of using make install as it is recommended by the kernel documentation. BTW, why do you recommend using make modules_install, why not copy the modules manually?

> > My point is that not mounting the /boot partition when installing the kernel
> > happens a lot. 
> 
> A manual installation assumes that you know what you are doing and that you are
> able to easily fix theses kinds of stuff.

Yes, the usual "user-centric" argument :-).
I believe in trying to solve problems if you see them reoccurring many times.
I made a suggestion on how I think it could be solved. 
Apparently you don't think that it is a problem at all or you don't care enough to fix it ... I hope it is the former. 
Maybe you could at least add a note to the handbook and the kernel configuration guide warning the user to make sure that /boot is mounted if it is a different partition before copying the image.

Anyways, I don't think this is going anywhere... I just wanted to reply to some of the parts of the discussions that were still "open".

Take Care

Tamas