General ('newbie') Install Question: Drivers

[milktoast]

I'm trying to get as deep an understanding as I can so I can eventually be a power user like you folks.

So manuallly setting up the Kernel is a big deal (at least for someone like me). Is it important that I find all the drivers the first time through? Is the Kernel updated with every driver install?

Driver installation is of course automated on other platforms, and it is to some extent on funtoo as well (there are packages for different graphics cards). Is that last statement the key to my answer?  That the Kernel does need to be updated every time but that it's done with the install script?

And if it is updated, what does that entail? (everything seems so intimately connected going through this the first several time; the kernel bone's connected to the bios/uefi grub... bone etc.) Would it just be updating the kernel "file" thing that comes out of compilation, replacing the old one where it sits?

[iamthepieman]

 

Kernel Emerge

The sys-kernel/gentoo-sources package is the vanilla kernel with the Gentoo patchset applied. Choose between kernel sources. The sys-kernel/linux-firmware package contains binary blobs needed for some hardware (wlan cards).

If sys-kernel/gentoo-sources has been selected:

root #emerge -av sys-kernel/gentoo-sources sys-kernel/linux-firmware

root #cd /usr/src/linux

Configure Manual

Discover which modules are required for the system's hardware:

root #lspci -nnk

Configure kernel by enabling each necessary module in the menuconfig interface. Search for specific module names by pressing / in menuconfig. Navigate to the associated feature by pressing the corresponding number listed on the left of the search results.

root #make menuconfig

Once finished build kernel and modules:

root #make -j2

Automatic

If things are working nicely in the current install environment, it is possible to use localyesconfig to select all modules currently loaded by the LiveCD:

root #make localyesconfig

Build the kernel and modules:

root #make -j2

Install

Install the kernel and modules:

root #make modules_install

root #make install

Bootloader

Specify the correct setting for the system's firmware. BIOS/MBR is pc, UEFI on x86_64 is efi-64, UEFI on x86 is efi-32:

FILE /etc/portage/make.confx86 PC BIOS settings for GRUB2

GRUB_PLATFORMS="pc"

FILE /etc/portage/make.confx86_64 UEFI settings for GRUB2

GRUB_PLATFORMS="efi-64"

Emerge GRUB2:

root #emerge --ask sys-boot/grub

Supposing the system has PC BIOS:

root #grub2-install /dev/sda

Supposing the system has UEFI firmware:

root #grub2-install --target=x86_64-efi /dev/sda

Edit GRUB2's configuration file:

root #nano /boot/grub/grub.cfg

Below is a simple GRUB2 configuration file:

FILE /boot/grub/grub.cfgExample manual config

set default=0

set timeout=1

 

menuentry "Gentoo" {

linux (hd0,1)/vmlinuz-3.14.4-gentoo root=/dev/sda3 rootfstype=ext4 net.ifnames=0 quiet ro

}

Alternatively use the grub2-mkconfig command to generate the configuration file::

root #grub2-mkconfig -o /boot/grub/grub.cfg

Found vmlinuz-3.14.4-gentoo

Network tools

Install tools needed for configuring the network interfaces:

root #emerge --ask sys-apps/iproute2 net-misc/dhcpcd net-wireless/wireless-tools net-wireless/iw net-wireless/wpa_supplicant

Clean up

Exit chroot, unmount partitions, and reboot:

root #exit

root #cd /mnt

root #umount -R gentoo

root #reboot

See also

• Gentoo Handbook

 

[funfool]

If you follow the install guide, you will get a binary kernel that should work for you as is, out of the box.

Now that kernel gives you a working booting system, you can in your free time, build a custom kernel.

You can have as many kernels, as you have room for on your hard drive.

So keep your working kernel, and if your new kernel does not turn out so well, you can boot the old working kernel and try again.

Just not the end of the world, if you do not get it right the first time.

[milktoast]

I'm not someone who hasn't read the handbook. I also have several other books, that say "don't worry about installing every module now, just the essential...because they can be installed later". In fact I've installed a custom kernel, so i won't be reverting to anything simpler any time soon.

What I'm asking for is a generic yet accurate explaination of what happens when a module (driver) is installed later on (Your musings, far less taxing than an overly technical hurdle).

Is it "registered with the kernel" somehow? is the entire kernel recompiled each time? is there an intermediate program that handles new modules "mod[something something]" Is it a standard or non-standard way of dealing with modules?

What are the essential (abstract?--though I doubt I'd ever consider accurate summation abstract... the crux of my burden in life) elements of the addition of a module to a system?

[Tassie_Tux]

Like you I also use a custom kernel together with the following external kernel modules delivered via portage:
sys-kernel/spl
sys-fs/zfs-kmod
sys-fs/vhba
x11-drivers/nvidia-drivers

 

When one of these packages is emerged - for the first time or for an update - the module is (as I understand) being built to work with the currently installed kernel. I have never seen portage request that the kernel is rebuilt.

 

Now if I update my kernel I do need to re-emerge these kernel module ebuilds to work against the newer kernel. I find the easiest way to do this is to issue this command

emerge -av @module-rebuild

[j-g-]

I'm not someone who hasn't read the handbook. I also have several other books, that say "don't worry about installing every module now, just the essential...because they can be installed later". In fact I've installed a custom kernel, so i won't be reverting to anything simpler any time soon.

 

What I'm asking for is a generic yet accurate explaination of what happens when a module (driver) is installed later on (Your musings, far less taxing than an overly technical hurdle).

 

Is it "registered with the kernel" somehow? is the entire kernel recompiled each time? is there an intermediate program that handles new modules "mod[something something]" Is it a standard or non-standard way of dealing with modules?

 

What are the essential (abstract?--though I doubt I'd ever consider accurate summation abstract... the crux of my burden in life) elements of the addition of a module to a system?

 

If you plan to start fiddling with a custom kernel I recomend  you a conscious read of the help of the Makefiles of the kernel

$ cd /usr/src/linux
$ make help

I'm not trying to say you can't read helps, but the kernel help is a fairly large one, and one should take some time to read all those options.

 

On the topic of getting the driver, you should know what filesystem you will use and enable those, but a way that can get you on a .config that doesn't need you to go disabling and enabling every single thing, would be:

boot with the standard kernel

# make defconfig or olddefconfig  using /proc/config.gz (You read about thouse)
then 
# make localmodconfig 
      -- to disable the modules not loaded this may disable some that also might be needed or have changed name in newer versions
# make menuconfig
      -- to select filesystem, security, cpu and further fine-tuning.
( Using '/' is a quick way to navigate trough the kernel you can put kernel module names or CONFIG names, and '?' will give plenty of info)

If you want to reuse your newly custom config for specific hardware and quickly try it on a new version

 

One way of doing it is to make a backup of the .config everytime you upgrade or modify your kernel, and then place it in a kernel source dir  to upgrade it to the newer version using

 make olddefconfig

 make  && make install ...

Another good practice is to start building as user your kernel, and only installing it as root.

[uudruid74]

I'm not someone who hasn't read the handbook. I also have several other books, that say "don't worry about installing every module now, just the essential...because they can be installed later". In fact I've installed a custom kernel, so i won't be reverting to anything simpler any time soon.

What I'm asking for is a generic yet accurate explaination of what happens when a module (driver) is installed later on (Your musings, far less taxing than an overly technical hurdle).

Is it "registered with the kernel" somehow? is the entire kernel recompiled each time? is there an intermediate program that handles new modules "mod[something something]" Is it a standard or non-standard way of dealing with modules?

What are the essential (abstract?--though I doubt I'd ever consider accurate summation abstract... the crux of my burden in life) elements of the addition of a module to a system?

In general, you wont be adding kernel level drivers. You can go into the kernel source and do a make menuconfig, select some additional modules and then do a make modules and make modules_install. This wont build modules that are already built or the kernel. However, most people just build all the modules they might need and don't mess with it anymore.

 

When it comes to binary video drivers, they are built against the existing kernel sources so that they can build a module

If you update your kernel, you will need to update those modules at the same time or you lose your GUI. I don't recommend using proprietary binary video drivers.

 

Its actually possible to load modules built for one kernel version into a different one, but its so error prone and kinda pointless since the source for them all is right there. Much safer to rebuild the modules with the kernel.

 

Technical (not totally accurate, but here's the simple version): the modules are placed in a /lib/modules/{kernel version}/ directory and then depmod is run which looks through the module headers to create a module database of supported device ids and what module is available for each device. The udev daemon listens to kernel gernerated insertion events and then loads the right module via modprobe based on the device ids from the kernel, the module database, and user preferences. It also generates the correct /dev entries for the new device.

[666threesixes666]

my custom kernels are about 1/5th the size of debian, but they also miss little details like console speaker modules.  ill look over the kernel docs, and roll a vanilla kernel tonight.  you need your file system, sata controller compiled in to boot with out initrd images.

 

ok 1st the kernel is the drivers.  its basically all the drivers a system could want, and some programs like iptables (firewalling) drbd (raid 0 over lan) etc....

 

when you update the kernel it generates a new bzImage file with the kernel version,  if its the same version it will append .old to the kernel.

 

the system boots, does post, then bios/efi then bootloader loads linux, linux loads its self and friends, starts openrc.  or something CLOSE to that....  it might be boot loader hands off to openrc then spawns kernel.  the file system and hard drive ide or sata controller which contains the linux are important drivers to find.

 

everything else you copy your old kernel config to the new kernel you're going to compile then add in whichever driver is required to run whatever you're trying to run.

[uudruid74]

You had the boot order right the first time! Never doubt yourself.

 

Bootloader loads kernel and initrd, a temporary root filesystem with more drivers/modules so that it can autodetect the root filesystem (which could means raid drivers filesystem drivers, nfs, etc)

 

The kernel loads initd and initd runs OpenRc scripts and anything else needed to start up the system.

[milktoast]

Some great information all around! Thank You