LPI Linux LPIC1. Module 1

Transcription

1 LPI Linux LPIC1 Module 1

2 Module Contents 1 Evans Ikua Lead Editor Kenya ikua@fossfa.net 2 Chris Brown Content Author UK cb11840@gmail.com 3 Mark Clarke Content Author RSA mark@jumpingbean.co.za 4 Brian Ssennoga Content Author Uganda bssennoga@ihsu.ac.ug 5 Trust Zifa Material co-editor Zimbabwe trust@jumpingbean.co.za 6 John Matogo Material co-editor Kenya john jmatogo@strathmore.edu 7 Ken Mutua Material co-editor Kenya kenmutua@gmail.com 8 Bernard Owuor Material co-editor Kenya b_owuor@yahoo.com 9 Sisay Adugna Material co-editor Ethiopia sisayie@gmail.com 10 Balthas Seibold Senior Project Manager - GIZ Germany Balthas.seibold@giz.de 11 Petra Hagemann Project Manager - GIZ Germany Petra.hagemann@giz.de 12 George Nyambuya Africa Coordinator - ict@innovation RSA George.nyambuya@giz.de 13 David Paulus Intern - GIZ Germany david.paulus@giz.de

3 Module Contents Boot the system Change run levels Shutdown and reboot system

4 Enable and disable integrated peripherals. Configure systems with or without external peripherals such as keyboards. Differentiate between the various types of mass storage devices. Set the correct hardware ID for different devices, especially the boot device. Know the differences between coldplug and hotplug devices. Determine hardware resources for devices. Tools and utilities to list various hardware information (e.g. lsusb, lspci, etc.) Tools and utilities to manipulate USB devices Conceptual understanding of sysfs, udev, hald, dbus

5 According to von Neumann, a computer system consists of a central CPU, primary storage or memory, secondary or permanent storage such as a hard disk, and various input/output devices. In order to operate the CPU needs to be able to load instructions and data into the CPU from memory, possibly having to fetch it from the secondary storage first, execute the instructions and then store the results back in memory. It communicates with the various input/output or peripheral devices via a data path know as bus. A computer system may have more than one bus which it uses to communicate with different components.

6 BIOS The purpose of the BIOS (Basic Input/Output System) is to perform a Power On Self Test(POST), identify and initialize system devices and peripherals and start the process to load the operating system by loading the boot loader from the boot device. The BIOS also provides an abstraction layer to the operating system for accessing system devices. The intention of this layer is to insulate the operating system form having to deal with the wide variety of devices available today but it is ignored by most modern operating systems, including Linux, which access the devices with their own device drivers.

7 Most BIOS manufactures provide a console based user interface that allows you to configure the low-level system for devices. The BIOS configuration interface, and how it is accessed, varies from manufacturer to manufacturer but is usually accessed by pushing a key or key combination, such as delete or insert during system boot. It is under the BIOS configuration console that you can: enable or disable devices, allocate resources such as IRQ and IO addresses, select the boot order of devices and, change that affect operating modes of devices such as disk drives and network cards

