Wednesday, May 7. 2008
Fedora 9 is only a few days away, as the counter on the front page testifies. Although it's possible to upgrade an earlier Fedora system to F9, it's generally agreed that a fresh installation is cleaner and has less potential for problems. If your system uses LVM (which has been the default for the last several Fedora releases), it's particularly easy to perform a fresh installation while maintaining access to your previous data, because you can create new Logical Volumes within your existing Volume Group. You can then mount your old filesystems and migrate data over with ease.
This type of installation will be covered in the upcoming F9 Focus Week, but in order to prepare for it, you'll need some free space within your volume group -- I'd recommend at least 6-10 GB. If you're not really comfortable with the LVM commands, you can explore and adjust your LVM configuration using the system-config-lvm tool; however, to reduce the size of a logical volume and free up some space, the filesystem within that logical volume must be unmounted -- and in the case of the root filesystem, that means that the system can't be running in its normal way, which pretty much precludes the use of system-config-lvm. To reduce the size of the root filesystem, see the article on Using LVM In Rescue Mode from System Recovery Week.
(Note the links above -- sorry if they're not very visible or obvious due to the styling).
Update: KageSenshi points out that system-config-lvm is on the Fedora live disc images. You can resize the root filesystem on the hard disk by simply booting from a live disc and running the system-config-lvm command from a terminal window.
Wednesday, February 27. 2008
PulseAudio became the standard audio system in Fedora 8, but how does the pulseaudio daemon start in a Gnome session?
Gnome sessions are managed by gnome-session, which starts a standard set of clients (as well as any programs which you have configured for your account) each time the Gnome desktop is started. The file /usr/share/gnome/default.session file, which configures the default list of clients, looks like this:
As you can see, the PulseAudio daemon is not among the programs listed (note that gnome-volume-manager is the mounted filesystem volume manager, not an audio volume manager). But this list isn't exhaustive: commands listed in .desktop files in /usr/share/gnome/autostart are also executed when a session is opened -- but on my system the only files in there are bluetooth-applet.desktop, gnome-volume-manager.desktop, and
So what starts pulseaudio? A quick check of the output of ps reveals that its parent process is in fact gnome-session, and strace confirms this.
A look at the rpm packages that start with "pulse" reveals something interesting:
The esound daemon (esd) was the audio daemon historically used by Gnome. A quick look at the files included in pulseaudio-esound-compat shows that it provides a dummy esd command:
The man page for esdcompat tells a bit more of the story:
This brings us to the final question: why does gnome-session start esd if it's not mentioned in any of the configuration files? Surely it can't be ... hardcoded?!
$ strings -a /usr/bin/gnome-session | egrep '\/usr\/bin\/esd'
Wednesday, February 13. 2008
A Fedora system usually begins its boot process with a startup screen (or menu) displayed by the bootloader Grub. The background for this screen is provided by the wonderfully talented Fedora artTeam. The image is in the file /boot/grub/splash.xpm.gz from the package fedora-logos.
Customizing your boot screen with a favorite photo, your company logo, or even a cartoon is quite straightforward:
Reboot to see the result.
The XPM format used by Grub is very unusual: it's actually a snippet of C source code containing an ascii-to-colour translation table and the image encoded as ASCII art. You can see this by using gunzip to decompress the file and then viewing it as text.
Tips on preparing a grub splash image:
Wednesday, November 28. 2007
Fedora, like most current Linux distributions, uses Grub as its bootloader on 32- and 64-bit x86 systems. Grub's configuration file, /boot/grub/grub.conf, typically looks something like this:
This file contains general options (in green), boot stanzas for Fedora (blue), and a boot stanza for Windows (red).
The general options are:
The Fedora stanzas (and those for other Linux distributions, if any) each consist of a title line followed by lines for:
Grub will load the kernel and initrd from the specified root device, then execute the kernel. Other operating systems, such as Windows, are loaded differently -- so Grub hands the boot process over to whatever bootloader was installed with the operating system, using these lines:
Throughout this file, partitions are referred to as (hdX,N) where X is the drive number in the order in which drives are discovered by the BIOS, numbered starting at zero, and N is the partition number, also numbered starting at zero. If your system only has one drive installed, the partition /dev/sda2 (/dev/hda2 under Fedora 6 and earlier) will therefore correspond to (hd0,1) in Grub notation.
If you're using Xen, your Fedora boot stanza will look something like this:
In this case, the "kernel" is actually the Xen hypervisor, and the actual dom0 kernel and initrd are loaded as modules to the hypervisor. Any kernel arguments must therefore be added to the module line which references the kernel (/vmlinux-*).
Since gub.conf is a regular text file, you can edit it with the text editor of your choice, such as vi, gedit, or kate. However, if you introduce an error into this file, you may not be able to boot your system from the boot menu. To reduce risk, it's a good idea to keep a known-good stanza in the file -- and in the worst case, you can always edit a boot stanza using the options provided by Grub during the boot process.
Wednesday, September 12. 2007
During system installation with Anaconda and when managing packages using the Browse mode of Pirut (which appears on the menu as >Applications>Add/Remove Software and identifies itself as Package Manager in its window title), you are given the option of selecting packages by groups arranged into broad categories. Each group may contain mandatory and optional packages, and optional packages in each group may be included or excluded for installation by default. Some packages are not included in any category and cannot be installed through this hierarchy.
The package taxonomy is created by the comps XML files, which are found in /var/cache/yum/*/comps*.xml -- each repository may have its own comps file. These files use an XML format which looks like this:
As you can see, the <category> tag defines the groups in a category, and the <group> tag defines the packages in a group. Text such as the name and description of each category and group is usually provided in multiple languages through the use of the xml:lang attribute.
Packages marked with a type of mandatory in the <packagereq> tag are always installed if the group is installed. Conditional packages are treated as mandatory if the requires package is present: for example, if you install the French language group and have Moodle installed, then French language support for Moodle will automatically be installed. Packages with a type of default or optional appear on the optional package list for the associated group; initially, the default packages are selected, and the optional packages are deselected.
Wednesday, September 5. 2007
If you install the Apache web server on your Fedora system, start it, and then access it before adding any content, you'll see the "Fedora Test Page" or "Welcome Page" as shown here. Where does this page come from, where is it configured, and how does it disappear once you add content?
This page clearly isn't configured in the main Apache configuration file, /etc/httpd/conf/httpd.conf -- there is no mention of it there at all. Instead, the configuration for this page is actually specified in /etc/httpd/conf.d/welcome.conf, which looks like this:
The LocationMatch directive ensures that this configuration applies only to requests with a path of / (or multiple slashes), which matches only requests to the DocumentRoot (http://ServerName/). For any such request, the Indexes option is disabled, so you cannot get an automatic index or directory listing. If a pre-built index page exists, such as index.html or index.html.var, that file is served; but if it doesn't exist, an HTTP 403 error is generated ("Forbidden"). The ErrorDocument directive specifies the page to be served in that case: /var/www/error/noindex.html. As soon as you create an index page, the 403 error is no longer generated, and the Welcome page disappears.
The configuration file /etc/httpd/conf.d/welcome.conf is owned by the httpd (Apache) package. Most of the other configuration files located in /etc/httpd/conf.d are owned by web application packages such as webalyzer, BackupPC, gallery2, or squirrelmail, and specifically configure Apache for that one application; removing the package removes the corresponding configuration file, removing the application-specific Apache configuration.
Wednesday, August 29. 2007
If you have a large number of Fedora systems (including virtual machines), you can speed up your system updates by creating a local mirror of the Fedora repositories. This will enable you to download packages once for all machines on your network instead of once per system.
Here is one way to do this:
You will need a machine with a large amount of free space in /var (100GB is safe) and the rsync and httpd packages.
First, create a small script to create and update your repository:
Warning: using rsync with the --delete option can have disasterous effects if run in the wrong directory.
Save the script and make it executable (chmod u+rx scriptname). When run, this script will copy the repository identified by the URL to /var/www/html/fedora/updates/$ARCH.
To determine the URL to be used, view the Fedora mirror list at http://mirrors.fedoraproject.org/publiclist/Fedora/7/ and select one of the rsync mirrors. Test it out using the rsync command:
$ rsync -v rsync://selectedhost/
This will show you the contents of the root rsync directory on the remote host. You may need to experiment until you find the directory that contains the RPMS subdirectory for your release of Fedora and machine architecture-- the mirror servers seem to have their own particular directory layouts. You're looking for the directory named os. For example, you might end up with a URL such as rsync://selectedhost/fedora/updates/7/i386/os/
Start the Apache web server (service httpd start) and opening a hole in your firewall for port 80 (use the menu option > System > Administration > Firewall and SELinux) so that your web server is accessible. You will be able to access your local repository mirror as http://yourserver/fedora using a browser.
Finally, configure your systems to use your local repository for updates by setting up a baseurl entry in /etc/yum.repos.d/fedora-updates.repo as described here. Test it out, and once you have it working, configure the cron daemon on the server to run the repository update script daily using this command:
Replace /path/to/update-script with the absolute pathname of the script, and adjust the time according to your needs ("0 4 * * *" means 4:00 am every day).
Wednesday, August 22. 2007
Fedora employs the Advanced Linux Sound Architecture (ALSA) system, a feature of the 2.6 kernel series. In addition to the kernel drivers, ALSA incorporates a library and a set of utility programs.
You've probably noticed that ALSA settings for various input and output controls are preserved across reboots. The audio device state is saved in the file /etc/alsa/asound.state, a text file which contains a description of each device control and the current values.
This file is created and read by the program /sbin/salsa, which is part of the alsa-utils package. At shutdown, the script /etc/rc.d/init.d/halt calls /sbin/salsa with the -s (save) argument:
When the udev subsystem discovers audio devices -- usually at system startup, but possibly at later time if an audio device such as a USB soundcard is not present at boot and hot-plugged later -- these two rules in /etc/udev/rules.d/90-alsa-rules are invoked:
The RUN part of each rule executes /sbin/salsa to restore the audio settings for all devices.
(Page 1 of 4, totaling 28 entries) » next page
The Fedora Daily Package exists to highlight lesser-known Fedora Linux packages each weekday-- with a special article each Wednesday taking a behind-the-scenes look at some of the configuration options and packaging details that make Fedora tick. For more information, please see the Fedora Daily Package Welcome posting.
To suggest a future Fedora Daily Package, use the Suggest a Package box below.
Suggest a Package
Chris Tyler's Blog
Syndicate This Blog
Original material in the Fedora Daily Package is Copyright ©2006-2008 by Chris Tyler. This material may be distributed under the Creative Commons Attribution-Share Alike 2.5 Canada License or the Open Publication License.