Todo: Refactor, break into sections and desribe each in more detail
Created Tuesday 22/8/2006
This document is a How-To for Fedora Core (FC) and describes quirks and features specific to the Fedora distribution. This How-To covers issues such as building a kernel image under Fedora, sound configuration, image and video playback, and package management and system configuration and administration.
The Fedora Core module config is similar to redhat and debian in that the modules to load are defined in a file based module database. From since about FC3 this has been /etc/modprobe.conf and the files contained in /etc/modules.d. Files and binaries of interest for module management are:
Todo: Refactor, break into sections and desribe each in more detail
The program /usr/sbin/setup, a symlink to consolehelper(1) can be used to modify which daemons are run on entry to a particular runlevel. See also chkconfig(1).
Todo: Need to add doco about /usr/sbin/setup (rpm is setuptool) which can be used to modify daemon startups which are symlinks to /etc/init.d scripts.
There are multiple package management systems in Fedora Core. However, rpm is the standard and is the basis for anaconda, the Fedora core installer. The rpm tool should be restricted to package mangement on the local system. For installing packages from the net, use something like yum or apt as they handle package dependencies well.
Todo: Add urls for yum front ends (yums, yam, pirut)
Note: Sound card configuration has moved to sound-linux
The kernel source for Fedora Core is installed into the source directory of the kernel version in /lib/modules. The source directory is typically a symlink to build, which itself is a symlink, typically pointing to /usr/src/kernels/<version>. So, for example, if the kernel version in question is 2.6.12, then the relevant directories for kernel source are:
Fedora Core uses /etc/modprobe.conf and not /etc/modules. The older Redhat RH9 used /etc/modules.conf. At any rate, the basic purpose and syntax of the two files is the same. So, to configure sound for an intel 82801EB add the line:
alias snd-card-0 snd-intel8x0
To either /etc/modeprobe.conf (for Fedora) or to /etc/modules.conf for RH9. Fedora Core also loads modules from /etc/modules.d, which contain the blacklist and modprobe.conf.dist (modules specified with the distribution). Also, Fedore Core may #include the file /etc/modprobe.conf.dist from within /etc/modprobe.conf. If this file is not included, then it can safely be removed.
IPv6 is loaded by default with Fedora Core. However much of the internet-working infrastructure may not be IPv6 ready loading this IP stack may slow network operations down as IPv6 DNS name resolution may be slow for systems where IPv6 is not running upstream. To turn it off, add the following to /etc/modprobe.conf:
alias ipv6 off alias net-pf-10 off
initrd image files (/boot/x-ver.img) are filesystem images usable as initial ramdisks for the linux boot process. To build one of these images, specify the kernel version that the ram disk loader should pull in. E.g., to rebuild an existing initrd image (e.g., for say a kernel 2.6.8-1.521), do the following:
bash-2.05b# cd /boot bash-2.05b# mv initrd-2.6.8-1.521.img initrd-2.6.8-1.521.img.bk bash-2.05b# mkinitrd -v -f /boot/initrd-2.6.8-1.521.img 2.6.8-1.521
Fedora Core comes with Security Enhanced Linux (selinux), which may cause a whole bunch of dmesg entries if an upgrade from rh9 has been performed as the filesystems might not have been labelled correctly. selinux comes with a script called fixfiles that can be run to relabel the filesystems as appropriate:
bash# fixfiles relabel
Tip: The Selinux FAQ has extensive selinux information
To build a custom kernel, download the source (e.g., from kernel.org) and unpack to /usr/src. The rest of this discussion assumes that a custom kernel is being constructed from kernel version 2.6.12. Clearly, building and installing a custom kernel requires root.
bash# cd /usr/src/kernels bash# tar jxf kernel-2.6.12.tbz2 bash# cd 2.6.12
The .config file is used to configure kernel options and device driver settings. It allows the kernel builder to specify which drivers and options should be staticly linked into the kernel image and which should be loaded as modules. Clearly, there's a trade off in terms of staticly linking (space) and loading as modules (time).
Options like Ethernet support (typically staticly linked), USB support (typically loaded as modules) and CPU and PCI bus options are specified in this .config file. Also, any non-standard device drivers as provided by 3rd party vendors can be specified at this point.
The .config options are specified with the make menuconfig (which provides for cursors-based text menu editing of the options). Other similar programs provide for a graphical interface to .config options, such as make gconfig and make kconfig
TIP: There are 100's of .config options and it's possible to start the .config process from a .config file that is known to be appropriate for hardware the custom kernel will run on.
TIP: It's useful to identify the custom kernel. This can be done by specifying the CONFIG_LOCALVERSION option, with a value like "_foonix". This identifier is appended to the name of the directory created in /lib/modules, such as /lib/modules/2.6.12_foonix. E.g.,
CONFIG_LOCALVERSION="_foonix"
The make gconfig (and related make menuconfig) save the options to the .config file in the current directory:
bash# cp /tmp/dot-config ./.config <-- optionally copy a known .config bash# make gconfig <-- make selections (m=module, y=static)
After the kernel device driver options have been specified, the kernel image can be built. This is done with make(1) and requires that gcc(1) is installed. The compilation process is started without any make args, as in:
bash# make
If the kernel is configured to load some device drivers as modules, then the "modules_install" must be executed to write the module libraries into the kernel lib directory:
bash# make modules_install
After the modules are installed, the kernel image can be installed with:
bash# make install
The upgrading from one release of Fedora Core to another can be done with yum
The fedora-release rpm for version FC 5.5 provides the required yum repositories and gpgkeys. This is available as fedora-release-5-5.noarch.rpm. To install this package:
bash $ wget http://download.fedora.redhat.com/pub/fedora/linux/core/5/i386/os/Fedora/RPMS/fedora-release-5-5.noarch.rpm bash $ rpm -Uvh fedora-release-5-5.noarch.rpm
In addition, the Livna packages (for multimedia, mp3 support and etc) also have an FC5 rpm. This available as livna-release-5.rpm. To install this package:
bash $ wget http://rpm.livna.org/livna-release-5.rpm bash $ rpm -Uvh livna-release-5.rpm
Note any rpm warnings from the rpm install above, especially those to do with config files. For example, the yum repository entries, e.g., files within /etc/yum.repos.d are not overwritten by default. Any new content (e.g., to fedora-extras) will be written as a new file with the extension .rpmnew
Merge any required changes between the .rpmnew files created in #10.A with existing yum repository files.
There maybe several old kernels installed on the system being upgraded. This happens each time a yum update is performed. These old kernels may cause dependency problems and so the safest option is to remove them, keeping only the current kernel rpm. Use rpm to find out which kernels are installed and then remove them.
Find out which kernel packages are installed:
bash # rpm -aq | grep kernel kernel-devel-2.6.16-1.2069_FC4 kernel-2.6.15-1.1833_FC4 kernel-2.6.14-1.1656_FC4 kernel-devel-2.6.14-1.1656_FC4 kernel-devel-2.6.15-1.1833_FC4 kernel-2.6.16-1.2069_FC4
Then determine which kernel version is booted:
bash # cat /proc/version Linux version 2.6.16-1.2069_FC4 (bhcompile@hs20-bc1-7.build.redhat.com) (gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)) #1 Tue Mar 28 12:19:10 EST 2006
Now remove old kernel packages
bash # rpm -e kernel-2.6.14-1.1656_FC4 kernel-devel-2.6.14-1.1656_FC4 kernel-2.6.15-1.1833_FC4 kernel-devel-2.6.15-1.1833_FC4
Perform a yum update as in
bash # yum -y upgrade 2>&1 | tee /tmp/yum_upgrade
The upgrade process will install new config files. If an installed package has a modified config file, then the upgrade process - actually this is done by rpm(1) - will create .rpmnew and .rpmsave files.
Identify the differences between any modified config files and the newly installed config files and merge the content, deleting entries that are obsoleted within the new config.
If the upgrade identifies that an existing config file has been modified, then the new config is created in the same location with an .rpmnew extension.
If the upgrade process identifies that the configuration file for a newly installed package did not previously exist, then rpm(1) writes the config content with an .rpmsave extension.
The upgrade process is now completed. Check that the bootloader (e.g., grub or lilo) contain the new kernel and that the kernel is present in the /boot directory. The FC5 kernel image is identified with _FC5.
After the kernel image cleanup performed in #10.C, there should be an FC4 kernel image and an FC5 kernel image. Perform the following 4 commands:
bash # cat /etc/grub.conf | grep _FC5
title Fedora Core (2.6.16-1.2096_FC5)
kernel /vmlinuz-2.6.16-1.2096_FC5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.16-1.2096_FC5.img
bash $ ls -laF /boot/vmlinuz-2.6.16-1.2096_FC5 bash $ ls -laF /boot/initrd-2.6.16-1.2096_FC5.img
bash $ rpm -aq | grep kernel kernel-2.6.16-1.2096_FC5 kernel-devel-2.6.16-1.2096_FC5 kernel-2.6.16-1.2069_FC4 kernel-devel-2.6.16-1.2069_FC4
If the new kernel images are installed in /boot and the bootloader (e.g., grub) knows about the new kernel image, then the upgrade is successful. Reboot and select the new kernel from the bootloader menu.
Stuart Moorfoot © 22 August 2006 foo@bund.com.au