Handbook Talk:Parts/Installation/Kernel
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)