Handbook Talk:Parts/Installation/Kernel
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 10:35, 5 November 2024 (UTC) :: Your reply ~~~~
Installing the source
typo in root #emerge --ask sys-kernel
- This is intentional on the Handbook Talk:Parts/Installation/Kernel. In the architecture specific articles it's fixed. (see Handbook:AMD64/Installation/Kernel for an example. --Maffblaster (talk) 20:35, 18 August 2016 (UTC)
Default: Manual configuration
With pciutils emerged you can run
root #lspci -v...
Kernel driver in use: xxxxAt the bottom of the verbose output it will explicitly tell you which Kernel driver is in use.
- Thanks! Using lspci -k works even better. Please do not forget to add a signature when posting on talk pages. :) --Maffblaster (talk) 20:38, 18 August 2016 (UTC)
HID support
The kernel module mentioned in the handbook has changed place and title in the new kernel.
Device Drivers --->
[*] HID support --->
<*> Generic HID drivers
- In case of such changes will you please mention the kernel version as in the older versions it's definitely not changed. --Charles17 (talk) 12:11, 18 March 2016 (UTC)
- I'm not sure when I fixed this, but I must have because the wiki is correct for this option as of kernel version 4.10.10. Closing discussion. --Maffblaster (talk) 22:45, 20 April 2017 (UTC)
EFI stub
In order to boot directly from UEFI, the kernel needs to have CONFIG_EFI_STUB support enabled:
Processor type and features --->
[*] EFI runtime service support
[*] EFI stub support
UEFI does not pass kernel parameters to the kernel during normal boot, so they must be hardcoded them via CONFIG_CMDLINE. to boot a root partition located at /dev/sda2 input the following text in the kernel configuration:
Processor type and features --->
[*] Built-in kernel command line
(root=/dev/sda2)
For GPT systems, using root=PARTUUID= might be preferable. To find out use gdisk:
root #gdisk /dev/sdaCommand (? for help): i Partition number (1-5): 2 Partition unique GUID: (pass the ID that is shown here to the kernel) Command (? for help): q
The partition's UUID is distinct from the filesystem's UUID.
— The preceding unsigned comment was added by AMID EVIL (talk • contribs) March 5, 2016
- If this is ever integrated, I would add a note that it is not preferred because Stub's parameters are not easily modified for debugging/troubleshooting. You would have to rebuild the kernel to add/change any boot parameters. --Grknight (talk) 02:03, 6 March 2016 (UTC)
- I did add support, mainly because I wanted to be sure the kernel section supported EFI booting (see Handbook:AMD64/Installation/Kernel#Architecture_specific_kernel_configuration). Brian Evans (Grknight) , I stand by your suggestion. I do NOT plan on explaining now to boot using a EFI stub kernel. This can be left to others to document in the main namespace. This discussion is complete. --Maffblaster (talk) 22:39, 20 April 2017 (UTC)
Make note about genkernel's disk space usage?
The binaries compiled by genkernel can take a lot of disk space - I was walking a friend through installing Gentoo on a VM, and recommended genkernel as the best method for starting out. Turns out that the compilation took up about 6GB of space in /usr/src/linux, and although they had given the VM enough space for it to complete, I needed to tell them to 'make clean' the compiled genkernel binaries after compilation to get enough space back to continue the installation.
I'd suggest changing paragraph T:60:
Now, compile the kernel sources by running genkernel all. Be aware though, as genkernel compiles a kernel that supports almost all hardware, this compilation will take quite a while to finish!
to:
Now, compile the kernel sources by running genkernel all. Be aware though, as genkernel compiles a kernel that supports almost all hardware, this compilation will take quite a while to finish, and use several times more space than a regular compile - it can easily use up 6GB of space in total, which is not automatically cleaned afterwards!
or words similar to that effect. --Sophira (talk) 21:46, 17 August 2016 (UTC)
- Hi Sophira, it's nice to see that you're helping your friend use Gentoo. What you said it not really accurate, unfortunately genkernel does not support building kernels that support all hardware. It only builds a very vanilla binary kernel with a minimal subsystem support. It does not perform any kind of hardware detection or create a custom kernel configuration file. In response to this common misconception I've included a special paragraph near the front of the genkernel article.
- If anything it would be better to provide to provide a link to the genkernel article and Kernel/Removal. I'll think about what's best to do here. Thanks for the tip! --Maffblaster (talk) 20:32, 18 August 2016 (UTC)
- Hiya Maffblaster! Thanks for the reply.
- I'm a bit confused about why your response directly contradicts the installation guide. Take a look at the page and you'll see that it does actually say "...as genkernel compiles a kernel that supports almost all hardware...". It's probably not really surprising that it's a common misconception if the installation guide is saying exactly that!
- Note that I'm not suggesting that genkernel creates a custom kernel for your configuration. I'm saying that it tries to support all hardware in the same kernel, which is why it takes so long.
- If it doesn't try to support all hardware, as you suggest (or at least all commonly-used hardware), then why does the compilation use up about 4x the space of a regular kernel compile and take much longer? I'm a bit confused.
- I guess it entirely depends on the way you're describing a "regular" kernel compile. If you can define that term, then perhaps we can get to the bottom of this. Generally speaking, compiled kernels definitely consume more space on the disk than just the extracted source. The recent extracted kernel sources decompress to about 775MB which doesn't include any object or binary files (which are generated post-compilation). With that being said, 6GB of space JUST for the kernel compile seems insanely-crazy-massive, even for a kernel compile with every possible option enabled... Are you sure you weren't somehow looking at the full size of everything on the virtual disk? What exact command did you use to calculate directory size? This seems like something was very wrong. :) I compiled v4.10.10-gentoo just now for a test (with the default configuration provided with genkernel) and the resulting /usr/src/linux directory was 1.3GB total.
- Try using the most recent Debian .config file and I'm sure it will take you longer to compile the kernel (lots more modules are enabled). You can do this with genkernel by using the
--kernel-config=/path/to/debian/.config. I'll rewrite some sections of the Handbook in order to make it describe what actually happens when you run genkernel without any--kernel-configoption passed. It will, by default, select a kernel configuration file for the system's architecture out of the /usr/share/genkernel/arch/ directory. I'll also add something near the introduction of the Handbook concerning the use of installing Gentoo in a VM. Generally I use a VirtualBox virtual disk image at the full 2.0 TBs that dynamically expands on writes so I never run into disk space issues. It's a little tricky because everyone has different use cases for their virtual machine disk sizes, so there's not a 'once size fits all' solution on sizes.
- Try using the most recent Debian .config file and I'm sure it will take you longer to compile the kernel (lots more modules are enabled). You can do this with genkernel by using the
- Also, for future reference, you can get very good support in the #gentoo (webchat) channel on Freenode or on the Forums. Kind regards, --Maffblaster (talk) 03:51, 21 April 2017 (UTC)
LVM/RAID
Consider the following sentences:
"In order to enable specific support in the initramfs, such as lvm or raid, add in the appropriate options to genkernel. See genkernel --help for more information. In the next example support is enabed for LVM and software raid (mdadm)"
Both LVM and RAID should be capitalized because they are acronyms.
Fturco (talk) 10:55, 14 May 2017 (UTC)
- Fixed. --Maffblaster (talk) 21:10, 15 May 2017 (UTC)
Installing the sources
This will install the Linux kernel sources in /usr/src/.
An easy way to create the symbolic link is to utilize eselect-kernel. In order to list all installed kernels:
root # eselect kernel listAvailable kernel symlink targets: [1] linux-
In order to create the symbolic link called linux , you can use:
root # eselect kernel set 1root #ls -l /usr/src/linuxlrwxrwxrwx 1 root root 12 Oct 13 11:04 /usr/src/linux -> linux-
— The preceding unsigned comment was added by Mpagano (talk • contribs) 08:21, June 14, 2021
- Hi Mike, I have added the section as suggested above. Thank you for the input. Strange to see that was missing from the Handbooks. --Maffblaster (talk) 17:32, 14 June 2021 (UTC)
- It is not really strange at all since the symlink will initially be created to what is installed without user input. This is really superfluous during install and only really useful when multiple kernels exist. Users normally don't need to set a kernel at this stage. --Grknight (talk) 17:39, 14 June 2021 (UTC)
Add a Genkernel hyperlink
In the T:77 portion
- The kernel is manually configured and built.
- A tool called genkernel is used to automatically build and install the Linux kernel.
- A Distribution Kernel is used to automatically build and install the Linux kernel like any other package.
perhaps change '{{c|genkernel}}' into '[[Genkernel|genkernel]]' for easier reference? Egberts (talk) 16:29, 29 September 2022 (UTC)
- Reasonable enough! Special:Diff/1185460/1185462. --Maffblaster (talk) 08:11, 19 February 2023 (UTC)
Post-install/upgrade tasks reword
This section could be explained better to prevent users running into issues with nvidia drivers for example. I find this happens quite often while offering support to new users.
This was discussed with Sam on IRC and was told in #gentoo-wiki "<+sam_> in the case of dist-kernel it is unusual to not want it globally" I believe this change makes this more clear that it is the recommended way to use a dist-kernel.
Existing text
Distribution kernels are capable of rebuilding kernel modules installed by other packages. linux-mod-r1.eclass provides the dist-kernel USE flag which controls a subslot dependency on virtual/dist-kernel.
Enabling this USE flag on packages like sys-fs/zfs and sys-fs/zfs-kmod allows them to automatically be rebuilt against a newly updated kernel and, if applicable, will re-generate the initramfs accordingly.
Proposed change
Distribution kernels are capable of rebuilding kernel modules installed by other packages. Portage provides a hook with dist-kernel USE flag which is part of linux-mod-r1.eclass and controls a subslot dependency on virtual/dist-kernel.
This USE flag should be applied globally if using a distribution kernel inside /etc/portage/make.conf. Doing so will allow packages such as sys-fs/zfs and x11-drivers/nvidia-drivers to automatically be rebuilt against a newly updated kernel and, if applicable, will re-generate the initramfs accordingly.
— The preceding unsigned comment was added by Immolo (talk • contribs) 2023-12-22T11:14:53
- Fixed in Special:Diff/1283969/1298140, thanks!
- --csfore (talk) 18:20, 11 May 2024 (UTC)
Drop genkernel
It's clear that genkernel is no longer in a good place from discussions on IRC. I would like to propose discussion of dropping it from the handbook as it is causing new users more issues than it solves with the current way it is worded which makes it sound like it does a better job then it was designed for it.
What the change will improve
- A better user experience for new Gentoo users
- Genkernel users can still use it if they wish by following Genkernel
- Less time wasted fixing ongoing genkernel issues by support people and devs
Areas of concern
- dist kernel does not currently support all arches
The last point does concern me the most and is something I'm working on in the background to fix however that is a way off before it is ready to be merged. A good middle ground might be we only remove it from handbooks which have full dist kernel support or we improve the manual compiling section to teach using make localmodconfig as a tool to help users compile their own kernel.
Please add your ideas below so we can start looking into fixing this longstanding issue.
Immolo (talk) 16:12, 5 April 2024 (UTC)
- Genkernel's been dropped down to the last option in preparation in Special:Diff/1290140/1297070, thanks!
- --csfore (talk) 22:45, 6 May 2024 (UTC)
- Are there plans to drop it entirely? Or should this discussion be closed?
- — Waldo Lemmer 14:21, 11 May 2024 (UTC)
- Thanks to everyone that helped make this happen! <3
- 21:24, 16 September 2024 (UTC)
Add Framebuffer section
Tip: To get this fixed sooner, use {{Proposal}}.
As highlighted by User:pietinger the handbook does not currently show users how to set up a framebuffer leaving a user stuck at a "Loading Linux" message. This proposal will give a user a basic working config while showing how they can configure for their own hardware at the same time.
To display output to the screen, the kernel requires framebuffer support. Below is an example of getting working generic support on nearly all machines. Users may instead enable support for their own graphics card, though it is recommended to have a fallback in the event that something goes wrong.
Device Drivers --->
Graphics Support --->
[*] Simple framebuffer driver
[*] Frame buffer Devices --->
[*] VESA VGA graphics support
[*] EFI-based Framebuffer Support
Immolo (talk) 15:01, 13 May 2024 (UTC)
- I think this fits in with everything in Handbook:Parts/Installation/Kernel#Enabling support for typical system components. It should not be its own section.
- I have edited it to propose my own changes.
- — Waldo Lemmer 15:19, 13 May 2024 (UTC)
- As already mentioned in IRC I would not suggest to enable [*] Simple framebuffer driver (make more problems than it solves).
- Pietinger 15:45, 14 May 2024 (UTC)
Hostonly be default
Tip: To get this fixed sooner, use {{Proposal}}.
Based on the discussion in #gentoo-wiki moving Gentoo to setting hostonly.
One such benefit to this is it reduces the ram required to boot by around 35MB which can be very helpful on older systems.
root #emerge --ask sys-kernel/installkernelhostonly
Hostonly is an option for dracut which tells it to only include firmware, drivers and modules that this specific system requires to boot. This can be rather useful as it both reduces the size of the initramfs and can speed up loading times. This option is disabled by default, but for most use cases it is highly recommended to enable it. When hostonly is disabled, local configuration files in /etc are not included in the initramfs, this may lead to strange behavioural discrepancies between the initramfs and the rootfs. For example, if custom options for some kernel module are specified in /etc/modprobe.d/ and this kernel module is loaded from the initramfs then these custom options will not be effective if Dracut's hostonly setting is disabled.
Related to the hostonly option, there is also the hostonly_mode setting which defaults to sloppy. To instruct Dracut to optimize more aggressively this option can de set to strict. Furthermore, if hostonly mode is enabled, then the hostonly_cmdline option is also automatically enabled. This option embeds a command line for the kernel in the initramfs containing the parameters required to find and mount the rootfs. If this is not desired then this behaviour can be disabled again by setting hostonly_cmdline="no".
For example:
/etc/dracut.conf.d/hostonly.confhostonly="yes"
hostonly_mode="strict"
hostonly_cmdline="no"
This will instruct Dracut to apply these settings every time Dracut is called either manually or via sys-kernel/installkernel.
Improvements are welcome until this is ready for merging into the handbook.