Handbook Talk:Parts/Installation/Kernel

From Gentoo Wiki
Jump to:navigation Jump to:search

Installing the source

Talk status
This discussion is done.

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

Talk status
This discussion is done.

With pciutils emerged you can run

root #lspci -v
...
    Kernel driver in use: xxxx

At 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

Talk status
This discussion is done as of April 20, 2017.

The kernel module mentioned in the handbook has changed place and title in the new kernel.

KERNEL Activating USB Support for input devices
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)
Version 4.4.4, the version that is automatically pulled if you do a clean install now. --Switch87 (talk) 12:27, 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

Talk status
This discussion is done as of April 20, 2017.

In order to boot directly from UEFI, the kernel needs to have CONFIG_EFI_STUB support enabled:

KERNEL Enable EFI stub support
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:

KERNEL Enable built-in kernel parameters
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/sda
Command (? 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
Note
The partition's UUID is distinct from the filesystem's UUID.

— The preceding unsigned comment was added by AMID EVIL (talkcontribs) 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?

Talk status
This discussion is done as of May 15, 2017.

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.
Thanks. --Sophira (talk) 21:09, 18 August 2016 (UTC)
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-config option 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.
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

Talk status
This discussion is done as of 2017-05-15.

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

Talk status
This discussion is done as of June 14, 2021.

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 list
Available kernel symlink targets:
  [1]   linux-

In order to create the symbolic link called linux , you can use:

root # eselect kernel set 1
root #ls -l /usr/src/linux
lrwxrwxrwx    1 root   root    12 Oct 13 11:04 /usr/src/linux -> linux-

— The preceding unsigned comment was added by Mpagano (talkcontribs) 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

Talk status
This discussion is done as of 2023-02-19.

In the T:77 portion

  1. The kernel is manually configured and built.
  2. A tool called genkernel is used to automatically build and install the Linux kernel.
  3. 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

Talk status
This discussion is still ongoing as of 2023-12-22.

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 (talkcontribs) 2023-12-22T11:14:53‎