8 Most BIOS console allow one to disable integrated peripherals such as COM ports, video or network cards. Even if these devices are not causing any installation or boot up issues you may wish to disable them if they are unused to free up resources that would otherwise be unavailable for other purposes. Sometimes it is necessary to disable system checks for peripherals such as a keyboard or a mouse which, although necessary for the proper operation of desktop machines, are often not present for servers. Machines without keyboards, mouse or monitors are referred to as headless systems. Some BIOSes will refuse to boot if these devices are not present unless these system checks are disabled. (You may wonder how headless machines are accessed at all if they don't have a keyboard, mouse or monitor. The answer is via the network with utilities such as SSH which is covered later in this book.) Of course to access the BIOS itself it is necessary to have peripherals such as a keyboard and monitor present!

9 IRQ, IO Addresses and DMA Addresses IRQs are the mechanism by which peripherals tell the CPU to suspend its current activity and to handle its event such as a key press or a disk read. IO addresses are regions of memory mapped to devices where the CPU can write information of the devices attention and read from the devices as well. This is a somewhat simplified explanation of how peripheral devices communicate with the CPU but suits our purposes for understanding IRQ and IO Addresses.

10 IRQ, IO Addresses and DMA Addresses IRQ 0 system timer (cannot be changed); IRQ 1 keyboard controller(cannot be changed); IRQ 2 cascaded signals from IRQs 8 15 devices configured to use IRQ 2 will use IRQ 9 IRQ 3 serial port controller for COM2 (shared with COM4, if present); IRQ 4 serial port controller for COM1 (shared with COM3, if present); IRQ 5 LPT port 2 or sound card; IRQ 6 floppy disk controller;

11 IRQ, IO Addresses and DMA Addresses IRQ 7 LPT port 1 or sound card (8bit Sound Blaster and compatibles). IRQ 8 realtime clock; IRQ 9 open interrupt / available or SCSI host adapter; IRQ 10 open interrupt / available or SCSI or NIC; IRQ 11 open interrupt / available or SCSI or NIC; IRQ 12 mouse on PS/2 connector; IRQ 13 math coprocessor / integrated floating point unit or interprocessor interrupt (use IRQ 14 primary ATA channel (disk drive or CDROM); IRQ 15 secondary ATA channel

12 IRQ, IO Addresses and DMA Addresses When the CPU and peripheral devices need to communicate and/or pass data between each other they make use of IO addresses. Essentially they communicate by reading and writing data to the reserved IO addresses of the device. There are two complementary methods for performing IO between the CPU and device. There is memory mapped IO (MMIO) and port IO (PIO) addressing.

13 IRQ, IO Addresses and DMA Addresses For allocation of IO memory you can look at /proc/iomem, an example of the contents of this file is given. Prior to plug and play technology you would have to configure IO devices addresses in the BIOS and operating system but with the introduction of plug and play the allocation is now done automatically by the operating system and the bus.

14 IRQ, IO Addresses and DMA Addresses DMA stands for direct memory access and is an optimization that allows devices to read and write directly to memory without having to go through the CPU. Traditionally when the CPU requests data to be read from a device into memory, the CPU needs to be involved in the process of transferring the data. Under this model, called Progammed IO (PIO), significant CPU time is spent simply copying data between the device and memory. With DMA devices can write directly to memory, bypassing the CPU. This greatly enhances system performance.

15 IRQ, IO Addresses and DMA Addresses DMA is automatically configured by the operating system for most devices. A significant device where DMA may not be automatically configured is on the system parallel ata (PATA) disks. For PATA devices (see section below) DMA access can be enabled, assuming your device is /dev/hda (SATA drives which are popular today do not use DMA in the conventional sense) by running the command: hdparm -d1 /dev/sda To see the current setting on your hard disk you can run the command hdparm -d /dev/sda

16 Configuring IRQs, IO Ports/Addresses and DMA Configuration for device IRQ, IO addresses, DMA channels and memory regions happens automatically with today's plug and play PCI bus. Resources are allocated via the system BIOS, via the Linux kernel and possibly the device driver with resource conflicts being automatically resolved in most cases. Linux provides various utilities to query devices to find out the resources that they use. A lot of these utilities make use of the information exported by the kernel in the /proc file system.

17 Configuring IRQs, IO Ports/Addresses and DMA Two commands used to query PCI devices are the lspci and setpci commands. The lspci utility can provide verbose information on devices using the PCI bus, depending on which parameters you use. The lspci utility can provide verbose information on devices using the PCI bus, depending on which parameters you use. l spci -vv provides detailed output on PCI devices. The output below shows typical output from the l spci command with no parameters.

18 Configuring IRQs, IO Ports/Addresses and DMA Even though IRQ conflicts are now a thing of the past, as interrupts can be shared, it can still be a bad idea for some devices with a high frequency of interrupts to share the same IRQ. This is particularly true if the devices are hard disks or sound devices. In this case it is recommended to try and move the PCI cards to different slots to try and get them assigned different IRQs.

19 Linux Device Management Overview A device driver is a kernel space program that allows user space applications to interact with the underlying hardware. Kernel space refers to privileged code which has full access to hardware and runs in ring 0 which is a hardware enforced privileged execution mode. User space applications run in a less privileged mode, ring 3, and cannot access hardware directly. User space application can only interact with hardware by making system calls to the kernel to perform actions on their behalf.

20 Linux Device Management Overview The Linux kernel exports information about the devices from the device drivers to a pseudo filesystem mounted under /sys. This file system tells user space what devices are available. It is populated at system boot but when a hot plug device is inserted or removed the /sys file system is updated and the kernel fires events to let user space know that there has been a change.

21 Linux Device Management Overview One of these user space applications is the kernel device manager, udev, which creates a device node under the /dev directory to allow user space application access to the device. The name of the device node or file is determined by the device drivers naming convention or by user defined rules in /etc/udev/rules.d/. It is through the entries under /dev that user space application can interact with the device driver.

22 Linux Device Management Overview D-Bus (desktop bus). These applications are mainly used by desktop environment to carry out tasks when an event occurs such as open the file browser when a USB drive is inserted or image application when a camera is inserted. While udev creates the relevant entries under the /dev file system, if anything useful need to happen when the event occurs HAL and D-Bus are needed. (Note: HAL is now deprecated as it is being merged into udev). HAL is a single daemon responsible for discovering, enumerating and mediating access to most of the hardware on the host computer for desktop applications to which it provides a hardware abstraction layer.

23 Mass Storage Devices Over time numerous interfaces for connecting mass storage devices have been developed but the four main types of disks encountered today are : PATA Parallel Advanced Technology Attachment, also known as IDE SATA Serial Advanced Technology Attachment, the latest standard replacing PATA especially on desktops and laptops; SATA drive naming conventions uses the scsi sub system naming conventions with devices being labeled /dev/sd[az].,

24 Mass Storage Devices SCSI Small Computer System Interface disks are used in servers and other high end machines. SCSI provides high speed access as well as the ability to connect a large number of devices SAS serial SCSI, a new SCSI standard aimed at servers Besides the interface, the type of mass storage is also determined by the device itself. For example you can have SATA optical drives (CDROMs/DVDROMS) as well as hard disk and SCSCI disks and SCSI tape drives.

25 Identifying the correct device ID for BOOT device The purpose of listing the different type of mass storage devices and their naming conventions is to allow you to easily identify the device ID for your disks. The blkid utility, which replaces vol_id, can be used to query the on a device or search for a device with a specific UUID. blkid /dev/sda1 produces the following output:

26 Identifying the correct device ID for BOOT device /dev/sda1: UUID="c7d63e4b-2d9f-450a b8929ec8a6b" TYPE="ext4" showing that the first partition on the device sda has an ext4 filesystem and a UUID of c7d63e4b-2d9f-450a b8929ec8a6b blkid -U cc4b-4bfc-beb9-305e1f7f8bc9 searches for the device with the specified ID and returns /dev/sdb1. Alternatively you could look under /dev/disk/by-uuid to see which ids map to which devices as seen by the Linux kernel.

27 Hot plug & Cold plug Devices Hot plug and cold plug devices refer to the ability of a device to be inserted or removed while the computer is running (hot plug) or whether the machine has to be powered down before the device can be inserted or removed (cold plug). Typical hot plug devices are USB data sticks, mice or keyboards and some SATA drives, while cold plug devices include video cards, network cards and CPUs, although in high end server machines even these components can be hot pluggable. The benefit of hot plug devices is the ability to swap out faulty, or add additional, components without having to take the machine offline, a requirement for many production servers that need to maintain maximum uptime.

28 USB Support One of the most popular types of hotplug interfaces today is the Universal Serial Bus (USB) which is a communication architecture designed to connect devices to a PC. These devices are divided into five classes: Display Devices Communication Devices Audio Devices Mass Storage Devices Human Interface Devices (HID) The devices are plugged into a USB port which is driven by a USB controller. Support for USB controllers is present in the Linux kernel since version 2.2.7

29 USB Support There are 3 types of USB host controllers: OHCI (Compaq) UHCI (Intel) EHCI (USB v 2.0) - usb-ohci.o - usb-uhci.o - ehci-hdc.o Once a USB device is plugged into a PC we can list the devices with lsusb.

30 Device Drivers In Linux device drivers most drivers are provided as part of the kernel source code and can be compiled as modules which can be loaded and unloaded dynamically into of the kernel or are compiled directly into the kernel. The modular system makes it possible for 3rd parties to write device drivers and provide them as modules that can be loaded and unloaded without having to recompile the kernel. Most drivers are compiled as modules as this keep the kernel small and allows for far more drivers to be available that what would be practical if they were all compiled as part of the kernel.

31 Device Drivers The commands you need to know to manage device drivers under Linux are: lsmod lists currently install modules, modinfo query a module for dependency, author and parameter information insmod installs a module by providing a path to the driver, modprobe installs a module via module name and handles dependency resolution, rmmod remove

32 Boot the System When an x86 computer starts up it follows a predefined set of steps to boot the operating system: 1. On start up the CPU jumps to the address of the BIOS and proceeds to load it. The BIOS performs some checks and initializes hardware before locating the configured boot device. The boot device is configured in the BIOS user interface by setting the boot order of attached mass storage devices.

33 Boot the System 2. Once the boot device is located the BIOS proceeds to load the the Master Boot Record (MBR) of the boot device. The MBR is the first sector ( 512 bytes) of the boot device and contains the 1st stage boot loader with a partition table. 3. The 1st stage boot loader locates the partition of the 2nd stage boot loader by looking at the boot sectors of the partition marked as active / bootable.

34 Boot the System 4. The second stage boot loader has the task of loading the operating system for Linux; this means the Linux kernel and initial ram disk. The second-boot loader may present the user with a menu to select which kernel to boot and may even allow the user to boot heterogeneous operating systems (aka dual boot). 5. Once the 2nd stage boot loader has loaded the kernel it passes control over to it, The kernel starts and configures the CPU type, interrupt handling, the rest of memory management such as paging tables and memory paging, device initialization, drivers, etc.

35 Boot the System 6. Once the kernel is fully operational it starts an initial programme which by default is /sbin/init. The init programme sets up user space and starts the login shells and/or the graphical login. What services are started and the state of the machine after the init process has completed its initialization depends on the default runlevel and its configuration.

36 Boot the System

37 Boot the System When the 2nd sage boot loader is running, you are presented with an opportunity to pass additional parameters to the Linux kernel via a text console that is part of the boot loader. Typical parameters that you may pass to the kernel include: init overrides the process that is run by the kernel after it has finished loading. init=/bin/bash is used to bypass the login prompt in cases where the root password had been forgotten.

38 Boot the System root informs the kernel which device to use as the root filesystem. Often used when troubleshooting an incorrectly configured boot loader. E.g root = /dev/hda1 tells the kernel to use /dev/hda1 as the root device filesystem rather than what it has been configured to use noapic/nolapic tells the kernel not to use the advanced programmable interrupt controller or local advanced programmable interrupt controller for assigning IRQ and resources. This effectively turns off pnp in the Linux kernel. noacpi turns off the advance

39 Boot the System Once the kernel has finished loading it starts the init process. Init is responsible for checking and mounting file systems, and starting up configured services, such as the network, mail and web servers for example, it does this by entering its default runlevel. This is configured in the /sbin/init application configuration file /etc/inittab.

40 Boot the System A line in the inittab file has the following format: id:runlevel s:actions:process id 1-4 characters that identify the function, runlevels the runlevels for which the process will be executed, action One of a defined list of events for which the process should be executed or an instruction to init on what to do when the process is executed.

41 Boot the System The most commonly used actions are: wait init will wait till the process it is starting has completed before continuing, respawn tells init to restart the process whenever it terminates, this is useful for login processes. Ctrl-Alt-Del this traps the ctrl-alt-delete key combination, initdefault set the default runlevel powerfail and powerokwait are used to respond to notifications from attached UPS devices in the event of power failure and restoration

42 Runlevels, Rebooting & Shutting down the system Traditionally Linux has 7 runlevels numbered from 0-6. A runlevel defines the state of the computer after boot. Except for runlevels 0 and 6, the the allocation of runlevel numbers to particular configurations differ from distribution to distribution. Run level 0 is the runlevel used to halt the system and run level 6 is used for rebooting the system. Runlevel specific scripts are stored under /etc/rc.d/rc?.d, /etc/init.d/rc?.d or /etc/rc?.d or similar location where the? Is the number of the runlevel. Under each of these directories there are symbolic links back to a common set of scripts, under the /etc/rc.d, /etc/init.d, or /etc/rc.d/init.d (note the missing number from the paths), that all runlevels use.

43 Runlevels, Rebooting & Shutting down the system The remaining runlevels are typically assigned to the following configurations: 1) single user mode 2) multi-user, text mode, no servers 3) multi-user, text mode, servers 4) multi-user, GUI mode, no servers 5) multi-user, GUI mode, servers.

