Linux System
Administration I:
Implementation
(Course code LX03)Student Notebook
ERC 6.0IBM certified course material
January 2009 edition
The information contained in this document has not been submitted to any formal IBM test and is distributed on an “as is” basis without any warranty either express or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer’s ability to evaluate and integrate them into the customer’s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will result elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk.
Trademarks
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both:
VMware® and the VMware "boxes" logo and design, Virtual SMP and VMotion are registered trademarks or trademarks (the "Marks") of VMware, Inc. in the United States and/or other jurisdictions.
PS/2® is a trademark or registered trademark of Lenovo in the United States, other countries, or both.
Adobe and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
Intel, Intel Xeon, Itanium, Pentium and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Linux® is a registered trademark of Linus Torvalds in the United States, other countries, or both.
AIX® AS/400® AT®
Balance® BladeCenter® Chipkill™
DB2® Domino® eServer™
General Parallel File System™
GPFS™ i5/OS®
iSeries® LoadLeveler® Lotus®
MVS™ Notes® OpenPower®
OS/2® OS/390® OS/400®
POWER™ POWER4™ PowerPC®
pSeries® RS/6000® S/390®
SP™ System i™ System i5™
System p™ System p5™ System x™
System z™ System z9® Tivoli®
XT™ z9™ z/OS®
UNIX® is a registered trademark of The Open Group in the United States and other countries.
AMD and AMD Opteron and combinations thereof, are trademarks of Advanced Micro Devices, Inc.
Trademarks . . . xiii
Course description . . . xv
Agenda . . . xvii
Certification information. . . xix Unit 1. Advanced Linux installation . . . 1-1 Unit objectives . . . 1-2 Installing Linux: Review . . . 1-3 Disk partitioning: Review . . . 1-5 Network installations . . . 1-7 Network install server: Overview . . . 1-9 Network install server: Configuration . . . 1-11 RHEL/Fedora kickstart installations . . . 1-13 RHEL/Fedora kickstart example . . . 1-15 SLES AutoYaST installations . . . 1-17 AutoYaST example . . . 1-19 Checkpoint . . . 1-20 Exercise 1: Advanced Linux installation . . . 1-21 Unit summary . . . 1-22 Unit 2. Startup and shutdown . . . 2-1 Unit objectives . . . 2-2 Linux startup flow . . . 2-3 Basic Input/Output System . . . 2-4 Master Boot Record . . . 2-5 GRand Unified Bootloader . . . 2-6 GRUB startup sequence . . . 2-8 /boot/grub/grub.conf or /boot/grub/menu.lst . . . 2-9 Starting the kernel . . . 2-11 Initial RAM Disk . . . 2-13 init . . . 2-15 /etc/inittab (RHEL/Fedora/SLES) . . . 2-18 Starting services (System V init style) . . . 2-21 Configuring services per runlevel . . . 2-23 Starting and stopping services manually . . . 2-25 Booting Linux in single-user mode . . . 2-27 Shutting down a Linux system . . . 2-29 Checkpoint . . . 2-30 Exercise 2: Startup and Shutdown . . . 2-31 Unit summary . . . 2-32
Unit 3. System administration tools. . . .3-1 Unit objectives . . . .3-2 System administration tools . . . .3-3 RHEL/Fedora setup . . . .3-5 RHEL/Fedora system-config-* . . . .3-7 SUSE YaST . . . .3-9 Webmin . . . .3-10 Webmin rpm installation . . . .3-11 Webmin screenshot . . . .3-12 Users, printer queues, printers . . . .3-13 Common printing subsystems . . . .3-14 Common UNIX printing system (CUPS) . . . .3-16 CUPS overview . . . .3-18 CUPS configuration with lpadmin . . . 3-21 CUPS configuration with a browser . . . .3-22 CUPS configuration with system-config-printer . . . 3-23 CUPS configuration with yast . . . 3-25 CUPS configuration with kprinter . . . 3-26 Checkpoint . . . .3-27 Exercise 3: System administration tools . . . .3-28 Unit summary . . . .3-29 Unit 4. Package management . . . .4-1 Unit objectives . . . .4-2 Software management . . . .4-3 RPM Package Manager . . . .4-4 Software archives . . . .4-6 RPM-related commands . . . .4-8 RPM database files . . . .4-9 RPM installing, freshening, and upgrading . . . .4-11 RPM uninstalling . . . .4-13 RPM querying . . . .4-14 RPM verification . . . .4-16 RPM signatures . . . .4-18 RPM philosophy . . . .4-20 Creating RPMs . . . .4-22 Example Scenario: Hello, world! . . . .4-24 hello.spec preamble section . . . .4-25 hello.spec prep, build, install, and files section . . . .4-26 RPM build process . . . .4-28 After RPM build process . . . .4-30 Integrated package management . . . .4-31 Keeping up-to-date (Fedora) . . . .4-33 Keeping up-to-date (Red Hat) . . . .4-35
X window system . . . 5-3 X client/server architecture . . . 5-5 Examples of X stations . . . 5-7 X servers in Linux . . . 5-9 X.org configuration . . . 5-10 Starting X . . . 5-12 Stopping X . . . 5-14 Session managers . . . 5-15 X networked . . . 5-16 X applications networked . . . 5-18 Applications over TCP/IP . . . 5-19 Secure shell . . . 5-22 X sessions networked . . . 5-23 X sessions over TCP/IP . . . 5-24 Chooser sessions . . . 5-26 Checkpoint . . . 5-27 Exercise 5: X window system . . . 5-28 Unit summary . . . 5-29 Unit 6. Logging . . . 6-1 Unit objectives . . . 6-2 Logging concepts . . . 6-3 Facilities and priorities . . . 6-5 /etc/syslog.conf . . . 6-7 logger command . . . 6-9 logrotate command . . . 6-10 Sample /etc/logrotate.conf . . . 6-12 Analyzing logfiles . . . 6-14 Checkpoint . . . 6-17 Exercise 6: Logging . . . 6-18 Unit summary . . . 6-19 Unit 7. Character devices, PCMCIA, and USB . . . 7-1 Unit objectives . . . 7-2 Character devices . . . 7-3 Character device naming . . . 7-4 Virtual character devices . . . 7-5 Serial devices, modems, and ISDN . . . 7-8 Serial terminals . . . 7-10 Parallel and PS/2 ports . . . 7-12 Sound cards . . . 7-13 PCMCIA devices . . . 7-15 lspci command output . . . 7-17 USB devices . . . 7-18 lsusb command output . . . 7-20 Checkpoint . . . 7-21
Exercise7: Character devices, PCMCIA, and USB . . . .7-22 Unit summary . . . .7-23 Unit 8. Block devices, RAID, and LVM . . . .8-1 Unit objectives . . . .8-3 Block devices . . . .8-4 Traditional block device naming . . . .8-5 Dynamic device naming with udev. . . .8-6 Floppy disks . . . .8-10 Hard disks . . . .8-11 Monitoring hard disk health . . . .8-13 Hard disk partitions . . . .8-15 Partitioning tools . . . .8-17 RAM disks . . . .8-18 The loop device . . . .8-19 Logical volume management (1 of 2) . . . .8-21 Logical volume management (2 of 2) . . . .8-23 LVM implementation overview . . . .8-24 Physical volume commands . . . .8-25 Volume group commands . . . .8-26 Logical volume commands . . . .8-27 Striping logical volumes . . . .8-28 Extending/reducing a volume group . . . .8-29 Extending/reducing a logical volume . . . .8-30 LVM backup and recovery . . . .8-31 Additional LVM considerations . . . .8-32 RAID . . . .8-34 RAID levels (1 of 2) . . . .8-36 RAID levels (2 of 2) . . . .8-38 Linux RAID support . . . .8-39 Linux software RAID implementation: mdadm . . . 8-40 mdadm modes . . . .8-42 mdadm implementation . . . .8-44 Watching a running RAID . . . .8-46 Spare disks . . . .8-48 Additional RAID considerations . . . .8-50 Checkpoint . . . .8-52 Exercise 8: Block devices, LVM, and RAID . . . .8-53 Unit summary . . . .8-54 Unit 9. Filesystems . . . .9-1 Unit objectives . . . .9-3 What is a file? . . . .9-4 What is a filesystem? . . . .9-6
Ext2fs summary . . . 9-15 Other filesystem features . . . 9-17 Creating a filesystem . . . 9-19 Mounting a filesystem . . . 9-20 Mounting filesystems at system startup . . . 9-21 Mount options . . . 9-23 Unmounting filesystems . . . 9-25 Checking a filesystem . . . 9-26 ext2/ext3-specific information . . . 9-28 ReiserFS-specific information . . . 9-30 Comparing filesystems . . . 9-32 SHMFS-specific information . . . 9-33 Quota concepts . . . 9-34 Quota implementation on Linux . . . 9-36 Enabling quota . . . 9-37 Configuring quota . . . 9-38 Quota information . . . 9-40 Checkpoint . . . 9-41 Exercise 9: Filesystems . . . 9-42 Unit summary . . . 9-43 Unit 10. Memory management and Xen . . . 10-1 Unit objectives . . . 10-2 Linux memory management . . . 10-3 Example: Lightly loaded system . . . 10-5 Example: Heavily loaded system . . . 10-6 Creating paging space: Partition/LV/RAID . . . 10-7 Creating paging space: File . . . 10-9 Useful memory-related commands/files . . . 10-10 procinfo command . . . 10-11 /proc/meminfo . . . 10-13 free command . . . 10-15 top command . . . 10-18 vmstat command . . . 10-21 vmstat –s command . . . 10-24 ps command . . . 10-25 Process memory: /proc/PID/status . . . 10-28 Process memory: /proc/PID/maps . . . 10-31 Xen overview . . . 10-33 Xen installation . . . 10-34 Booting the Xen kernel . . . 10-35 Xen domain configuration file . . . 10-36 Example Xen configuration file . . . 10-37 Booting a guest domain . . . 10-38 Xen domain management (1 of 2) . . . 10-39 Xen domain management (2 of 2) . . . 10-40
File system management . . . .10-41 Networking in Xen . . . .10-42 Virtual Machine Manager . . . .10-43 Checkpoint . . . .10-44 Exercise 10: Memory management . . . .10-45 Unit summary . . . .10-46 Unit 11. Scheduling . . . .11-1 Unit objectives . . . .11-2 Scheduling . . . .11-3 Cron . . . .11-4 User crontab example . . . .11-6 crontab command . . . .11-8 System crontab file . . . .11-9 anacron (RHEL/Fedora) . . . .11-10 /etc/anacrontab (RHEL/Fedora) . . . .11-12 at command . . . .11-13 batch command . . . .11-15 Controlling at Jobs . . . .11-16 Checkpoint . . . .11-17 Exercise 11: Scheduling . . . .11-18 Unit summary . . . .11-19 Unit 12. Backup and restore . . . .12-1 Unit objectives . . . .12-3 Backup schemes . . . .12-4 Incremental versus differential backup . . . .12-6 Sample monthly backup scheme . . . .12-7 Backup devices . . . .12-8 Default backup tools . . . .12-10 tar command . . . .12-11 GNU tar . . . .12-13 cpio command . . . .12-14 dump command . . . .12-15 dd command . . . .12-16 Other backup tools . . . .12-17 Checkpoint . . . .12-18 Exercise 12: Backup and restore . . . .12-19 Unit summary . . . .12-20 Unit 13. User administration . . . .13-1 Unit objectives . . . .13-2 Security concepts . . . .13-3 User hierarchy . . . .13-4
Passwords . . . 13-15 /etc/passwd . . . 13-16 /etc/shadow . . . 13-17 /etc/group and /etc/gshadow . . . 13-19 /etc/issue and /etc/issue.net . . . 13-20 Message of the day . . . 13-21 Checkpoint . . . 13-22 Exercise 13: User administration . . . 13-23 Unit summary . . . 13-24 Unit 14. User-level security . . . 14-1 Unit objectives . . . 14-2 User-level security overview . . . 14-3 Pluggable Authentication Modules (PAM) . . . 14-5 Authentication before PAM . . . 14-6 Authentication with PAM . . . 14-8 PAM configuration file example . . . 14-10 Common PAM modules . . . 14-13 Principles of authorization . . . 14-14 File permissions . . . 14-16 Changing permissions . . . 14-18 umask . . . 14-19 Example: Creating a team directory . . . 14-20 Root access . . . 14-21 su command . . . 14-23 sudo command . . . 14-24 Security logs . . . 14-26 Useful commands . . . 14-28 Additional commands . . . 14-29 Checkpoint . . . 14-30 Exercise 14: User-level security . . . 14-31 Unit summary . . . 14-32 Unit 15. Troubleshooting . . . 15-1 Unit objectives . . . 15-2 Troubleshooting . . . 15-3 Identifying the problem: Part 1 . . . 15-5 Identifying the problem: Part 2 . . . 15-7 Core dumps . . . 15-9 Fixing the problem . . . 15-11 What is Rescue Mode? . . . 15-13 Use available rescue tools (1 of 3) . . . 15-15 Use available rescue tools (2 of 3) . . . 15-16 Use available rescue tools (3 of 3) . . . 15-17 chroot command . . . 15-18 Booting Rescue Mode: RHEL/Fedora . . . 15-20
Using Rescue Mode: RHEL/Fedora . . . .15-22 Booting Rescue Mode . . . .15-23 Using Rescue Mode: SUSE . . . .15-25 Repair installed system: SUSE . . . .15-26 Checkpoint . . . .15-29 Exercise 15: Troubleshooting . . . .15-30 Unit summary . . . .15-31 Appendix A. Checkpoint solutions . . . A-1 Appendix B. Certification information . . . B-1 Appendix C. Physical planning and maintenance . . . C-1 Appendix D. Policies and procedures . . . D-1 Appendix E. Kernel compilation and configuration . . . E-1 Appendix F. Linux on IBM servers . . . F-1 Acronyms . . . X1 Glossary. . . X5 Index. . . X-13
The reader should recognize that the following terms, which appear in the content of this training document, are official trademarks of IBM or other companies:
IBM® is a registered trademark of International Business Machines Corporation.
The following are trademarks of International Business Machines Corporation in the United States, or other countries, or both:
VMware® and the VMware "boxes" logo and design, Virtual SMP and VMotion are registered trademarks or trademarks (the "Marks") of VMware, Inc. in the United States and/or other jurisdictions.
PS/2® is a trademark or registered trademark of Lenovo in the United States, other countries, or both.
Adobe and PostScript are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States, and/or other countries.
Intel, Intel Xeon, Itanium, Pentium and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.
Linux® is a registered trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both.
UNIX® is a registered trademark of The Open Group in the United States and other countries.
AIX® AS/400® AT®
Balance® BladeCenter® Chipkill™
DB2® Domino® eServer™
General Parallel File System™
GPFS™ i5/OS®
iSeries® LoadLeveler® Lotus®
MVS™ Notes® OpenPower®
OS/2® OS/390® OS/400®
POWER™ POWER4™ PowerPC®
pSeries® RS/6000® S/390®
SP™ System i™ System i5™
System p™ System p5™ System x™
System z™ System z9® Tivoli®
XT™ z9™ z/OS®
AMD and AMD Opteron and combinations thereof, are trademarks of Advanced Micro Devices, Inc.
Linux System Administration I: Implementation
Duration: 4 days
Purpose
The purpose of this course is teach experienced Linux users the techniques, methods, and policies used in Linux system
administration.
Audience
The intended audience for this course are experienced Linux users who want to become administrators of one or more Linux servers.
Prerequisites
• IBM Linux course LX02 (Linux Power User) • Practical experience in running Linux as a user
Objectives
After completing this course, you should be able to: • Install Linux from a network install server
• Manage system startup and shutdown
• Select and use system administration tools when appropriate • Configure and manage printers
• Use packaging tools to create, install, and de-install packages • Configure and manage the X Window System
• Manage logging
• Manage character devices, Personal Computer Memory Card International Association (PCMCIA), and Universal Serial Bus (USB)
• Manage hard disks, partitions, Redundant Array of Independent Disks (RAID), and Logical Volume Management (LVM)
• Create and manage filesystems
• Use scheduling tools
• Create and restore backups • Perform user administration • Apply user-level security • Troubleshoot Linux problems
Contents
• Advanced Linux installation • System startup and shutdown • System administration tools • Printers
• Packaging tools • X Window system • Logging
• Character devices, PCMCIA, and USB
• Managing hard disks, partitions, LVM, and RAID • Filesystems
• Memory management and Xen management • Scheduling
• Backup and restore • User administration • User-level security • Troubleshooting Optional material
• Physical system management and planning • Policies and procedures
Day 1
Unit 1- Advanced Linux installation Exercise 1- Advanced Linux installation Unit 2- Startup and shutdown
Exercise 2- Startup and shutdown Unit 3- System administration tools Exercise 3- System administration tools
Day 2
Unit 4- Package management Exercise 4- Packaging tools Unit 5- X Window system Exercise 5- X Window system Unit 6- Logging
Exercise 6 - Logging
Day 3
Unit 7- Character devices, PCMCIA, and USBUnit 8- Block devices, RAID, and LVM
Exercise 8- Block devices, RAID, and LVM Unit 9- Filesystems
Exercise 9- Filesystems
Unit 10 - Memory management and Xen Exercise 10 - Memory management and Xen
Day 4
Unit 11 - Scheduling Exercise 11 - Scheduling Unit 12 - Backup and restore Exercise 12 - Backup and restore Unit 13 - User administration Exercise 13 - User administration Unit 14 - User-level security Exercise 14 - User-level security Unit 15 - Troubleshooting
Exercise 15 - Troubleshooting Wrap-up, optional exercises
Distribution naming conventions
This course deals with multiple distributions of the Linux operating system. The following acronyms will be used throughout the course.
- Red Hat Enterprise Linux Entry Server
• RHEL: Applies to all versions of Red Hat Enterprise Linux • RHEL5: Applies to Red Hat Enterprise Linux 5
• rhel51s: Applies to Red Hat Enterprise Linux Server 5 - Fedora Linux
• Fedora: Applies to all versions of Fedora • fedo8: Applies to Fedora Linux 8
- SUSE Linux Enterprise Server
• SLES: Applies to all versions of SUSE Linux Enterprise Server • SLES10: Applies to SUSE Linux Enterprise Server 10
Several professional certifications currently exist for Linux. This course, combined with other Linux courses, prepares you for all of them. For more information, refer to Appendix B.
This course, in combination with other courses, has been certified by ProCert (http://www.procert.com) as appropriate course material for preparing for LPI certification tests. The statement below reflects this.
Linux Professional Institute statement
“This course is specifically designed to provide you with the skills, knowledge, and understanding required to become professionally certified by LPI. To learn more about LPI certifications or to register to take an official LPI certification exam, visit www.lpi.org.”
What this unit is about
This unit teaches you how to perform advanced (non-CD) installations.
What you should be able to do
After completing this unit, you should be able to: • Perform a network installation
• Discuss network install servers
• Discuss RHEL/Fedora kickstart installations • Discuss SLES AutoYaST installations
How you will check your progress
Accountability:
• Checkpoint questions • Machine exercises
References
Linux man pages
SUSE Linux 10 Installation and Administration Guide RedHat Enterprise Linux V5 Administration Guide RedHat Enterprise Linux V5 Installation Guide
Figure 1-1. Unit objectives LX036.0
Notes:
© Copyright IBM Corporation 2009
Unit objectives
After completing this unit, you should be able to:
•
Perform a network installation
•
Discuss network install servers
•
Discuss RHEL/Fedora Kickstart installations
Figure 1-2. Installing Linux: Review LX036.0
Notes:
Introduction
Taking time to plan and prepare for the installation of any operating system is highly recommended. It provides you with the ability to have all the resources at hand for the installation, and avoid any delays that the lack of planning might impose.
Documentation
Novell provides both release notes and installation information on both the distribution media as well as their Web site. The Installation and Administration Manual is designed
to guide you through the installation and administration of SUSE Linux Enterprise Server 10 on various platforms.
The installation manual is in PDF format and available in several languages. To access this manual, place the first CD into an available PC and use an Acrobat reader to open the file located on the CD.
© Copyright IBM Corporation 2009
Installing Linux: Review
•
Documentation
•
Hardware requirements
•
System resources
•
Installation resources
Red Hat provides both release notes and installation related manuals on CD1 of the distribution media. Red Hat also provides this information online.
We strongly suggest you have these documents at hand and review them, before proceeding with an installation, even if you consider yourself a skilled Linux
administrator. Each distribution may make significant changes that an impact your installation!
Hardware requirements
One thing that needs to be checked is to verify that the target system’s hardware is supported. This includes both the system and I/O devices and adapters installed on the system. Occasionally, I/O devices and adapters will be released that are not included in the current distribution releases of the Linux operating system. We suggest you refer to the Web site for the distribution you will be installing to check for additional information on devices.
System resources
As you plan for an installation, you will need to gather system information. What type of disk will you will be installing to? Will you be using a network, and if so, what address will it use?
Installation resources
Once you have decided on the method of installation, make sure you have these resources on hand and that they have been tested. If installing via a network, make sure you have all relevant information (IP addresses, server configuration, network paths, and so forth). If you are installing from CD-ROM, verify the media is not
corrupted (better to find this out in testing rather than when you are in the final stages of an installation). Do you have any customization scripts in place? Have you read the manuals? Always being prepared is the best key to success.
Check for updated information
Before starting the installation, always check with the distribution to verify no patches or fixes have been released since you received your media. SUSE Linux releases updates in the form of Service Packs (SP1, SP2, and so forth). Red Hat releases software in the form of updates (as in RHEL5 U1, which we are using in this course).
Figure 1-3. Disk partitioning: Review LX036.0
Notes:
Introduction
On an Intel-based computer (x86 compatible), a hard disk is split up using a partitioning scheme. The scheme dates back to the 8086 processor.
Every hard disk in your computer consists of a large number of sectors of 512 bytes each. The first sector of the disk always contains two things1:
- The Master Boot Record (MBR). This master boot record contains the bootstrap code of the system.
- The Partition Table. This table contains the way the rest of the disk is divided into partitions.
The rest of the disk can be split up into a maximum of four primary partitions2. Every partition can hold a separate filesystem, each with its own operating system on it. In 1 Actually, three: the first sector also contains a two-byte magic number to verify that this is a valid master boot record sector. 2 The partition table itself is 64 bytes. To fully describe a partition, you need 16 bytes per partition, hence the limit of four partitions that
can be described in the partition table.
© Copyright IBM Corporation 2009
Disk partitioning: Review
sda: The first sector of the disk contains
the MBR and partition table
sda1: First primary partition holds a
Microsoft Windows filesystem
sda5: First logical partition holds a Linux
filesystem that will be mounted as /
sda6: Second logical partition holds a Linux
filesystem that will be mounted as /home
sda7: Third logical partition holds a Linux
swap space
sda2: Second primary partition is an
extended partition and holds three logical partitions
Master Boot Record (MBR) Partition table
MS Windows
Linux swap
Linux /home
addition to that, one of the primary partitions can be used as an extended partition, which can contain an unlimited number of logical partitions3. (Linux limits the number of logical partitions to 59 on integrated development environment (IDE) disks and 11 on Small Computer System Interface (SCSI) disks4.) Every logical partition can hold a separate filesystem too. Most operating systems are not able to boot off a logical partition, just off a primary partition. Linux is an exception to this.
The first IDE hard disk is called /dev/hda, the second /dev/hdb, and so on. The first primary partition on the first IDE drive is called /dev/hda1, the first logical partition is called /dev/hda5. Under the 2.4 kernel, most Linux distributions defined devices up to /dev/hda16, so if you wanted to create more than 12 logical partitions, you would need to create some extra /dev entries yourself using the mknod command. With the
introduction of the 2.6 kernel, and devfs, Linux now creates device entries for only those devices found.
SCSI disks are a little different in this respect. The first difference is that SCSI disks use /dev/sda instead of /dev/hda. The second difference is that SCSI disks can only hold eleven logical partitions. This has to do with the SCSI ID numbering, which reserves 16 IDs for all block devices on the disk, where /dev/sda is also considered a block device. Together with four primary partitions, this leaves a maximum number of eleven logical partitions.
In newer distributions (that is, Fedora 8), all hard disks are referred to as “dev/sda”, including IDE disks.
Figure 1-4. Network installations LX036.0
Notes:
Introduction
Most Linux systems are installed from the distribution CD-ROMs (or DVDs). This is a convenient method if you only need to install one or a few systems but quickly becomes tedious if you need to install ten or more systems, especially if each system has to be installed with the same settings.
More advanced installation methods exist which are convenient for these situations, and in all but a few cases, this comes down to network installations, where the Red Hat Package Manager software packages (RPMs) to be installed are downloaded from the network.
Network protocols
Various network protocols exist to retrieve the installation RPMs, and the protocols that are supported depend on your distribution. Support might be included for Network File
© Copyright IBM Corporation 2009
Network installations
•
Installations where packages to install are downloaded from
the network
•
Network protocols supported depends on distribution
– Network File System (NFS)
– File Transfer Protocol (FTP)
– HyperText Transfer Protocol (HTTP)
– Server Message Block (SMB)
•
Requires a network install server
•
Usually requires special network-enabled boot media
– Preboot Execution Environment (PXE) boot requires no media
System (NFS), File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and Server Message Block (SMB).
An obvious requirement for a network-based install is that somewhere on the network you need to configure a network install server, which holds all the RPMs for your distributions.
Finally, you will need some network-enabled boot media. This can be the first CD (or DVD) of your regular installation or a minimal install CD or DVD ISO image. If your system supports the Preboot Execution Environment (PXE), you can boot and install your distribution over the network without the need for physical boot media.
Figure 1-5. Network install server: Overview LX036.0
Notes:
Image server
A network install server is typically a Linux/UNIX server, although Windows servers can
sometimes also be used. The content of all relevant CDs is copied to disk and made available. It is a good idea to use a naming scheme that allows multiple versions of multiple distributions to be copied to disk.
Almost all network install servers export the CDs via NFS. You can also configure a server to use FTP, HTTP, or SMB.
NFS
If you decide to use NFS, be aware of the fact that the newer distributions typically use NFS version 3, while older distributions typically use NFS version 2. This might lead to compatibility problems, which can be solved easily by forcing the NFS server to always use version 2.
© Copyright IBM Corporation 2009
Network install server: Overview
•
Should be a Linux/UNIX server
•
Content of all relevant CDs copied to disk
– Use a naming scheme that allows multiple versions/distributions to
be exported
•
For example: /export/rhel51s, /export/fedo8,
/export/suse10sp1, ...
•
Method
– NFS
– (Anonymous) FTP
– HTTP
– SMB
Anonymous FTP
If you decide to offer anonymous FTP installs, then you need to create your directory structure somewhere in the /var/ftp directory, since the FTP daemon will perform a chroot to this directory when anonymous FTP is requested.
HTTP
If you decide to offer HTTP installs, you can simply create a symbolic link from your DocumentRoot directory to the directory where your CDs are copied into, as long as
FollowSymLinks is set in your Web server configuration.
PXE boot
The PXE boot process allows the server to broadcast a boot menu to its network. Any BOOTP enabled machine can display the menu and talk to the server using Trivial File Transfer Protocol (TFTP) protocol. The client then enters the appropriate information to boot, install, or rescue from the network installation server.
Figure 1-6. Network install server: Configuration LX036.0
Notes:
Introduction
We mentioned on the previous visual that you should select a naming convention when setting up your installation server. You should always check the documentation and release notes for a distribution to verify if there is a specific naming convention you must follow as well, or your network installation may not function correctly.
Important files
After creating the installation directory, you need to copy the contents of the relevant CDs to that directory. This needs to be done with all preservations of permissions, users and so forth intact and can best be done with the cp -a command.
For a Red Hat distribution, make sure you copy at least the .discinfo file and the Server/ and images/ directories. For a Fedora distribution, you need .discinfo, repodata/,
© Copyright IBM Corporation 2009
Network install server: Configuration
•
Server fileset configuration
– RHEL: Copy .discinfo, Server/ and images/
– Fedora: Copy .discinfo, repodata/, Packages/ and images/
– SUSE Linux: Copy CD 1 completely, and from all other CDs, copy
SUSE/ and media*
•
Server configuration
– Red Hat/Fedora
•
Manual
– SUSE Linux
Packages/, and images/, and for a SUSE distribution, make sure you copy the whole CD1 and at least the suse/ directory and the media* files of the subsequent CDs.
Server configuration
SUSE Linux Enterprise Server (SLES) provides a tool under Yet another Setup Tool (YaST) to configure your installation server. This menu-driven interface will configure a directory tree with the proper sub-directories and files so that a system running SLES can successfully be an installation server. In the case of Red Hat, you will need to configure the installation server manually.
Figure 1-7. RHEL/Fedora kickstart installations LX036.0
Notes:
Introduction
Kickstart provides the ability to create a hands-off installation. This means that if the ks= option is passed to the installer, the install program will take input from the configuration file. The contents of the kickstart configuration file can contain all of the answers to questions posed by the Anaconda installer, plus post-install directives. If the
configuration is missing information, the install process will prompt the installer for additional information.
File creation
The ks.cfg file is a flat text file. After a system has been installed, a kickstart file that configures the system to the way that it was installed is located in root’s home directory in a file /root/anaconda-ks.cfg.
To create a kickstart file from scratch, use the system-config-kickstart utility. © Copyright IBM Corporation 2009
RHEL/Fedora kickstart installations
•
Fedora/RHEL method of automating installations
•
File ks.cfg with three sections:
– Install commands
– %packages section
– %pre, %post sections
•
File creation
– Manually
– system-config-kickstart
– /root/anaconda-ks.cfg (created during installation)
•
Location
– Boot floppy or NFS server
•
NFS also requires a Dynamic Host Configuration
Protocol (DHCP) server
•
Initiation:
Location
The kickstart file can be presented either on a diskette, or from a network source, such as an NFS server.
Initiation
Kickstart is Red Hat and Fedora’s method of automating installations. It involves creating a ks.cfg file, which contains three sections:
- The first section, which starts at the top of the file, contains the answers to all questions of the installation process. For instance, if the statement lang en_US is present in the kickstart file, the question “What language do you want to use during the installation process?” will not be asked, and US English is used.
- The second section starts with the %packages identifier. It contains a list of all packages (RPMs) to be installed. Just as with the install process itself, it can also use the package groups that are defined in the component groups XML file provided by the distribution (comps-rhel5-server-core.xml in RHEL5, Fedora-8-comps.xml in Fedora), located in the repodata/ directory. These package groups are identified with an ampersand, for instance “@ Printing Support”.
- The third section starts with the %post identifier. It contains a series of shell
commands that are executed once the installation has finished. These are executed on the newly installed system, with all paths, networking, and so forth intact. This means that virtually anything is possible, including mounting remote filesystems, creating user accounts, and so forth.
It is also possible to create a %pre section, which is executed before the installation starts. This is generally used only to implement custom partition schemes.
Kickstart files can be created by hand, but Red Hat has also released a tool which might help you generate kickstart files: system-config-kickstart (formerly known as ksconfig). This tool is available on the distribution CDs in the system-config-kickstart RPM. As an added bonus, the RHEL/Fedora installer, Anaconda, generates a kickstart file for you based on the choices made during the installation process itself. This file is called /root/anaconda-ks.cfg.
The kickstart configuration file can be stored on the boot diskette, or can be stored on a network server. Kickstart installs are then started by typing linux ks=URL where URL is the location where the ks.cfg file is stored. Examples are ks=floppy and
ks=http://10.0.0.1/kickstart/ks.cfg. If you do not supply a URL (linux ks), then the location of the kickstart file is taken from the DHCP next-server and filename option fields in the DHCP reply from the DHCP server.
Figure 1-8. RHEL/Fedora kickstart example LX036.0
Notes:
Introduction
The visual shows a small portion of a kickstart configuration file
The following is the complete example of the kickstart file that is shown in the visual above. Note the name is anaconda-ks.cfg. This file was created during the installation of RHEL51. Can you tell what software was selected for this installation? What
timezone will system use?*
[root@sys2 ~]# more anaconda-ks.cfg
# Kickstart file automatically generated by anaconda.
install cdrom
lang en_US.UTF-8
langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us
© Copyright IBM Corporation 2009
RHEL/Fedora kickstart example
# cat anaconda-ks.cfg
# Kickstart file automatically generated by anaconda. install
cdrom
lang en_US.UTF-8
langsupport --default=en_US.UTF-8 en_US.UTF-8 keyboard us
xconfig --card "Intel 815" --videoram 16384 --hsync 30-94 --vsync 48-120 --resolution 800x600 --depth 16 --startxonboot --defaultdesktop gnome network --device eth0 --bootproto static --ip 10.0.0.3
--netmask 255.255.255.0 --gateway 10.0.0.100 --hostname sys2 rootpw --iscrypted $1$Q1EsuwfB$aowfCXdJRUcpW/8h4JlOc.
firewall --disabled selinux --enforcing
authconfig --enableshadow --enablemd5 timezone America/Los_Angeles
bootloader --location=mbr --append="rhgb quiet"
# The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work
#clearpart --all --drives=had . . .
xconfig --startxonboot --defaultdesktop gnome --startxonboot --defaultdesktop gnome
network --device eth0 --bootproto static --ip 10.0.0.3 --netmask 255.255.255.0 --gateway 10.0.0.100 --hostname sys3
rootpw --iscrypted $1$Q1EsuwfB$aowfCXdJRUcpW/8h4JlOc. firewall --disabled
selinux --enforcing
authconfig --enableshadow --enablemd5 timezone America/Los_Angeles
bootloader --location=mbr --append="rhgb quiet"
# The following is the partition information you requested # Note that any partitions you deleted are not expressed # here so unless you clear all partitions first, this is # not guaranteed to work
#clearpart --all --drives=hda
#part /boot --fstype ext3 --size=100 --ondisk=hda #part pv.4 --size=0 --grow --ondisk=hda
#volgroup VolGroup00 --pesize=32768 pv.4
#logvol / --fstype ext3 --name=LogVol00 --vgname=VolGroup00 --size=1024 --grow
#logvol swap --fstype swap --name=LogVol01 --vgname=VolGroup00 --size=512 --grow --maxsize=1024 %packages @ everything e2fsprogs grub kernel lvm2 kernel-devel
* The final part of the file shows that all software (everything) was selected for this installation. The timezone is set near the beginning of the file. This system is set to
Figure 1-9. SLES AutoYaST installations LX036.0
Notes:
Introduction
SLES also supports autoinstallations. On the most recent distributions, this is done through AutoYaST. Earlier SLES distributions used other, more complicated and limiting ways of performing autoinstallations.
File creation
AutoYaST installations revolve around an XML-based file containing all the installation information. This file can technically be created by hand, but that’s a huge task. It is far easier to use yast autoyast to create this file.
Location
This file is saved on a network server. You then need to boot the system from regular boot media.
© Copyright IBM Corporation 2009
SLES AutoYaST installations
•
SUSE Linux method of automating installs
•
File ay.xml containing all installation information:
– General settings for keyboard and so forth
– Partition settings
– Packages
– Pre- and post-install scripts
•
File creation:
– yast autoyast
•
Location:
– Store file on network server
•
Initiation:
– install=nfs://10.0.0.1/export/sles10sp1 \
Initiation
In order to start the install, you need to supply two URLs to the boot loader:
- The first URL is the URL where the installation images can be found. This URL generally has the form install=nfs://10.0.0.1/export/sles10sp1
- The second URL is the URL where the AutoYaST file can be found. This URL generally has the form autoyast=nfs://10.0.0.1/autoyast/myprofile.xml In addition to this, you might also need to specify the network adapter and type. This typically looks like: insmod=eepro100 netdevice=eth0.
Just as with RHEL and Fedora, it is possible to modify the syslinux.cfg file on the boot floppy to start the installation manually.
Figure 1-10. AutoYaST example LX036.0
Notes:
Introduction
The visual shows a small portion of an AutoYaST XML-formatted configuration file. Note the tag format.
© Copyright IBM Corporation 2009
AutoYaST example
<?xml version="1.0"?>
<!DOCTYPE profile SYSTEM "/usr/share/autoinstall/dtd/profile.dtd"> <profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.c om/1.0/configns"> <bootloader> <activate config:type="boolean">false</activate> <global> <embed_stage1.5 config:type="boolean">true</embed_stage1.5> <gfxmenu>/boot/message</gfxmenu> <lines_cache_id>0</lines_cache_id> <prompt>1</prompt> <stage1_dev>/dev/hda7,/dev/hda</stage1_dev> <timeout config:type="integer">8</timeout> </global> <initrd_modules config:type="list"> <initrd_module> <module>piix</module> </initrd_module> <initrd_module> <module>processor</module> </initrd_module> <initrd_module> <module>thermal</module> . . .
Figure 1-11. Checkpoint LX036.0
Notes:
Write down your answers here:
1.
2.
3.
© Copyright IBM Corporation 2009
Checkpoint
1.
True / False: A network install server needs to be a Linux
system.
2.
Which of the following install methods does not require a
network server?
a) NFS
b) SMB
c) FTP
d) CD-ROM
3.
What are some possible locations where a RHEL/Fedora
kickstart or SLES AutoYaST file can be stored?
Figure 1-12. Exercise 1: Advanced Linux installation LX036.0
Notes:
© Copyright IBM Corporation 2009
What you will do in this exercise:
• Install a Linux distribution onto your
classroom system
Figure 1-13. Unit summary LX036.0
Notes:
© Copyright IBM Corporation 2009
Unit summary
Having completed this unit, you should understand:
•
Network install servers are convenient means of software
distribution for doing both upgrades and installs.
•
A network install server typically exports multiple versions of
multiple distributions
via NFS, FTP, or HTTP.
•
To perform a network install, you typically need a special
network-enabled boot media, DVD/CD/USB key, and
sometimes additional module disks as well.
•
RHEL/Fedora kickstart and SLES AutoYaST install methods
allow you to automate installations.
What this unit is about
This unit teaches you how the startup process of a Linux system actually works and how to shut down a Linux system properly.
What you should be able to do
After completing this unit, you should be able to: • Describe the Linux startup flow
• Configure autostarting services • Boot Linux into single-user mode
• Perform a proper shutdown of a Linux system
How you will check your progress
Accountability:
• Checkpoint questions • Exercise
References
Linux man pages
SUSE Linux 10 Installation and Administration Guide Red Hat Enterprise Linux V5 Administration Guide Red Hat Enterprise Linux V5 Installation Guide
http://www.gnu.org/software/grub
GNU GRUB - GNU Project - Free Software Foundation (FSF)
http://grub.enbug.org GRUB Wiki
Figure 2-1. Unit objectives LX036.0
Notes:
© Copyright IBM Corporation 2009
Unit objectives
After completing this unit, you should be able to:
•
Describe the Linux startup flow
•
Configure autostarting services
•
Boot Linux in single-user mode
Figure 2-2. Linux startup flow LX036.0
Notes:
Introduction
This visual gives an overview of the Linux startup flow. In the subsequent visuals, details about each step will be covered.
© Copyright IBM Corporation 2009
Linux startup flow
Hardware boot
Software boot
Usually GRUB
Low level initialization of
important hardware (disk,
CPU, VGA adapter...)
Full initialization of all
hardware
Runs boot scripts and
starts system services
power on
BIOS
init
system ready
boot loader
Linux kernel
and initrd
Figure 2-3. Basic Input/Output System LX036.0
Notes:
Introduction
Every Intel PC has a Basic Input/Output System (BIOS). This is a little program which is stored in an Electrical Erasable Programmable Read Only Memory (EEPROM),
(sometimes also called non-volatile memory) on your motherboard. It is the first
program that runs once the power is switched on. It performs a number of basic tasks: - Completes Power On Self Test (POST) to check memory and hardware.
- Loads various options from non-volatile memory, for instance, memory timing parameters, interrupt request (IRQ) assignment to devices, and the order of boot devices. These options can be set by the user when pressing Del, F1, F2, or some other key while the memory is being tested.
- Checks for the availability of boot devices.
© Copyright IBM Corporation 2009
Basic Input/Output System
•
Checks memory and hardware (POST)
•
Loads options from nonvolatile memory
– Memory timings
– Order of boot devices
•
Checks for boot devices
– Floppy disks
– CD-ROM
– Hard disks
Figure 2-4. Master Boot Record LX036.0
Notes:
Master Boot Record
The Master Boot Record (MBR) is the first sector (512 bytes) of the boot device. It contains three things:
- A 446-byte boot loader program: Software to bootstrap the operating system. - The partition table: A 64-byte table which describes how the rest of the disk is split
up into partitions.
- A 2-byte “magic number,” which is used to check whether this is a valid MBR.
Bootloader
The role of the operating system boot loader is to locate, load, and execute the operating system kernel image. The most common boot loader is the Grand Unified Bootloader (GRUB). The Linux Loader (LILO) is rarely used these days.
© Copyright IBM Corporation 2009
Master Boot Record
• Size: 512 bytes (first sector of HD)
• Addressed by BIOS
• Content:
- 446-byte program code (to boot
an operating system)
- 64-byte partition table with
max. four entries
- 2-byte "magic number" (0xAA55)
Master Boot Record (MBR)
Figure 2-5. GRand Unified Bootloader LX036.0
Notes:
Introduction
GRand Unified Bootloader (GRUB), as Linux Loader (LILO), consists of a number of separate stages:
- The first stage, called stage1 on disk, is usually stored in your MBR.
- The 1.5th stage, called *_stage1_5 (e2fs_stage1_5, fat_stage1_5, minix_stage1_5, reiserfs_stage1_5, and so forth) is stored on disk, typically in /boot/grub. Several 1.5th stage files exist, each for a different filesystem.
Note: This stage is used to add filesystem capabilities to GRUB so that GRUB is able to use regular filename references when loading configuration files, kernels and such, instead of disk block locations. Because of this stage, GRUB is able to
© Copyright IBM Corporation 2009
GRand Unified Bootloader
•
Program stored in MBR (first stage) and in /boot/grub (1.5th
and second stage)
•
Understands filesystem structure
– No need to activate a configuration as with LILO
•
Configuration file is /boot/grub/menu.lst (linked to
/boot/grub.conf)
•
Installed in MBR with grub-install
•
When system boots:
– Selects predefined OS to boot or
– Uses command language to boot non-predefined OS
– Command language compatible with configuration file
•
GRand Unified Bootloader (GRUB) additional features:
– MD5 encrypted passwords
non-predefined operating system.
If a “splashimage” was included in the GRUB configuration, then the second stage displays the menu in a graphical mode with the splash image as background.
GRUB configuration file
The GRUB configuration file is typically stored in your /boot filesystem in a separate GRUB directory called menu.lst (linked to grub.conf). On a regularly booted Linux system, this file is thus referenced as /boot/grub/menu.lst. It contains all predefined operating systems and their options and peculiarities.
GRUB installation
To install GRUB, either use the shell script grub-install or start the grub program and use GRUB commands to install GRUB manually.
GRUB features
GRUB has some additional features that make it far more useful than LILO:
- GRUB supports MD5-encrypted passwords to protect normal users from supplying parameters and options to predefined operating system or defining their own operating system boot procedure.
- GRUB can perform hiding and unhiding of Windows partitions. This is a requirement for running multiple Windows operating systems from the same disk.1
- If configured properly, GRUB can be used to boot from the network. This requires the netboot package and setting up DHCP and TFTP servers. Network booting is outside the scope of this course.
1 The problem lies in Windows 9x itself: When a Windows system boots, it goes through the partition table and assigns a drive letter to
every partition type it recognizes, starting with C:. Furthermore, Windows is only able to boot from the C:-drive. Thus, if you want multiple Windows 9x operating systems on your partition, you need to “hide” all partitions that are not in use. This is done by changing the partition type to something that Windows does not recognize.
Note that Windows NT and its descendants allow you to select another drive assignment order, and thus allow you to have multiple operating systems on one disk.
Figure 2-6. GRUB startup sequence LX036.0
Notes:
Introduction
The visual shows the GRUB startup sequence graphically. The system BIOS boots the system from the selected boot disk by reading and executing the contents of the Master Boot Record (MBR). For a system using GRUB, the MBR contains stage 1 of the GRUB boot loader.
Stage 1 of the GRUB boot loader then loads the 1.5 stage to enable filesystem capabilities. This allows GRUB to reference file names such as /boot/grub/menu.lst, /boot/initrd, and so forth.
Finally, stage 2 is loaded, providing a menu-driven interface to boot predefined operating systems or enter commands to boot a non-predefined operating system.
© Copyright IBM Corporation 2009
GRUB startup sequence
addresses stage1_5 (CHS) contains stage1
MBR
Stage 1 Stage 1_5 Stage 2filesystem driver, loads (hd0,3)/grub/stage2
loads for example,
(hd0,3)/vmlinuz or Windows via "chainloading"
Configuration: /boot/grub/menu.lst
Figure 2-7. /boot/grub/grub.conf or /boot/grub/menu.lst LX036.0
Notes:
GRUB configuration options
The GRUB configuration file, /boot/grub/menu.lst, is nothing more than a predefined series of commands that could just as well have been entered on the GRUB command line. Storing these commands in a file, though, makes booting far more convenient. The file starts with a few general configuration options:
Table 1: /boot/grub/menu.lst general configuration options
Option Description
default=0
This specifies the default operating system to be started. Note: GRUB also allows you to specify the fallback
parameter, which specifies the operating system to boot in case the default fails.
timeout=5 Timeout before starting the default operating system, in seconds.
© Copyright IBM Corporation 2009
/boot/grub/grub.conf or /boot/grub/menu.lst
#boot=/dev/hda default=0 timeout=5
title Red Hat Enterprise Linux ES (2.6.9-34.EL) root (hd0,0)
kernel /vmlinuz-2.6.9-34.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-34.EL.img
#boot=/dev/hda default=0 timeout=5
title Fedora Core (2.6.15-1.1955_FC5) root (hd0,0)
kernel /vmlinuz-2.6.15-1.1955_FC5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.15-1.1955_FC5.img
default=0 timeout=8
title SUSE SLES 10 root (hd0,6)
kernel /boot/vmlinuz root=/dev/hda7 selinux=0 resume=/dev/hda6 splash=silent showopts
When general options are all defined, specific operating systems need to be predefined. For this, the following options may be needed:
Note: Different distributions have made extensions to GRUB, which allow for instance graphics to be used.
Table 2: /boot/grub/menu.lst configuration options
Option Description
title The title of the operating system, as it shows up in the GRUB boot screen.
root
The root partition of the filesystem. All files that are referenced later on are stored on this filesystem. Specifying root is not required, but you will have to identify the root partition every time you mention a file instead, as is done with the SuSE stanza.
kernel The kernel image that is to be loaded, and all options that need to be passed to the kernel.
initrd An initial root disk that needs to be loaded.
unhide Unhide the partition specified (that is, change its type so that Windows systems will recognize it).
hide Hide the partition specified (that is, change its type so that Windows systems will not recognize it).
rootnoverify
The root of the operating system is the partition specified, but don't try to verify and access this as GRUB does not support the filesystem type.
makeactive Mark this partition active in the partition table.
chainloader +1 To boot this operating system, invoke the chainloader, which needs to load the first sector of the specified root partition.
Figure 2-8. Starting the kernel LX036.0
Notes:
Introduction
When the user selects a Linux operating system in the boot loader, then the boot loader will load the Linux kernel.
Compressed versus uncompressed kernel images
A kernel image is either non-compressed (vmlinux), or compressed (vmlinuz) and is normally located in the /boot directory. The naming convention for a kernel image that is compressed is that the kernel image file name will have the letter z. Uncompressed kernel images will have the letter x. Consider the following selected contents of the /boot/grub/menu.lst file
# cat /boot/grub/menu.lst ...
title Red Hat Enterprise Linux Server-base(2.6.18-92.el5) © Copyright IBM Corporation 2009
Starting the kernel
•
Once the kernel is loaded, it is started by the boot loader
•
On most architectures (including i386), the kernel is
compressed with a decompress program included
•
When the kernel starts, it detects all hardware and switches
the CPU to multitasking, multiuser mode
Inspecting /boot/System.map-2.6.16-rc1-git3-7-default
Loaded 21547 symbols from /boot/System.map-2.6.16-rc1-git3-7-default. Symbols match kernel version 2.6.16.
No module symbols loaded - kernel modules not enabled. klogd 1.4.1, log source = ksyslog started.
<5>Linux version 2.6.16-rc1-git3-7-default (geeko@buildhost) (gcc version 4.1.0 20060123 (prerelease) (SUSE Linux)) #1 Mon Jan 30 21:52:12 UTC 2006
<6>BIOS-provided physical RAM map:
<4> BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) <4> BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) <4> BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) <4> BIOS-e820: 0000000000100000 - 0000000017ee06c0 (usable) <4> BIOS-e820: 0000000017ee06c0 - 0000000017ee66c0 (ACPI data) <4> BIOS-e820: 0000000017ee66c0 - 0000000017eee700 (ACPI NVS) <4> BIOS-e820: 0000000017eee700 - 0000000018000000 (reserved) <4> BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) <4> BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) <4> BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved) <5>0MB HIGHMEM available.
<5>382MB LOWMEM available.
<6>found SMP MP-table at 0009fe00 <7>On node 0 totalpages: 98016
root (hd0,0)
kernel /vmlinuz-2.6.18-92.el5 ro roo/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-92.el5.img ...
This reference to a compressed kernel image /vmlinuz-2.6.18-92.el5.
Due to potential space constraints, the Linux kernel can be compressed. If a
compressed kernel image is used, an uncompress program is attached to it. Actually, it looks like a self-decompressing ZIP file in DOS.
Loading the kernel image
The boot loader loads a specified kernel image in memory and starts the kernel executing. At this point, the kernel initializes system hardware which has built-in
support. This includes hard disks, serial devices, mice, graphical adapters, keyboards, network adapters and the like. By far, most of these adapters can indeed be
autodetected, but some can't. In that case, their configuration parameters (most notably, IRQ, I/O, and DMA levels) need to be passed to the kernel as boot options. If this is the case, consult the Hardware-HOWTO for details.
Next, the kernel locates the initrd (initial RAM disk), decompresses it, and loads all
required kernel modules (device drivers) stored in the initial RAM disk. We will discuss the initrd in more detail on the next visual.
After the kernel has detected all hardware, it switches the processor to the so-called “protected mode,” which basically means that from that point on multitasking is possible in a multiuser environment.
Note: While booting, the kernel generates a lot of messages that will scroll off the screen very fast. Since no filesystem is available on which to store these messages, they vanish. If you wish to retrieve these messages later however, you can run the dmesg command to see them.
Figure 2-9. Initial RAM Disk LX036.0
Notes:
Introduction
Not all hardware is supported in the core kernel image. In fact, almost all hardware support in Linux today comes in the form of modules. These modules are pieces of code that are loaded into kernel memory only if required.
This works well, but leads to a minor problem if kernel modules are needed to mount the root filesystem. This can happen, for instance, because:
- The root filesystem sits on a hard disk type for which support was not compiled into the kernel image. This applies mostly to SCSI.
- LVM or RAID was used, and LVM or RAID support was not compiled into the kernel image.
- The root filesystem uses ext3, JFS or ReiserFS as filesystem type, and support for these filesystems was not compiled into the kernel image.
© Copyright IBM Corporation 2009
Initial RAM disk
•
An Initial RAM Disk (initrd) is needed if the kernel can't access
the root filesystem without modules (SCSI, LVM, RAID, ext3,
Reiser)
•
The initrd is loaded into memory by the boot loader which
consists of a small gzip-compressed ext2 filesystem image
•
The initrd contains a linuxrc script that loads the modules
from the RAM disk and mounts the actual root filesystem
Linux kernel
linuxrc
Mount actual root fs
Kernel modules
initrd
In these cases, you are going to need an initial RAM disk (sometimes also called an initial root disk). This is a file containing a compressed image of an ext2 filesystem,
which in turn contains two things: - A linuxrc script
- The kernel modules that are needed
The initrd image is loaded into memory by the boot loader, just like the Linux kernel. When the Linux kernel starts, it detects the presence of the initrd. It then proceeds to uncompress and mount this filesystem as temporary root. The kernel’s last direct action is then to start the linuxrc script.
The linuxrc script loads all the required modules, mounts the true root filesystem, and then executes a system call pivot_root. This switches the position of the initrd and the true root filesystem. From that point on, the actual root filesystem is mounted at its correct location, and linuxrc is able to continue the boot process by starting the /sbin/init program.
Figure 2-10. init LX036.0
Notes:
init process
The init process started by the kernel reads its configuration file /etc/inittab to: - Identify the first script to run during system startup
- Identify the default run level if no runlevel is given at the boot prompt - Determine which scripts to be run at the various run levels
- Determine how to handle certain key sequences - Determine how to handle a power failure
Runlevels
There are seven (eight for SUSE) runlevels, but on most distributions only runlevel 3 and 5 are really important for us. 3 means full multiuser mode with a text-based login (you'll need to start X yourself), and 5 is the same, but with an X-based login screen. The following run levels apply to Red Hat, Fedora, and SUSE:
- 0 - System halt
© Copyright IBM Corporation 2009
init
•
init is started by the kernel after the root filesystem is mounted
•
init reads configuration file /etc/inittab
•
Decides on default runlevel if no runlevel is given
•
Runlevels have different meaning:
– 0: System halt
– S: Single-user mode (no scripts run) (SUSE)
– 1: Single-user mode (some scripts run)
– 2: Local multiuser without network
– 3: Full multiuser with network
– 4: Not used
– 5: Full multiuser with network and xdm (GUI)
– 6: System reboot
•
init will start all programs for that runlevel
Note: Once the system has started, you can switch runlevels
- S - Single-user mode (no scripts run) (SUSE) - 1 - Single-user mode (some scripts run) - 2 - Local multiuser without network - 3 - Full multiuser with network - 4 - Not used
- 5 - Full multiuser with network and xdm (GUI) - 6 - System reboot
The runlevels are defined in /etc/inittab. For example: # cat /etc/inittab . . . # System initialization. si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 . . .
Each run level has a set of scripts associated with it in the directory structure
/etc/init.d/rc<X>.d (SUSE) or /etc/rc<X>.d (Red Hat, Fedora), where X is the run level.
In the example, runlevel 3 would cause the script /etc/rc.d/rc to execute scripts in the /etc/rc.d/rc.3 directory structure.
Default runlevel
The default runlevel is specified in the /etc/inittab file. The entry id: identifies the default runlevel. For example:
# grep id /etc/inittab id:5:initdefault:
The default runlevel for the system in the example will be runlevel 5.
Run-level determination
Switching runlevels
Switching runlevels can be accomplished by using either the init or telinit commands. For example, to change the runlevel of the system to runlevel 1:
# runlevel N 5
# init 1 # runlevel 5 1
In the example, by using the runlevel command, you can identify the current runlevel state before and after the init command was issued.
