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
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.
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?
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.
(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.
(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.
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.
(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
*** Bug 188089 has been marked as a duplicate of this bug. ***
*** Bug 196916 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
(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.
'CLOSED WONTFIX' should be obvious for everyone.
> > 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