44 Runlevels, Rebooting & Shutting down the system Runlevel specific scripts are stored under /etc/rc.d/rc?.d, /etc/init.d/rc?.d or /etc/rc?.d or similar location where the? Is the number of the runlevel. Under each of these directories there are symbolic links back to a common set of scripts, under the /etc/rc.d, /etc/init.d, or /etc/rc.d/init.d (note the missing number from the paths), that all runlevels use. The symbolic links have a name that starts with a S or K, a number and then the name of the service the script controls.

45 Runlevels, Rebooting & Shutting down the system The S means that this is a script run with 'start' when the runlevel is entered and K signifies a script which is run when the run level is exited. The number indicates the order in which the scripts are run while the name indicates the services. The order of the scripts is determined by system requirements, for example the network needs to be configured before the mail or web server can be started. Startup scripts are simply bash scripts that call the appropriate application when run. These scripts take a standard set of parameters namely; start, stop, restart and reload. Some poorly written scripts may not implement all of the parameters.

46 Configuring Runlevels You can add or remove services from run levels by changing the symbolic links in the respective /etc/rc.d/rc?.d directory but various tools exists to enable easy management of these scripts. Under Debian systems and their derivatives you can use the update-rc.d or rc-update scripts, passing in the name of the service you wish to add or remove with the appropriate parameter, for example: update-rc.d disable 3 apache2 update-rc.d enable 3 apache2

