A "macho" Linux user might just jump in and install a random Linux distribution on any available hardware. In contrast, a real Linux geek uses hard-learned knowledge to plan a Linux installation. A quality plan can help the geek manage the system throughout its life cycle. Once tested, that system can be replicated in the enterprise, saving cost and time. In this chapter I provide guidance that can help you harness your experience before you install.
The latest Linux distributions are easy to install on most modern hardware. I've found few annoyances within the installation routines for the Linux distributions I know. But there are related topics that merit careful attention. Ideally, every hardware component that you own is certified by the Linux distribution of your choice. But we live in the real world. For example, many geeks have to deal with bosses who want Linux installed on the cheapest possible laptops (translation: hardware that depends on Microsoft driver libraries with few available Linux drivers) with all the latest features, such as wireless support and working high-resolution displays.
The choice of Linux distributions can be difficult. Your manager may not have heard of your favorite distribution. If you choose a cost-free version of Linux, you generally have to download gigabytes of data, and "everyone" wants the latest distribution when it's released. While there are brand-name distributions that may get a corporate stamp of approval, they may also break your budget. Unless you can afford to rely exclusively on support from Red Hat or Novell/SUSE, you need to know how to interact with the Linux community in order to solve some of the annoyances I touch on in this book. While flames may seem to be the norm to many, there are several principles that can maximize the quality of response from the community, which I'll list at the end of the chapter.
One common "annoyance" is the literature that warns of dire consequences if you don't record every detail of your hardware before starting the installation process. You've probably installed Linux on a variety of computers. While you may never have had a problem with hardware, trouble does happen. For this reason, some Linux vendors, including Red Hat and Novell, do test and certify hardware components as well as entire systems. They offer more extensive support if you use such hardware. Even if you're using another distribution, their certified hardware is more likely to work reliably with Linux.
Any A+ certified hardware technician can list the hardware components on a computer. A Linux geek can cite the compatible components, such as the chipsets associated with a specific wireless card. He can use this information to compile the most efficient kernel for his system.
Tip
The A+ certification was developed by CompTIA, primarily as an entry-level exam for Microsoft computer hardware technicians. As someone comfortable with Linux, you know so much more about computers. The entry-level CompTIA Linux+ exam (www.comptia.org/certification/linux/) includes a significant hardware component. Other Linux certifications include those released by the Linux Professional Institute (www.lpi.org), Novell (www.novell.com/training/certinfo/), and Red Hat (www.redhat.com/training/certification/).
If you're installing Linux at home, consider whether your system has any of the common components in Table 5-1, and ensure you know at least the make and model of each component. If time is limited, focus on the components that you configure during the installation process: the size of the hard drive(s), CPU(s) type, amount of RAM, and video card chipset.
Table 5-1. Common hardware components
Component | Key information to learn | Additional information |
|---|---|---|
Motherboard/BIOS | Integrated support (e.g., video) | A BIOS upgrade may add useful options. |
CPU | Type (x86 [e.g., i386, i586, i686], ia-64, Itanium) | Some distributions may be built for your CPU. |
RAM | Amount | Minimums vary by distribution. Some BIOSes can detect only a limited amount of RAM. |
Video card | Chipset | If Linux can't detect your chipset, get the Horizontal and Vertical refresh rates. |
Hard drive controller | IDE, SCSI, SATA, RAID support | SCSI and SATA can support more than the standard 4 IDE drives. |
Network adapters | Chipset, revision | If Linux doesn't detect your adapter, knowing the chipset and revision level can help you find alternative drivers. |
Sound | Chipset | Most have MIDI/ALSA support. |
Hard drive | Size | A few drives are not supported; avoid the same IDE cable for multiple drives. |
Pointing device | Mouse protocol | Most two-button mice can imitate the middle (third) button. |
Keyboard | Keyboard type | Usually associated with a language. |
Modem | Connection (PCI/USB/ISA) | Microsoft-dependent hardware discussed later. |
Printers | Parallel/USB | Microsoft-dependent hardware discussed later. |
What follows are solutions to the most common hardware annoyances, with general guidance that you can follow for unspecified hardware problems. Ideally, you should classify your systems or hardware in the following categories:
Certified hardware by a distribution company
Compatible hardware, as classified in one of the Linux hardware databases
Additional Linux-compatible hardware, which requires additional research, including the Linux Hardware HOWTO
Linux hardware in the works, with pre-release drivers
Incompatible hardware, awaiting development
The first thing to check is the web site for your Linux vendor. They maintain lists of hardware and systems that they've tested. You can find Red Hat's list at http://bugzilla.redhat.com/hwcert/; Novell/SUSE currently maintains their list (English version) at http://hardwaredb.suse.de/?LANG=en_UK. If you're lucky, you're working with complete hardware systems certified for a specific distribution. Red Hat and SUSE have tested a number of complete servers, workstations, notebooks, and more. If you are installing a Linux distribution on certified hardware, you should have no problems, and you may be able to get additional support for your systems.
One implied category of certified hardware consists of computers where Linux is already preinstalled. There are a number of vendors, including big names such as HP and Dell, who sell systems where they install a major Linux distribution for you. They support their systems with the originally installed operating system. All you need to do is keep it up-to-date. However, if you add hardware or a new Linux distribution, you may be on your own.
Red Hat and SUSE, among others, maintain a database of compatible hardware. Such hardware has been tested, often by employees associated with that distribution. This is known by Red Hat as "compatible hardware" and by SUSE as "ready for SUSE Linux." While distributor companies may provide limited support for such hardware, there may be interactions such as IRQ conflicts beyond their control.
Tip
Red Hat has recently changed their hardware database to focus on compatible hardware systems. As of this writing, there are very few individual hardware component compatible with Red Hat Enterprise Linux 4.
As Debian is built by volunteers, they do not have a program of certified hardware. But as with any Linux distribution, you can start your hardware checks with the Linux Hardware HOWTO, available from http://www.tldp.org/HOWTO/Hardware-HOWTO.
The databases provided by the Linux distributors can't keep up with the torrent of new hardware. They may not have updated their databases for the latest Linux drivers. So if you don't see your hardware on a compatibility list, don't give up! I'd look in five areas:
Check the web site associated with your hardware. You might just find a new set of Linux drivers, ready for download. If you're lucky, you may get an RPM or DEB package that you can install directly on your system. Alternatively, if you have to compile drivers from their source code, you may need to install the Linux kernel source code for your system. Watch the Makefile associated with such source code; you may need to modify its settings.
At other times, Linux compatibility may be there where you least expect. The chipset associated with a component may be produced by a third company.
Third, Linux drivers for earlier versions of a component may provide partial compatibility. For example, the drivers associated with a version 1000 scanner may provide sufficient functionality if you're working with a version 1100 scanner.
Fourth, there are developers who enjoy cloning drivers for new hardware. Just as the original Linux developers cloned the functionality of Unix, the Linux hackers of today create new source code that emulates the functionality of proprietary drivers. Sometimes hackers build the functionality with original code; other times they may build wrappers that allow use of drivers built for other operating systems. As open source developers want to share their work, their progress is usually available online. Some are organized into SourceForge groups, which are listed at http://www.sourceforge.net.
Finally, you sometimes may be able to extract the drivers by recompiling the kernel. I describe the recompiling process in "Recompiling the Kernel" in Chapter 7.
Linux hackers are constantly at work on incompatible hardware. They lobby hardware vendors to release their source code. They clone drivers for desirable peripherals. The open source nature of Linux means that the development work is transparent. If you have the time, there are a multitude of projects where you can help. SourceForge is the home of a number of Linux hardware projects.
The people behind Linux distributions are often cautious. Many won't include a developmental driver until it is tested and proven to work, without causing trouble with other systems. But if you absolutely need that wireless card, that scanner, that memory stick, etc., developmental drivers may be your only choice. And if you have to compile the driver into your kernel, that's another annoyance we'll work through in "I Need to Add a Custom Kernel Module" in Chapter 7.
Any developmental software that you install may be less than complete. For example, you may need to configure a script to load the appropriate drivers the next time you boot Linux. If you want to run the script during the boot process, you can make it part of the appropriate boot script from the following table:
Distribution | Script |
|---|---|
Debian | /etc/init.d/local |
Red Hat/Fedora | /etc/rc.local |
SUSE | /etc/init.d/boot.local |
These files are often empty; when you add the commands of your choice, they're run automatically during the boot process. You'll actually have to create /etc/init.d/local on Debian Linux; all you need is to start the script with the first line to use the bash shell interpreter, followed by the full path to the commands you need:
#!/bin/sh
/path/to/command switchYou'll need to make sure the command starts in the appropriate runlevels, preferably after other scripts, with the following command:
update-rc.d local defaults 99c
The resources of the Linux community are limited. They may not be working on the hardware that you need. There are third parties who can help, for a fee. For example, Xi Graphics' DeXtop (http://www.xinside.com) and SciTech's SNAP graphics (http://www.scitechsoft.com) provide proprietary drivers for many otherwise incompatible graphics cards. Linuxant (http://www.linuxant.com) provides a wrapper that uses Microsoft Windows driver software for network cards.
If you're brave and dedicated, you can start your own Linux hardware project. A good place to start is SourceForge, where you may ask for help from those working on related projects. Alternatively, Linux Device Drivers by Jonathan Corbet et al. (O'Reilly) is also an excellent resource, as it can help you identify starting points from related hardware.
In typical desktop and laptop systems, a number of components depend on Microsoft Windows driver libraries. The most well known of these is the winmodem. Trouble with Microsoft-dependent devices is not limited to Linux; there are a wide range of Microsoft-dependent devices that do not work on Windows XP/2003. While most of these devices are modems and older printers, don't be surprised if you find other Microsoft-dependent hardware. Many of the initial "hacks" that support this hardware are based on the Wine project, which allows Linux to use Microsoft driver libraries.
Tip
As strange as it sounds, about half of U.S. Internet connections are still made via telephone modem. While this seems almost "third world" in contrast to broadband connections in other industrial nations, it means that telephone modems are still a common fact of life in the U.S., and a key skill set for the well-rounded Linux geek.
In principle, it's best to find and install hardware that does not depend on Microsoft driver libraries. In practice, that's not feasible, as many computers come preloaded with winmodems.
In many cases, Linux detects winmodems straight out of the box. To see if that applies to your system, run the lspci command. Linux has detected winmodems on all three of my computers. The lspci output is straightforward; I've isolated the key lines for the detected internal modems:
01:0e.0 Communication controller: Conexant HSF 56k Data/Fax Modem (rev 01) 0000:00:08.0 Modem: Ali Corporation M5457 AC'97 Modem Controller
When I ran a cardctl ident command, Linux also detected the PCMCIA winmodem on my third computer, a Motorola ModemSurfr, as shown here:
Socket 1: product info: "Motorola", "MobileSURFR 56K", "021", "A" manfid: 0x0109, 0x0505 function: 2 (serial)
If you have an ISA modem, you might try a pnpdump or isapnp command. If a modem is installed when you start Linux, you might be able to find a related message in the /var/log directory, in the dmesg or messages files.
But even when your winmodem is supported by the kernel, configuring the modem might require extra effort on your part. With the latest Linux distributions, working winmodems are linked to the /dev/modem device file; for example, the following output from ls -l /dev/modem tells me that /dev/modem is ready and linked to /dev/ttyS1, also known in the Microsoft world as port COM2. (Microsoft numbers ports starting at 1, while Linux starts at 0; COM1 is ttyS0, and so forth.)
lrwxrwxrwx 1 root root 10 2004-11-19 07:12 /dev/modem -> /dev/ttyS1
If you don't see this link, you'll need to create it. If you know the port device associated with your modem (such as from a dual boot with Microsoft Windows), you can do so with the ln command. For example, if Microsoft suggests that the modem is connected to port COM3, use the following command:
In -s /dev/ttyS2 /dev/modem
If you want winmodem support, you'll need to enable kernel modules. This is a good practice that I think every Linux geek follows in a regular PC, because enabling modules lets you load the drivers and other modules that you need, depending on the type of modem that you have.
One problem Linux has in a Microsoft-dominated world is default Plug and Play settings. Left alone, Linux does well with Plug and Play. However, any Plug and Play settings in a computer BIOS can keep Linux from detecting an otherwise Plug and Play device.
If you have an ISA winmodem, run the pnpdump command. This looks through all of your ports for ISA attachments. Look at the output in the /etc/isapnp.conf file. SUSE 9.3 still has pnpdump in the isapnp package. The current version of Debian Sarge includes pnpdump in the isapnptools package.
Tip
ISA cards are sufficiently rare that some distributions (including Red Hat/Fedora) no longer include the isapnp package, which includes the pnpdump command. If you have a newer distribution without isapnp, you should be able to install an older version of the package on your system. Alternatively, you can download and install the appropriate packages from http://www.roestock.demon.co.uk/isapnptools/.
If Linux detects a PCI card on your system, you should find it in the output to your lspci or scanpci commands. You may get additional information if you run lspci in verbose mode—i.e., lspci -vv. Some distributions (such as Red Hat) store this information in /proc/pci.
If you're fortunate, your winmodem is ready to go. Your /dev/modem device is linked to the actual modem device (alternatively, you can substitute the actual modem device file, such as /dev/ttyS1). You can test your modem from the command-line interface with the minicom utility. I open it with the minicom -s command, which starts the configuration menu, where you can modify modem settings as needed through the Serial Port Setup menu. When you run the "Save Setup As Dfl (default)" command, and then exit, minicom takes you to the main menu with a basic Attention (AT) command similar to:
AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 OK
This confirms that Linux can communicate with your winmodem. You can configure the Internet connection tool of your choice, such as KPPP or Red Hat Internet Configuration Wizard, to connect to the Internet via modem. Alternatively, you could connect directly on a touch-tone line with a command such as:
ATDT 555-654-3210
If your modem is connected to the telephone network, this will dial a number. If successful, it connects you to the system on the other side. If the call is not free, you may see additional charges on your telephone bill.
If minicom shows no response to your commands, Linux is having trouble communicating with your modem. The first step is to make sure your phone line is securely connected to your modem.
The next step is to find the chipset associated with your winmodem. You may already see it in the output to the lspci -vv command or in the /proc/pci file, both described earlier in this annoyance. Alternatively, you can use the scanModem tool available at http://www.linmodems.org to find most chipsets. Just make sure to make the scanModem tool executable (chmod +x scanModem).
You can then connect to additional resources for your system through links at http://www.linmodems.org, or with a Google search. The options are too varied to list here. In general, you will need to install the source code for your active kernel, make sure to enable modules, and then add the driver modules you need.
If you have a Conexant/Rockwell winmodem, you may be able to use the drivers available through Linuxant. While their work does not fully comply with the GPL (see the Linuxant HSF Driver License Agreement), it can save significant amounts of time. If you're willing to live with 14.4 Kbps, they have drivers that you can download for free. Alternatively, full 56k drivers are available on a trial basis for a month, and then for a one-time fee of $20.
Tip
If you use the Linuxant drivers (or any other drivers where the source code is not available and licensed under the GPL), they "taint" the Linux kernel with non-GPL code. For many, this is not a big deal; it's just incorporating code that helps Linux work better. But if you're building a new version of Linux, tainted code can't be released under the GPL. In addition, some Linux enthusiasts are ideologically opposed to non-free drivers and refuse to help people on mailing lists if they use such drivers.
The other major hardware item that depends on Microsoft Windows driver libraries is the GDI printer, also known as the winprinter. Naturally, most winprinters are found on older (pre-year 2000) systems. As these printers generally depend on older driver libraries, newer Microsoft operating systems such as 2000/XP also have trouble printing to winprinters.
There are three basic categories of winprinters. Two are associated with specific brands (HP and Lexmark). The third includes a variety of printers that are designed to convert Windows printer output into the PostScript language that newer Microsoft operating systems can understand. Unfortunately, that by itself does not make such printers usable on Linux. However, many Linux distributions include the work described at http://linuxprinting.org to help many winprinters work on Linux.
Sometimes winprinters are already supported through the new standard Linux print system, CUPS. Before you try any other techniques, try configuring your printer through CUPS (or system-config-printer in the latest Red Hat/Fedora distributions). You may be pleasantly surprised.
Briefly, the HP winprinters use Printing Performance Architecture. If you have one of these printers, you can download the pnm2ppa print filter. If there is no package available for your distribution, you can download it from the associated SourceForge project home page at http://sourceforge.net/projects/pnm2ppa/. As it was last updated in 2002, there is no guarantee that it will work with the latest distributions.
A few older Lexmark printers also relied on Microsoft Windows driver libraries; these printers were effectively ported by 2000. A number of the associated Linux drivers are available from http://bimbo.fjfi.cvut.cz/~paluch/l7kdriver/.
The sales of laptop computers are rapidly approaching those of desktops. According to the NPD Group (http://www.npd.com), the dollar sales of laptops exceeded those of desktops for the first time in 2003. Computer users want mobility. Linux geeks want to be in the forefront of this trend.
Weight, form, and function are critical on laptop computers. Many manufacturers rely on unique proprietary systems to reduce even a few grams from each system. Fortunately, a lot of hackers have shared their Linux experiences on a wide variety of laptops. A lot of this information has been collected on two web sites, http://www.linux-laptop.net and http://www.tuxmobil.org. The same principles apply when you install Linux on Personal Digital Assistants (PDAs) and even mobile phones.
Laptops provide additional hardware challenges. Components such as PCMCIA cards, LCD displays, infrared ports, and more were first commonly used on laptops. They normally require drivers that you won't find for desktop computers.
Laptop computers include more specialty hardware than desktops. For example, laptops have PCMCIA adapters. They may have mini-PCI cards. They may not even include CD/DVD drives, which makes network cards more important for installation. Their graphics systems often include customized chipsets.
There are a few manufacturers who sell laptops with Linux preinstalled. Besides HP's nx5000, there are a number of smaller companies who sell laptops with Linux preloaded. The skill sets of these manufacturers, and thus the levels of support, vary.
Most laptops still come with Microsoft Windows preinstalled. If you overwrite the Microsoft operating system, you may partially or completely void the warranty for your computer. Nevertheless, many Linux geeks appreciate the challenge of installing Linux on a laptop designed for Microsoft Windows. However, that can lead to a number of annoyances, including the dreaded winmodem (a modem designed to work with Microsoft drivers; see the previous annoyance) as well as proprietary hardware without Linux drivers. If you see your laptop (or a similar model) at http://www.linux-laptop.net or http://www.tuxmobil.org/mylaptops.html, read through people's experiences with it. For example, I had trouble installing Red Hat Enterprise Linux 3 on an HP laptop until I read the experience of another Linux geek on how Anaconda (Red Hat's installer) has trouble detecting the HP keyboard. All I had to do was tap on the keyboard at the right time, and Anaconda recognized the keyboard.
Tip
Many Linux geeks believe that the preloading of Microsoft Windows on most personal computers is essentially a tax. There have been several efforts in recent years to get refunds on preloaded Microsoft operating systems. Unfortunately, these efforts have been less than successful.
As a Linux geek, one more annoyance (for some) is a responsibility to share with the community. If you've installed Linux on a laptop that you don't see on the list, post your experience online. Submit your experience to one of the aforementioned Linux laptop sites. Once you've done so, you can cite your contribution and increase your credibility in the Linux community.
When you're planning a Linux installation on a laptop computer, you'll generally want to pay particular attention to the hardware components noted in Table 5-2. Focus on the details you need for installation.
Table 5-2. Laptop hardware annoyances
Component | Key information | Additional data |
|---|---|---|
BIOS | Boot order | Some BIOS settings—such as legacy USB, Plug and Play, and hibernation—can prevent installation. |
Monitor | Resolution, refresh rates | Find the maximum refresh rates to avoid overloading the monitor. |
Graphics card | Memory, chipset, options | If there is no Linux driver available, be prepared to accept a minimal SVGA configuration. |
No CD/DVD drive | Is there room for a portable drive? | A portable drive requires PCMCIA (Cardbus) / USB / IEEE 1394 (FireWire) drivers during the installation process. |
Wireless card | PCMCIA, USB, or mini-PCI | Check the availability of the driver for your wireless card. More information is available in a related annoyance, "My Wireless Card Works on Another Operating System, but Not Linux," later in this chapter. |
Power management | APM or ACPI | Linux drivers depend on power-management scheme; better managed in Kernel 2.6. |
If you have a 1.44" boot floppy and CD/DVD drive integrated into the laptop, you're set. You should be able to install Linux on your laptop even if your BIOS doesn't detect the Linux installation CD. But what if your laptop doesn't meet these requirements? While I can't cover all possible scenarios, I have some basic suggestions:
If you're having problems booting from a CD despite the right BIOS configuration, check it on another CD drive. Make sure the md5sum or sha1sum value matches that of the download or the associated text file listed on the CD. If you're still having problems, re-create the CD, preferably on the same drive. Also, some laptops can't handle the more common compressed bzImage kernels.
If you're having problems booting from a DVD, try booting from a CD. Some drives that won't boot from a DVD will boot from a CD. This is one reason why both SUSE and Fedora provide bootable CDs and DVDs.
If you can't boot from a CD/DVD or floppy, there are other options. If your network card supports the Pre-boot eXecution Environment (PXE), you can boot and install Linux via a TFTP network installation server. For more information on a PXE-based Red Hat installation, see http://www.stanford.edu/~alfw/PXE-Kickstart/PXE-Kickstart.html.
If your laptop BIOS supports booting from a USB key drive, you can set up a network boot from that device. Generally, you can write boot disks to a USB key drive almost in the same way as you would to a CD. This is important for Fedora/Red Hat distributions, where the alternative boot image is now designed for a USB key drive.
Alternatively, you can set up installation files on a different laptop partition. For details, see the documentation for your distribution.
Display issues are common when installing Linux on a laptop. Key to managing a display on Linux is the frame buffer, where your current screen image is stored, pixel by pixel. You can manage how the frame buffer functions during the Linux installation process. Help screens are often available when you press a function key—such as F1, F2, etc.—from the installation boot screen. There are two basic problems you may have with the display.
The installation screens may not be readable. No instructions are visible. You are forced to restart the process. In this case, you can disable frame buffer acceleration. Some distributions allow you to do so by adding linux nofb to the installation prompt.
The display may be out of proportion. For example, I've seen a 320 × 200 display that shows a useless fraction of a graphical installation screen. In this case, you can restart the installation process, with the frame-buffer video modes shown in Table 5-3. For example, if you add vga=791 to the installation boot prompt, you're setting 16-bit color with 1024 × 768 resolution. This is a translation of the hex code, which is described in the Framebuffer HOWTO at http://www.tldp.org/HOWTO/Framebuffer-HOWTO.html.
Just because you've installed Linux on a laptop doesn't mean that it's useful, at least to someone who is experienced with Linux. Installation routines install software and drivers only for detected hardware. Linux can't install software for what it doesn't see.
The Linux 2.6 kernel is generally superior in the way it handles laptop hardware. Unlike the Linux 2.4 kernel, it incorporates the code required to handle different PCMCIA adapters. The extra steps in older books to make sure that PCMCIA drivers are loaded during the installation process no longer apply. But there are problems. For example, some of the earlier 2.6 kernels have power issues with respect to PCMCIA cards. A number of these issues have been collected at http://pcmcia.arm.linux.org.uk.
Tip
Cardbus is the 32-bit version of the PCMCIA bus. Current laptops should have Cardbus controllers. If you see such a listing in the output of the lspci command, Linux has detected your PCMCIA controller.
If you have problems with PCMCIA cards, the first place to start is the controller. Generally, you can identify the associated PCMCIA/Cardbus controllers (and installed cards) with the lspci command. Kernel modules associated with the controller should show up in the output to the lsmod command. Typical PCMCIA controllers are associated with the yenta_socket and i82365 modules.
Tip
If you're having trouble with the PCMCIA controller, make sure you have the appropriate PCMCIA package installed. For Debian and Red Hat, it's pcmcia-cs (naturally, in their native DEB and RPM package formats). For Fedora, it's now pcmciautils. For SUSE, it's pcmcia. Make sure the pcmcia service script (which is normally started from /etc/init.d) is running and that it starts in the appropriate runlevels. It should also load the appropriate modules; you need not include them in /etc/modules.conf, /etc/modprobe.conf, or related files.
Once you have your PCMCIA controller working, you can now run the aforementioned commands to check for the card. In addition, you can use various cardctl or pccardctl commands to check whether cards have been properly detected by your laptop PCMCIA controller. If your kernel recognizes your card, you should see it listed in the output of the cardctl ident command. I show you how this process works in the next annoyance, which discusses wireless network cards
There are a number of different CPUs designed to save power on laptop computers, controlled on modern Intel-style systems through the Advanced Configuration and Power Interface (ACPI). Power management allows ACPI to adjust the CPU to lower speeds. Throttling allows ACPI to lower the CPU clock speed when the temperatures are too high. The limit interface option allows ACPI to regulate both power management and throttling. They generally works as follows: the bus master allows ACPI to tell your RAM to stop accessing the CPU, which allows the CPU to enter a sleep or suspend state. This in turn lowers the power consumption of the CPU and lets the battery run longer.
If ACPI does not save battery power or otherwise help you regulate power on your laptop (http://www.tldp.org/HOWTO/ACPI-HOWTO/), disable ACPI through your bootloader. Linux interfaces work well with the older Advanced Power Management (APM) service. It's normally part of the apmd package, which is available on most distributions. To disable ACPI, add the following command to the kernel command line in your bootloader configuration file (such as /boot/grub/grub.conf, /boot/grub/menu.1st, or /etc/lilo.conf):
acpi=off
You may already have optimal power-management settings. If you've activated the Advanced Configuration and Power Interface (ACPI) daemon for Linux, check your kernel processor settings. For the first CPU, it's located in the /proc/acpi/processor/CPU0 directory. Check the info file in this directory. If you have full ACPI power management configured, you should see:
bus mastering control: yes power management: yes throttling control: yes limit interface: yes
For power management, ACPI also may use the SpeedStep or PowerNow! modules. Both are normally compiled into the kernel:
SpeedStep is associated with the Intel Centrino CPU. It's configured as a module on most Linux distribution 2.6 kernels. To check, run the following command:
grep CENTRINO /boot/config-`uname -r`
PowerNow is associated with the AMD K6, K7, and K8 CPUs. It's configured as a module on most Linux distribution 2.6 kernels. To check, run the following command:
grep POWERNOW /boot/config-`uname -r`
If the associated kernel settings are not set to m or y (modular or included in the kernel), you may need to make changes. I guide you through the annoyance of recompiling the kernel in "Recompiling the Kernel" in Chapter 7.
To manage these systems, Debian supports the cpufreqd or cpudyn DEB packages, which you can add with the apt-get install command. Alternatively, you can install the cpufreq package from a SUSE installation CD. If you have a Red Hat/Fedora distribution, you can get the cpudyn RPM from Dag Wieers's repository at http://dag.wieers.com/packages/cpudyn/.
If your laptop battery is not performing as it should, check the battery state. It's available in the /proc/acpi/battery directory. Each battery, BAT1 and BAT2, includes an info file. When fully charged, the design capacity should equal the last full capacity. The first few lines of my HP laptop's state file show a problem:
present: yes design capacity: 4400 mAh last full capacity: 3840 mAh
This suggests I may not have followed good battery-management practices, which include discharging and recharging the battery completely during the first few uses. Most Linux desktop GUIs include a battery-management applet, which you can use to monitor your system. I describe how you can configure desktop GUI applets in Chapter 1.
Personally, I'm rather annoyed with the current state of wireless connections from Linux. With precious few exceptions, you can't just plug and play an 802.11g card on a Linux laptop computer. As we move toward Intel's "World Without Wires," Linux is going to have to handle 802.11a/b/g and even "WiMAX" (802.16) network cards seamlessly. But for the immediate future, Linux geeks will often have to download and compile experimental drivers. If you take this approach, you'll have to recompile the kernel with modules every time you upgrade the kernel.
Fortunately, the need for Linux wireless card drivers has the attention of the hacker community. As of this writing, 4 of the top 10 Linux kernel projects listed on SourceForge are focused on specific wireless chipsets. I've managed to download and install "alpha" drivers on my laptop computer fairly easily. But it did require that I recompile my kernel. If this is too time-consuming, proprietary help is available from Linuxant (which happens to taint your kernel). A number of the hacking approaches are based on using an NDIS wrapper around an existing Windows XP driver. You'll need to configure your kernel source code with loadable modules. I cover recompiling the kernel in "Recompiling the Kernel" in Chapter 7.
As for packages, make sure you've loaded the appropriate wireless-tools RPM or DEB package. If you're working with a wireless PCMCIA card on a Linux 2.4 kernel, you'll also need the kernel-pcmcia-cs associated with your current kernel. If you're running a Linux 2.6 kernel, the PCMCIA tools are integrated into the kernel source code.
Tip
Some wireless card drivers are also integrated into the latest kernels. For example, after I drafted this chapter, the drivers for the internal laptop Centrino wireless cards were integrated into Linux kernel 2.6.14.
The main sponsor of Linux wireless network cards is Absolute Value Systems. You can browse the work they've collected online at http://www.linux-wlan.com. The basic database of wireless cards and their Linux status is available online at http://www.linux-wlan.org/docs/wlan_adapters.html.gz. Another great resource is maintained at http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html.
As of this writing, precious few cards support the linux-wlan project. If possible, purchase these cards. Your budget will go toward companies that support Linux, and you're more likely to have trouble-free installations; many of these cards are described in the aforementioned databases.
If you're willing to use Microsoft Windows drivers, one more alternative is the NdisWrapper project, available online at http://ndiswrapper.sourceforge.net.
Tip
If you're having problems with an installed wireless card, refer to "I'm Having Trouble Connecting to an Existing Network" in Chapter 7.
If Linux doesn't automatically detect your wireless card, you'll first need to identify it. What you see on the package may not correspond to the actual chipset in the card. When you find drivers for your card, you need to know the chipset.
If detected, you should be able to find the card in the output from the lspci -v or scanpci commands. If you have a Red Hat distribution, you might also find it in the /proc/pci file. The output is fairly straightforward; for example, the lspci -v command on my desktop computer gives me the following information about my wireless card:
01:0d.0 Network controller: Texas Instruments ACX 111 54Mbps Wireless Interface
Subsystem: Abocom Systems Inc: Unknown device ab90
Flags: bus master, medium devsel, latency 64, IRQ 9
Memory at f4102000 (32-bit, non-prefetchable) [size=8K]
Memory at f4120000 (32-bit, non-prefetchable) [size=128K]
Capabilities: [40] Power Management version 2As you can see, this is an 802.11g wireless card, based on the Texas Instruments ACX 111 chipset. It's actually a card from another manufacturer, who uses the TI ACX 111 chipset, which I got at a discount store. (As of this writing, that particular chipset is proprietary.) Shortly, I'll show you what I did to install open source drivers for this card.
If you have a PCMCIA card, you should see it detected in the output from the cardctl ident or pccardctl ident command. You may not be so fortunate. As described earlier in the "Linux Won't Work with All My Hardware" annoyance, older Linux 2.6 kernels have had trouble with respect to managing power and some wireless network cards. In that case, you might not even see output from the card. If your kernel and card are not affected by this problem, you may get specific output. For example, I got specific output from one laptop:
Socket 0: product info: "Realtek", "Rtl8180" manfid: 0x0000, 0x024c function: 6 (network)
But less output from another:
Socket 0: no product info available manfid: 0x0007, 0x0082
Fortunately, if you can identify the controller and chipset from the PCI interfaces, you're set. If Linux doesn't detect your card at all, there are alternatives.
Make sure the card is physically secure in its slot. If the card is internal, such as with a regular or mini-PCI card, turn off your computer first.
If available, check detection in another operating system, such as Microsoft Windows.
Use the documentation for your card. Chipsets are often listed in paper documentation, or even on the physical hardware. But be careful; manufacturers have been known to change chipsets at different revision levels of the card.
If you're fortunate, the drivers for your wireless card are included with your Linux distribution and were detected during installation of the native network configuration tools. But this is not the case for the majority of wireless network cards. In this case, you'll need to find and probably install drivers on your own. There are several basic steps to this process:
Check to see if your network card is detected and/or configured; the most straightforward method is with the ifconfig -a command. In some cases, you'll see your network card as device wlanx, athx, or ethx. If you don't see an IP address, all you may need to do is configure IP addressing for your card, which you can do with the same basic commands (such as ifconfig) as with a regular network card.
If your network card is not configured, Linux may have still detected it. You'll need the manufacturer and chipset. You may be able to get this information from your documentation, with the lspci -vv or scanpci commands, or from data in /proc/pci. If it's a PCMCIA card, try the cardctl ident or pccardctl ident command.
Once you find a manufacturer and chipset, search through available databases. Start with the database available from http://www.linux-wlan.com.
If this doesn't help, you can check for Linux support from the manufacturer's web site. You may be able to download driver modules, which you can install with the appropriate insmod or modprobe commands and configure to install automatically upon rebooting in /etc/modules.conf. Sometimes complete open source drivers are available online. A web search is usually the best bet for finding such drivers.
Tip
The Debian Sarge version of /etc/modules.conf loads modules from different configuration files in the /etc/modultils directory. The default versions of the major configuration files in this directory provide guidance in their comments. Add the module command that you need to the appropriate file in this directory.
Some Linux distributions (e.g., SUSE) support access to binary drivers without source code. If you accept, you will "taint" your kernel with non-GPL code. Unless you're a Linux purist or otherwise need a consistently licensed kernel, this just makes it easier to manage your system.
If all else fails, you're now in the realm of developmental drivers: alpha and beta drivers associated with your wireless network card's chipset. If Linux drivers are in work, they may be available through Source Forge (http://www.sf.net).
In many cases, if you want to get a wireless network card working on your Linux computer, you'll need to install developmental drivers. Often, these beta- (and even alpha-) level drivers work as well as any stable kernel module. I've installed alpha drivers from a TI ACX100 SourceForge project to enable wireless "no name" cards with this chipset on my laptop and desktop computers.
Generally, you'll need the tools associated with compiling the kernel to install developmental drivers. I go into detail on basic requirements in Chapter 7. While most software for the major Linux distributions is compiled into binary RPM and DEB packages, test software is often available only as compressed archives in tar.gz or tar.bz2 formats. You need to know how to decompress such packages. For example, when I downloaded drivers for the ACX100 chipset, I downloaded a package named acx100-0.2.0pre8_plus_fixes_37.tar.bz2, which I then unpacked in my home directory with the following command:
tar xjvf acx100-0.2.0pre8_plus_fixes_37.tar.bz2
Alternatively, if the package were in tar.gz format, I'd use a command such as tar xzvf acx100-0.2.0pre8_plus_fixes_37.tar.gz. But I won't go into detail, as these are basic skills for the Linux geek. The result is unpacked to a subdirectory with the same filename. For example, if I downloaded to the /home/michael directory, I'd find the source for the wireless drivers in the /home/michael/acx100-0.2.0pre8_plus_fixes_37 subdirectory.
If you've installed the source code associated with the current kernel and configured loadable modules, you should be able to compile the downloaded wireless drivers into your kernel. The basic steps vary and should be documented in a file such as INSTALL or README in the driver package. There are three basic steps:
Remove the modules associated with older versions of the same driver. For example, if you've installed drivers with abc in their names, you can find them in the active kernel module directory with the following command:
find /lib/modules/`uname -r` -name "*abc*"
Prepare the package with the new drivers. Follow the directions in the applicable INSTALL or README files.
Install the package per instructions; normally this is done with a make install or make command.
Next, you'll have some sort of script to activate your wireless card. If you've installed drivers from an RPM or a DEB package, the script commands may already be installed. Run the script as documented in the package. To make sure the script runs the next time you boot Linux, you'll need to add it to a user start script. Standard administrator configurable start scripts vary by distribution; start scripts for our three distributions are shown in Table 5-4.
Table 5-4. Startup scripts for user commands
Distribution | Script filename |
|---|---|
Red Hat/Fedora | /etc/rc.d/rc.local |
SUSE | /etc/init.d/boot.local |
Debian | /etc/init.d/local |
If the file in question does not yet exist, you'll need to create it. Start with the command for your preferred shell; the following works for the default bash shell:
#!/bin/sh
Then proceed with the full path to the script that activates your wireless card. Alternatively, if you've loaded modules, you'll want to make sure they load the next time you boot, by adding desired modules to /etc/modules.conf or /etc/modprobe.conf. Debian discourages direct editing of this file; you can configure modules in this distribution in one of the files in the /etc/modutils directory.
At last count on http://www.linux.org, there were over 350 different Linux distributions. In an annoyance-free world, everyone could download her favorite distribution and get courteous and free support from the wide variety of Linux geeks dedicated to support online. So much for the perfect world!
Many people think of Linux as a free operating system. Linux geeks know that isn't quite true. Support takes time, which is valuable. Many Linux distributions, including Red Hat and SUSE, provide fee-based support for licensed installations of their distributions. If you're willing to get your support directly from the community, there are alternatives to the well-known licensed Linux systems.
Red Hat network entitlements are expensive. They start at $179 for Red Hat Enterprise Linux WS (workstation) and can reach above $2,500 per system for Red Hat Enterprise Linux AS (advanced server). While Red Hat is the "name brand" Linux distribution, there are ways to get the same software for the cost of support. Novell's support fees for SUSE are similar: they start at $60 for SUSE 10.0 and can reach $14,000 for SUSE Linux Enterprise Server 9 for IBM Z Series servers.
Red Hat's move away from standard supported distributions has dismayed a significant part of the Linux community. However, Red Hat continues to release the source code for all but the proprietary packages of their Enterprise distribution. This means the Linux community has access to the same software that Red Hat is licensing. Similarly, SUSE releases many of the binary packages for its latest workstation and server distributions, with ISOs available some weeks later.
As a Linux geek, you probably already know something about the variety of available Linux distributions. You may already have your favorites. In most cases, distributions organize packages in one of two camps: RPMs or DEBs. In other words, they work with the RPM Package Manager or the Debian package system.
In this book, we've focused on Red Hat/Fedora, Novell/SUSE, and Debian. This is patently unfair to the wide variety of available distributions. I've included in Table 5-5 an arbitrary sample of alternative distributions that include some level of support, assuming you've purchased an official version of their product. The list is less than fair, as it does not mention many of the benefits of distributions such as Knoppix and Ubuntu (both derivatives of Debian). A more complete list is available from http://www.linux.org/dist/list.html.
Table 5-5. Alternative Linux distributions
Name | URL | Support | Comments |
|---|---|---|---|
Gentoo | Mailing lists | Focused on developers and power users; uses portage for package management | |
Mandriva | Support incidents | Based on the merger of Mandrake and Conectiva | |
Knoppix | From knopper.net in Germany | Based on Debian Linux | |
Slackware | Support providers listed on web site | From Patrick Volkerding | |
Yellow Dog | Phone, install, and mailing list | For PowerPCs; home of yum | |
Turbolinux | Limited installation support | Largest distribution in Asia | |
Linspire | Email and on-call support | Formerly known as Lindows; sold with Wal-Mart PCs | |
Ubuntu | Focused on usability in all languages | Based on Debian Linux | |
Xandros | Email support | Also known for compatibility with Microsoft Windows; based on Debian |
Red Hat builds the software for its distributions from source code, organized in source RPMs. Red Hat releases this enterprise-quality source code on public FTP servers. When others compile this source code into a distribution, it is known as a "rebuild." The process is considerably more complex than just compiling source RPM files.
Several groups have sprung up to provide "rebuilds" based on Red Hat Enterprise Linux source code. I personally prefer the cAos rebuild (http://www.caosity.org), as the cAos Foundation keeps its rebuilds up-to-date with the latest Red Hat Enterprise Linux 3/4 updates. (Its rebuilds of these distributions are officially known as CentOS-3/CentOS-4.) While others have also kept their "rebuilds" up-to-date, cAos at this time appears to have the most active community. But even with volunteers, maintenance and download servers are expensive, and cAos has requested that users contribute $12/year per system.
I've found the cAos updates are available about a month after Red Hat releases its updates. While cAos has modified the icons and other graphics to avoid Red Hat trademarks violations, the software is identical to what is released in Red Hat Enterprise Linux 3/4 in almost every respect. One exception is that it uses the yum (Yellow Dog Updater, Modified) for updates, as is done with Fedora Linux. Others follow a similar model. Table 5-6 lists a few Red Hat clones, along with their web sites.
Table 5-6. Rebuilds of Red Hat Enterprise Linux
Name | URL | Notes |
|---|---|---|
CentOS | Author preference | |
White Box Linux | First with an official rebuild | |
TaoLinux | From Alfred University, New York | |
Lineox | European distribution; CDs/apt-based support available from its web site | |
Scientific Linux | Based on a consortium of labs and universities | |
Rocks | Configured for cluster management; CDs available through CheapBytes |
If you need an official level of support, there are alternatives to Red Hat. Progeny supports the most recent versions of Red Hat Linux (8 and 9), released before 2003. cAos has links to corporate levels of support at www.caosity.org/support/commercial. But if you are a Linux geek, you may be able to support your Red Hat Enterprise Linux 3/4 rebuild installations on your own, with a little help from the community, as described in the next annoyance.
Tip
The third-party rebuilds of Red Hat Enterprise Linux are an inexpensive way to practice for the Red Hat certifications. For more information, see http://www.redhat.com/training/certification.
So many distributions, so little time. What makes downloading new distributions more difficult is the lack of high-speed connections. Even in the U.S., half of all users still primarily use telephone modems. I once tried to download the ISO files associated with an older Red Hat distribution over a telephone modem. After three days of stops and starts, the ISO I downloaded was corrupt and unusable.
For those of us without a T3 level (45 Mbps) connection to the Internet, downloads can take hours. Standard DSL connections may be barely satisfactory for some. When I had a DSL connection, it typically took three hours to download the data for a single CD. Cable modem connections are often faster; if I downloaded at an optimum time, I might be able to download the data for a CD every hour. But God help me if others in the neighborhood are downloading music or movies.
One option is to wait until your favorite distribution is available on CD from a third party such as http://www.cheapbytes.com or http://www.linuxcentral.com. They often have the most popular distributions available for purchase within a week of release. If you don't have the time or bandwidth, this is a viable option.
If you're downloading SUSE Linux on DVD in the USA, don't download all 7 GB from the SUSE servers in Germany. You're pulling traffic over routers and heavily used backbones between yourself and Germany. Data slows down when it runs into traffic. It may have to wait for other data with people who've paid more for Quality of Service (QoS). It's best to find a mirror where you can download closer to where you are (or use BitTorrent, described in the next section).
Every major Linux distribution has a list of mirrors. As long as the mirror is up-to-date, it's best to pull your distributions from it for two reasons:
- Speed
The closer you are to what you're downloading, the less chance there is for a delay due to traffic at an intermediate router.
- Cost
Downloads are billed to the repository. Several popular volunteer sites (including Debian) limit direct downloads to keep their costs down.
Tip
When you have a subscription to Red Hat Enterprise Linux, you can download the CDs only through your Red Hat Network account, and updates through the official Red Hat Update Agent server.
Linux distributions include updates. Whether you have a subscription to the Red Hat Network, or are using a participatory distribution such as Debian or Fedora, updates are frequent. You may be able to upgrade critical components for new features or security. Most distributions allow you to update through a mirror site. Be sure to keep your /etc/apt/sources.list or /etc/yum.repos.d files up-to-date with the latest update repositories.
A number of distributions support downloads via BitTorrent, which is a peer-to-peer protocol for file transfers. As more clients download a specific file, there are more peers available. With BitTorrent, you can set up a download from multiple sources, which can maximize the speed of the download. More popular downloads support faster BitTorrent speeds.
If it isn't available for your distribution, you can download the basic BitTorrent software from the associated home page at http://www.bittorrent.com. The BitTorrent commands are written in Python. Versions are also available for Microsoft Windows and Apple Macintosh. Once installed, the applicable commands on several distributions have .py extensions.
If you have a firewall on your network, you'll need to open a range of TCP ports for BitTorrent: 6881-6999. You'll need to open these ports before starting any BitTorrent download.
Once you start a BitTorrent download, you'll need to be patient. It takes time to find clients who have already downloaded a desired file with this system. But once you've connected to a group of others, your BitTorrent speed can be impressive. For example, the following download of a Debian Sarge CD is proceeding at about three times the speed of a standard midday download through my cable modem, as shown in Figure 5-1.
You can use a GUI such as Azureus to help you monitor your downloads. Some BitTorrent packages include a btdownloadgui script that makes the process easy, as shown in Figure 5-2.
Alternatively, you can open a download directly from the command-line interface. For example, I've downloaded the first Sarge CD torrent file to my /tmp directory. If I then wanted to join the "Torrent" for the first Debian Sarge CD, I'd run the following command:
btdownloadheadless /tmp/sarge-i386-1.iso.torrent
Once you've downloaded the CD, keep BitTorrent open as long as possible. The BitTorrent system does not work unless you share—in other words, unless you allow others to download parts of the file from your system.
Tip
One popular alternative to BitTorrent is Jigdo, the Jigsaw Download tool, which is supported by Debian Linux. Download the jigdo or jigdo-lite packages. Make sure you have version 0.6.8 or above. The jigdo-lite command is straightforward; it prompts you for a .jigdo file, which is available from http://cdimage.debian.org. It follows up with a prompt for a Debian mirror site. Jigdo works in the background and takes care of the rest.
As a Linux geek, you have to be ready in case the people you're working with want to install Linux on a substantial number of computers. And it would be supremely annoying to be up all night running installation programs on each individual computer. There are four sensible steps that you should take before installing Linux on a large number of computers:
Test the desired configuration on one computer. Document any changes that you make.
Create or use an existing configuration file to automate a new installation. Modify to match any changes you make to the test computer.
Test the new configuration file, by using it to install Linux on a second computer. Document any problems. Modify the configuration file to make required changes.
Repeat step 3 until the configuration file allows you to install Linux automatically on the computer of your choice.
Different Linux distributions include tools that can help. Red Hat has Kickstart. SUSE has AutoYaST. Debian uses the Fully Automatic Installation (FAI) tools. While some of these tools can work with bootable network cards, you may not be lucky enough to have them in your environment.
With these tools, you can automate the installation of Linux on other computers. If you have 100 identically configured computers and a DHCP server on a network, you can set up a single installation process that works automatically for those computers. Test your favorite Linux on one computer, configure it to your needs, and replicate this process on other computers. Yes, you could use disk mirror tools as well, but that requires you to physically move the disks, etc. If there is a hardware defect on one of the 100 systems, you may not know it until you get a user complaint.
As a Linux geek, you may already be familiar with Progeny Linux (http://www.progeny.com). Ian Murdock (one of Debian's founders) created Progeny to bring Linux, and primarily Debian Linux, to more people. Progeny uses open source tools; they're in the process of porting Red Hat's Anaconda and Kickstart tools. Thus, in this section, we'll limit our solution to the basic procedures for Kickstart and AutoYaST.
Kickstart is still a work in progress for Progeny Debian as of this writing. Progeny has announced that Kickstart will be a part of its next release. It is consistent with Progeny's decision to adapt Anaconda as the primary installation program. Hopefully Kickstart for Debian will be ready by the time you read this book, possibly for the Debian-based enterprise distribution. (Ubuntu already uses Kickstart.) Alternatively, you might consider SystemImager (http://www.systemimager.org) or the aforementioned FAI (http://www.informatik.uni-koeln.de/fai/).
Kickstart is a straightforward tool. If your test computer is perfect and does not need tweaking, you can almost take your original Red Hat (or Debian) configuration Kickstart file, add it to a boot disk, and install away on the computers of your choice. When you install a Red Hat distribution on a computer, it includes the current configuration in /root/anaconda-ks.cfg . We'll take a brief look at my version of this file, with things you may need to modify for your situation. Here are the first few commands:
install nfs --server=server.example.com --dir=/mnt/fedora lang en_US.UTF-8 langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us
The second command, which specifies a network installation, is critical. NFS has the advantage over FTP and HTTP; besides being most efficient, you can copy the Red Hat installation CDs to the directory that you're sharing over the network as .iso files. Alternatively, if you use cdrom on this line, you'll need installation CDs for each computer.
xconfig --card "Intel 810" --videoram 16384 --hsync 31.5-37.9 --vsync 50-70 --resolution 800x600 --depth 24 --startxonboot --defaultdesktop gnome network --device eth0 --bootproto dhcp --hostname Fedora3 rootpw --iscrypted $1$2l6AeSZr$54N4e4kuMQFYiZnuxDdxw0
The xconfig command appears on two lines in
this book because it's long. It specifies an automatic boot into the
GUI by setting the id variable in
/etc/inittab to runlevel 5. The network command
could be annoying; it sets up Fedora3 as the
hostname of every computer. You could leave out the
--hostname Fedora3 option if your DHCP server
assigns hostnames. The rootpw command can carry
an encrypted password, which you can copy from
/etc/shadow, assuming you've configured the
shadow password suite on your computer. For more information on how
you can use the shadow password suite, see the "Too Many Tasks, Too Few
Qualified Administrators" annoyance in Chapter 10.
firewall --disabled authconfig --enableshadow --enablemd5 timezone America/Los_Angeles bootloader --location=mbr --append="rhgb quiet"
Most administrators disable a firewall on a computer within a LAN. In any case, a computer that serves as a firewall should get special attention and not be configured using Kickstart. The authconfig command enables the shadow password suite, with MD5 encryption. The computers on your network are probably all in the same time zone. Unless you have another bootloader, the MBR is the best place for it. Red Hat now appends the rhgb quiet command to the kernel; regular users might be confused by standard kernel messages. This configuration is for systems with SCSI disks; the sda name below is the standard name for the first SCSI drive.
#clearpart --linux --drives=sda #part /boot --fstype "ext3" --size=100 --ondisk=sda #part pv.8 --size=0 --grow --ondisk=sda #volgroup VolGroup00 pv.8 #logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=5024 #logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=256 --grow --maxsize=512
You can't use this file to automate installation until you activate the preceding commands. This particular set of commands configures a standard ext3 partition for the /boot directory, with logical volumes and given sizes for the root directory (/) and swap partitions.
%packages @ office ... @ graphical-internet kernel e2fsprogs grub lvm2
The package selection list is straightforward; I've abbreviated
it to save space. In the preceding lines, I see the Office and
Graphical Internet package groups, which are defined in Red Hat's
comps.xml file. Red Hat organizes its RPM packages in
groups in a file named comps.xml, in the first
installation CD's /
Package /base
subdirectory, where Package is
Fedora or RedHat. As the
file's name suggests, it's in XML format. During the installation
process, Red Hat's Anaconda installer presents these package groups to
the administrator so you can choose which you want to install.
For example, here is an excerpt from comps.xml for Red Hat Enterprise Linux 3. A number of intermediate XML comments and commands have been omitted for brevity. As you can see, Red Hat's Office group includes several packages over and above openoffice.org:
<group>
<id>office</id>
<name>Office/Productivity</name>
......
<grouplist>
<groupreq>base-x</groupreq>
</grouplist>
<packagelist>
<packagereq type="default">openoffice.org</packagereq>
<packagereq type="default">xpdf</packagereq>
<packagereq type="default">ggv</packagereq>
<packagereq type="default">mrproject</packagereq>
<packagereq type="optional">kdepim</packagereq>
<packagereq type="optional">kdegraphics</packagereq>
<packagereq type="default">tetex-xdvi</packagereq>
</packagelist>
</group>We also see the kernel, e2fsprogs, grub, and lvm2 packages listed separately because they are not a default part of any Red Hat package group.
If you've added software while testing your Linux system, you'll need to add that information to this list. Red Hat also provides a GUI configuration tool for ks.cfg: system-config-kickstart or redhat-config-kickstart.
Once you've configured the Kickstart file with desired settings, save it to ks.cfg. Next, you'll want to copy this file to a shared directory. You can use the same shared directory that the installation files are in.
Now you can test the result on a new computer, with the following steps:
Make sure the computer properly connected to your installation server via the network.
Set it to boot from the CD.
When you see the
boot:prompt, you can get Kickstart to read from your ks.cfg file.Once you've copied it to the installation server, you can use the following command:
boot: linux ks=nfs:server.example.com:/mnt/fedora/ks.cfg
Similar options are possible from ks.cfg files on a floppy disk or embedded on the CD.
Note the %post tag at the bottom of
the Kickstart configuration file. You can add commands to further
configure servers. For example, you might use it to copy key
configuration files, such as for Samba servers.
SUSE also has a tool for automated installations called AutoYaST. It's available through YaST2, SUSE's Yet another Setup Tool. You can start it from the command line with the /sbin/yast2 autoyast command, or by selecting "autoinstallation" from the miscellaneous options in the graphical YAST tool. Unless you're familiar with SUSE's XML tags, I recommend that you use AutoYaST to configure the autoinstallation file.
If you don't see the AutoYaST module, you probably need to install the associated RPMs: yast2-trans-autoinst, yast2-config-autoinst, and yast2-module-autoinst.
As with Kickstart on Red Hat, you can configure a reference profile based on the local computer. To do so, open YaST. Navigate to the Misc menu, where you can start the Autoinstallation tool. Then click Tools → Create Reference Profile. It opens the Create a Reference Control File menu shown in Figure 5-3. Select the services that you need, and the appropriate settings will be copied to the Reference Control File.
Once created, you can modify the Reference Control File or save it via the File menu.
To set up your AutoYaST installation media, you'll need to
make sure that you copy all of the CDs to the installation server.
To make sure the client sees the server as a single installation
source, run the following Perl command, where
inst is the directory with the SUSE
installation files:
perl -pi -e 's/InstPath: \t\d+/InstPath: \t01/' /inst/suse/setup/descr/common.pkdNow you can share the /inst directory.
NFS is usually best for this purpose. Then, to configure a network
installation, copy the autoyast.xml file to the boot media. To make sure the
client looks at the installation server, configure an info file. You
can include this information within the <init> tags, with an <info_file> tag:
<init> <info_file> install: nfs://192.168.0.1/inst/suse netdevice: eth0 server: 192.168.0.1 serverdir: /inst/suse autoyast: 192.168.0.1/inst/autoinst.xml </info_file> </init>
Then when you boot the SUSE installation program, enter the
following command, where autoyast.xml is on the
shared NFS directory from
server.example.com:
linux autoyast=nfs://server.example.com/instI believe that Linux geeks are helpful. They'll take time that they don't have to help you with an interesting problem. They love good questions, as they can help them learn more about Linux. On the other hand, many Linux geeks are strong-willed. They are not known for social graces. In short, Linux geeks (other than yourself) can be annoying. But if you do your homework and treat the Linux community with dignity and honor, you can keep annoyances with Linux geeks to a minimum. While there are no guarantees, you'll probably get a better response from the Linux community if you follow these principles:
If you're learning to do something, read the associated HOWTO. Learn the associated manpages. If you're having a problem, read the appropriate logfiles in your /var/log directory. For example, if you're having a problem with Windows file sharing, review the newest files in the /var/log/samba directory. Examine the error messages. Use Google and Google Groups (http://groups.google.com) to search the Web and associated newsgroups for others who've had the same problem. I often search quoting the same or similar error messages. I've found at least a few others who've had similar problems almost every time. There are other sites with Linux-dedicated message boards, which may also be helpful. Be prepared. Know (and be able to cite) your relevant hardware. Have key configuration and logfiles handy.
Use your favorite Linux book! Many are available from O'Reilly and other reputable publishers. Even this author has written other Linux books with more detailed information.
If you've done your homework and still need help, there are several options:
If your Linux distribution comes with support for your problem, use it. You've paid for it!
If your Linux distribution has mailing lists or IRC channels, ask your question there, using the guidelines described in the next section.
If you're working with a specific service, there may be a mailing list or newsgroup associated with that service. For example, Samba has their own mailing lists, and there are several newsgroups focused on that service.
There are perhaps thousands of mailing lists and newsgroups available on different subjects associated with Linux. Selecting the right newsgroup or mailing list can save time and help you get the answers as quickly as possible. When looking for answers, follow these guidelines:
Look for the right group. For example, it's not a good idea to ask a question about the DEB packaging system on a Red Hat newsgroup. Most of the readers (and even many of the gurus) won't have the experience that you're looking for to answer your question. And they will not hesitate to tell you so, sometimes in less-than-polite terms.
Make sure the group is active. There are a lot of inactive newsgroups. If few people see your question, you're not likely to get a response. Review the latest newsgroup headers, and check the dates.
Read over previous messages on the newsgroup. If you're comfortable with the level of expertise, proceed with your message. See "Posting Guidelines for Newsgroups and Mailing Lists," later in this annoyance, for some posting rules of thumb.
There are a substantial number of mailing lists dedicated to Linux. Many are organized by distribution (see the following table). When you sign up for a mailing list, you're getting an account on that list. Remember, these lists are by and large staffed by volunteers. If you want to unsubscribe, use your account. Alternatively, check the bottom of the message. Unsubscribe information is often also available there.
Distribution | Mailing list |
|---|---|
Red Hat | |
SUSE | http://www.suse.com/us/private/support/online_help/mailinglists/ |
Debian |
Users often get frustrated with the volume of messages on some mailing lists, such as the main Fedora Linux list. Many have asked the Fedora group, in a message to the whole list (thousands of people), for instructions on how to unsubscribe. The Fedora lists put instructions on how to "unsubscribe" at the bottom of each message. Unless you've tried and are having problems with the instructions (which may indicate a problem with a server), and cannot identify a mailing list administrator, it is bad form to ask the group to unsubscribe you from any mailing list.
Almost as annoying are the mailing-list subscribers who inadvertently send their vacation messages to the entire mailing list. Without the proper settings, a user's vacation message is sent as a reply to every mailing-list message. Don't get caught with this problem.
Linux users and geeks ask for help all the time. It is axiomatic; the only stupid question is the one that is not asked. However, there are unhelpful ways to ask a question, many of which will irritate the average Linux geek. Some (sanitized) examples include:
"I can't hear sound after installing Fedora. What do I do?"
"cdrecord doesn't work."
"I am a beginner who wants to get RHCA."
These are examples of unspecific generic questions, which make it difficult for others to help. If they're peeved enough, a likely answer is an admonishment to "Do your homework before asking another question!" Less chastising would be a link to standard documents such as the Sound and CD-Writing HOWTOs, available from http://www.tldp.org. The thought of a Linux beginner who wants to pass the Red Hat Certified Architect (RHCA) exams might lead to derisive laughter, or a link to the Red Hat home page for this newest and most advanced certification.
There are correct ways to ask a question on a newsgroup or mailing list. What I cite certainly isn't the only way. You may already be experienced with newsgroups. But remember, there are a whole army of Linux geeks who have trouble with newsgroups and commonly end up in flame wars.
When you have a new problem, start a new thread. Direct your message directly to the mailing-list address.
Stay focused on one topic. For example, if you ask unrelated questions about Samba and DVD movies on one thread, it will be more difficult for others to respond.
Summarize your topic or problem in the subject line. Keep it short. Subject lines that are too long are more likely to be deleted.
Provide a brief description of your problem. If there's a service involved, include key lines from the appropriate configuration file. Don't overdo it. For example, the contents of /var/log/syslog would overwhelm most readers with irrelevant info; most will avoid your message. And if you have personal information and/or encrypted passwords, do leave them out of your message.
List the versions of the applicable software or services. Others need to know what you're working with.
State what you've done to try to solve the problem.
List the resources that you've read—such as HOWTOs, FAQs, and documents—in your efforts to solve the problem.
If you're seeing errors, include key lines from logfiles. Boot messages can be found in the dmesg output. Service messages are normally listed in specific logfiles or directories. Other errors can be found in /var/log/messages. Don't include the entire output of your /var/log/messages file; mine are typically text files with tens of thousands of lines (which corresponds to several MB of data).
There is also a right way to answer questions on a newsgroup or mailing list. As a Linux geek, you are part of a community. You have a responsibility to share what you know. It's like participating in a democratic society. If you can help someone who needs help with Linux, you're contributing to the success of this operating system:
Just as you should keep your questions as short as possible, keep your responses short. If you know that the answer is available in another document, such as a HOWTO, it's appropriate to cite that document.
Don't feel obligated to answer all questions associated with the message. If you only know the answer to one of the questions, it's OK to just answer that question. Edit out the other issues, and include your answer inline or after the end of the message.
By convention, Linux users post responses at the bottom of a message. This allows others to read archived messages with the problem at the top and the solution at the bottom.
There are a number of basic guidelines that can help you cope in the world of Linux geeks. Some are well known, such as avoiding the use of caps so others don't think you're shouting. Here are some additional guidelines:
Don't post in HTML. A number of Linux geeks use text-based messaging solutions. HTML email can foul up such clients.
Don't hijack the threads of others. Mailing lists are organized in threads. When you have a new topic, it's best to start with a new message. For example, new messages to the main Fedora mailing list should be sent directly to fedora-list@redhat.com. As an example, assume there's a current thread on sound cards, and you want to ask the group about graphics settings. If you use the "Reply" function on an email client such as Kmail, Evolution, or (heaven forbid!) Outlook Express, your reply will show up as part of the sound card thread, even if you change the subject line.
Avoid cross-posting where possible. Cross-posting is when someone posts the same message on multiple mailing lists. Many Linux gurus often subscribe to a large number of mailing lists. If they see your message multiple times, they're less likely to help.
Limit the length of your lines. More than 72 characters per line can make it difficult for some to read your message in their email readers.
When you answer a message, edit it and leave the relevant questions. This minimizes the size of the email. Answer the message inline. This makes it easier for the reader to associate your answer with the question at hand.
If you must have a signature line, keep it short. Start them with a delimiter; a standard is a couple of dashes followed by a space (-- ). Many newsreaders take this delimiter to strip out the signatures.
A flame war is when deliberately hostile messages are posted on a mailing list or discussion board. It's easy to say "Don't get involved in flame wars." It can be difficult to put into practice, especially if you feel passionate about a topic. And many Linux geeks are passionate about their beliefs. There are several principles you can follow that can help keep a flame war from becoming personal:
Don't be afraid to step away. Online discussions move quickly, and anything that you may have said is usually quickly forgotten.
Focus on the subject. Do not attack the person.
Keep looking at how to solve the problem at hand.
State your opinions clearly. Experiences differ. You can speak to your own experience. Do not try to speak for others.
Avoid discussions beyond your expertise or experience. For example, it's usually not helpful to say "copying this software breaks the law" unless you are a lawyer with expertise in that particular area of the law. And if you do have that kind of expertise, you should know that expressing such opinions could get you into a different kind of trouble.
And again, don't be afraid to step away from a flame war. There are more important things in life.
Not all flame wars are bad. Many become serious academic discussions about software—for example, the important discussions between Andrew Tannenbaum (the creator of Minix) and Linus Torvalds on the use of microkernels and monolithic kernels in the operating system. If you get involved in a flame war expecting a serious academic discussion, be careful. Not everyone can conduct a debate like Tannenbaum and Torvalds—or, for those of you familiar with U.S. history, Lincoln and Douglas.
Tip
Abraham Lincoln and Stephen Douglas conducted a series of debates in the mid 1800s, a few years before the American Civil War, that stand in the annals of political history. Each of their debates lasted several hours and held the interest of the many thousands who watched it live (and out of doors). Even though they were vigorous political rivals, they remained friends throughout. Douglas supported Lincoln after he became president of the United States in his efforts to keep the U.S. together. If you think you can manage a debate like Lincoln or Douglas . . . .
If you are a Linux geek, there will be times where nobody will be able to answer your question. If the previous steps have failed, it's time to post a bug report, more commonly known as a Bugzilla. A Bugzilla is a single bug or feature request, documented on an appropriate list of bugs for a Linux distribution, application, or service. There are guidelines to Bugzilla reports as well:
Check the current Bugzilla database. Someone may have already reported the problem.
Make sure your problem is reproducible. A hacker can't help you if he can't reproduce the problem on his own PC. Document the steps you took when you encountered the problem.
Report the issue to the proper developers. If you're having a problem with the functionality of OpenOffice.org Writer, it's generally less helpful to report it on the Debian bug list. The people who need to see it are the developers of OpenOffice.org Writer.
Note the distribution and packages in question. Linux distributions are large. Different developers have responsibility for different packages. Bugzilla procedures often prompt you in this process.
Some Bugzilla reports are feature requests. If you want action, be realistic. Don't ask for a service that creates world peace. Do ask for features that can improve a product. One simple example of a feature request that I made was to Red Hat's X Configuration tool. I asked that the associated configuration file note whether it was created by Anaconda (the Red Hat Installation tool) or the post-installation configuration tool (system-config-display).