Kernel build, what does "#make install" do?

[MickeJ]

Hi, i am a newbee and planning a Gentoo install.

When reading the documentation https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Kernel#Compiling_and_installing. It says

[saturnalia0]

I don't know if Gentoo does anything in particular, but looking at the kernel's Makefile it hints that the install target is handled by /sbin/installkernel:

[pietinger]

MickeJ,

Welcome to Gentoo Forums !

I can confirm that "make install" copies only 3 files to /boot (*): Your kernel, your .config-file and your system.map. With this copy it also adds a version string to them (and do a rename from .config to config; and a rename from bzImage to vmlinuz). AFAIK there is also a hook where you can configure more actions if you want.

Because you asked for efibootmgr ...

I am using UEFI as my bootmanager (no Grub) and I dont need a "make install" anymore; I am just "copying" my kernel to /boot/efi/USEDDIRECTORY/. after building my (new) kernel with (EXAMPLE):

[MickeJ]

Thx!

Greate news. Yepp i want the same, just use my hardware bootloader EFI app (Lenovo) and booting "direct" into a UKI kernel. Just manually copy and run efibootmgr.

I wish the "make install" output used "/usr/lib/kernel/version/" instead of "/boot" Makes no sense to use a "/boot" directory when the vmlinuz file is on another block device. Instead put it on /usr or /var.

[MickeJ]

And also thx for this example as inspiration

/usr/src/linux # sbsign --key /mnt/stick/keys/DB.key --cert /mnt/stick/keys/DB.crt --output /boot/efi/secure/bzImage.efi arch/x86/boot/bzImage

[Hu]

For many many years, /boot has been traditional because it is a special-purpose filesystem, often kept unmounted, that exists solely to hold the early boot environment (kernel, initramfs, bootloader configuration). Putting it on /usr or /var would be unusable on typical encrypted-disk systems.

You can direct make install about where to write by setting INSTALL_PATH in the Make environment. You could also choose to skip make install entirely and manage copying the files through your own script, since there are few files and their names are predictable.

[Goverp]

The default installkernel will maintain symlinks "vmlinuz", etc and "vmlinuz.old" etc. This gives one advantage of having kernels on a modern filesystem (symlinks) rather than the antique floppy disk stuff used for the EFI partition, and means rather whimsically that you don't need to reconfigure GRUB to a new kernel every time you update it (whatever Ubuntu decides to the contrary), but annoyingly can't handle if you use the EFI stub in an EFI partition.

You can easily rewrite installkernel to rename your current kernel to "vmlinuz.old.efi" and copy your new kernel to "vmlinuz.efi", in which case you need just two fixed efibootmgr entries; the downside is you can't tell what versions the current and old kernels are from outside ("file vmlinuz.efi" works fine once Linux is running), and you have only one level of fallback.

(Me, I prefer to keep vmlinuz.new (just installed, testing), vmlinuz, vmlinuz.old (in case I rename .new as current too soon and then find a bug) and vmlinuz-V.R-1.foo if vmlinuz-V.R.bah is current - since the .foo releases are just fix levels, not different releases. So I have a hairy grub.cfg that can handle all of this without needing to reconfigure on a new release).
_________________
Greybeard

[MickeJ]

Ok, thx for feedback. I am educating me before installing because i think the install and daily use is sort of same thing in Gentoo. I think Portage makes it very flexible but with also simple when you have settled down and just want a defined world to be your regular daily driver. I just was curious before i spend time.

I put my Intel cpu firmware and I915 into two initrd located in a separate folder from the kernel in /EFI because they very seldom changes. And i reuse those initrds when booting other distros.
This is approx the efibootmgr i am planning to use. Its ok if manually create this, but long term a automated way would be better ofc. I am thinking about editing the cmake kernel make file, but that is a later issue. Agreed on keeping a old kernel to boot after a update.