47 Configuring Runlevels For rpm based distributions (like RedHat or CentOS) the command chkconfig does the same thing. chkconfig -del httpd will remove the apache web server from all configured run levels, chkconfig -add httpd will add the apache web server to all default runlevel, chkconfig -level 3 httpd on will add apache to runlevel 3

48 Starting & Stopping Services You may also stop and start services at runtime. On Debianbased systems, by either invoking the start-up script directly on debian based systems with the appropriate parameter i.e. start for starting the service and stop for halting the service. /etc/init.d/apache2 stop /etc/init.d/apache2 start On Redhat based systems you can use the service command to stop and start services. service httpd start service httpd stop

49 EXERCISE 1.1 examin hardware configuration 1. Thoroughly examine the following files and directories: /proc/ioports /proc/interrupts /proc/iomem /proc/dma /etc/rc.d/ /etc/rc.d/rc?.d /dev/* 2. Check kernel boot options (to do so you need to find the grub.conf file, for example using /etc/grub.conf symlink)

50 EXERCISE 1.2 Check the last boot status 1. Sometimes the boot process does not finish correctly. In such a case you can check what went wrong for example by running dmesg command or, in order to troubleshoot the boot phase when services are starting, you can check log files via examining the /var/log/* files, mainly /var/log/messages/.

51 EXERCISE 1.3 Check system boot and shutdown process 1. Check /etc/inittab file and check the default runlevel (find the initdefault option). Then identify appropriate startup directory for the runlevel and examine the order in which services are starting and stopping while boot / shutdown process. 2. Reboot your system (shutdown r now) and check which services are being stopped and how this corresponds with the K scripts. Then, while the system is booting, check if the services starting sequece corresponds with the S scripts order.

52 EXERCISE 1.4 Add remove service from runlevels 1. Using chkconfig l check which services are running in which runlevels. 2. Use manual (man command) or read lecture notes in order to check how can you remove a service to be omitted while entering a specified runlevel (for example your default runlevel).

53 EXERCISE 1.4 Add remove service from runlevels - continued 3. Remove one selected service from all runlevels (for example network) and check appropriate runlevel rc?.d directory to see what happened. 4. Add the service back to all runlevels and compare what has changed in the rc?.d directory.