This chapter provides information about the Filesystem Hierarchy
Standard (FHS) and Linux Standard Base (LSB). Various
software packages and special features, such
as booting with ``initrd'', linuxrc, and the
rescue system, are described in detail.
SuSE Linux strives, as far as possible, to conform to the File system Hierarchy Standard (FHS, package fhs). See also http://www.pathname.com/fhs/. For this reason, it is sometimes necessary to move files or directories to their ``correct'' places in the file system.
SuSE supports the Linux Standard Base project. Current information on this can be found at http://www.linuxbase.org.
The LSB specification version for 9.0 is 1.3. From now on, the Filesystem Hierarchy Standard (FHS) is included in the specification and defines settings, such as the package format and the initialization of the system. See Chapter 12.
TEX is a complete typesetting system which runs on various platforms. It is expandable with macro packages like LATEX. It consists of very many single files that have to be assembled according to the TEX Directory Structure (TDS) (ref. ftp://ftp.dante.de/tex-archive/tds/ teTeX is a compilation of current TEXapplications.
teTeX is employed in SuSE Linux with a configuration that complies with the requirements of both the TDS and the FHS.
To make it easier to set up an FTP server, the package ftpdir includes an example environment. This is installed in /srv/ftp.
Apache is the standard web server in SuSE Linux. Together with the installation of Apache, some example documents are made available in /srv/www. To set up your own web server, include your own DocumentRoot in /etc/httpd/httpd.conf and store your files (documents, picture files) accordingly.
Users can make personal entries in /.profile or in /.bashrc respectively. To ensure the correct processing of these files, it is necessary to copy the basic settings from /etc/skel/.profile or /etc/skel/.bashrc respectively into the home directory of the user. It is recommended to copy the settings from /etc/skel following an update. Execute the following shell commands to prevent the loss of personal adjustments:
mv ~/.bashrc ~/.bashrc.old cp /etc/skel/.bashrc ~/.bashrc mv ~/.profile ~/.profile.old cp /etc/skel/.profile ~/.profile
The personal adjustments then need to be copied back from the files *.old.
The cron tables are now located in /var/cron/tabs. /etc/crontab serves as a system-wide cron table. Enter the name of the user who should run the command directly after the time table (see File 23, here SuSE @nohyphen root is entered). Package-specific tables, located in /etc/cron.d, have the same format. See [8]cron.
/etc/crontab cannot be processed with crontab -e. It must be loaded directly into an editor, modified, then saved.
A number of packages install shell scripts to the directories /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly, whose instructions are controlled by /usr/lib/cron/run-crons. /usr/lib/cron/run-crons is run every fifteen minutes from the main table (/etc/crontab). This guarantees that processes that may have been neglected can be run at the proper time.
The daily system maintenance jobs have been distributed to various scripts for reasons of clarity ( package aaa_base). Apart from aaa_base, /etc/cron.daily thus contains for instance the components backup-rpmdb, clean-tmp or clean-vi.
There are a number of system services (``daemons''), which, along with the kernel itself, regularly record the system status and specific events to log files. This way, the administrator can regularly check the status of the system at a certain point in time, recognize errors or faulty functions, and troubleshoot them with pinpoint precision. These log files are normally stored in /var/log as specified by FHS and grow on a daily basis. The package logrotate package helps control the growth of these files.
The old settings listed below will be adopted when updating from a version older than SuSE Linux 8.0:
Configure logrotate with the file /etc/logrotate.conf. In particular, the include specification primarily configures the additional files to read. SuSE Linux ensures that individual packages install files in /etc/logrotate.d (e.g., syslog or yast).
logrotate is controlled through cron and it is called daily by /etc/cron.daily/logrotate.
Note
The create
option reads all settings made by the administrator in
/etc/permissions*. Ensure that no conflicts arise
from any personal modifications.
For some GNU applications (e.g. , tar) the man pages are no longer maintained. They have been replaced by info files. info is GNU's hypertext system. Typing info info gives a starting help for using info. info can be launched via emacs -f info or on its own with info. The programs tkinfo and xinfo are easy to use or you can access the SuSE help system.
With the ulimit (user limits) command, it is possible to set limits for the use of system resources and to have these displayed. ulimit is especially useful for limiting the memory available for applications. With this, an application can be prevented from using too much memory on its own, which could bring the system to a standstill.
ulimit can be used with various options. To limit memory usage, use the options listed in Table 11.1.
System-wide settings can be made in /etc/profile. There, creating core files must be enabled, needed by programmers for ``debugging''. A normal user cannot increase the values specified in /etc/profile by the system administrator, but he can make special entries in his own /.bashrc.
Details of memory must be specified in KB. For more detailed information, see bash.
Note
Not all shells support ulimit directives. PAM (for
instance, pam_limits) offers comprehensive adjustment
possibilities should you depend on encompassing settings for
these restrictions.
The free command is somewhat misleading if your goal is to find out how much RAM is currently being used. The relevant information can be found in /proc/meminfo. These days, users, who have access to a modern operating system such as Linux, should not really have to worry much about memory. The concept of ``available RAM'' dates back to before the days of unified memory management. The slogan free memory is bad memory applies well to Linux. As a result, Linux has always made the effort to balance out caches without actually allowing free or unused memory.
Basically, the kernel does not have direct knowledge of any applications or user data. Instead, it manages applications and user data in a ``page cache''. If memory runs short, parts of it will be either written to the swap partition or to files, from which they can initially be read with the help of the mmap command (see [2]mmap).
Furthermore, the kernel also contains other caches, such as the ``slab cache'' where the caches used for network access are stored. This may explain differences between the counters in /proc/meminfo. Most, but not all of them, can be accessed via /proc/slabinfo.
Domain name resolution is handled through the file /etc/resolv.conf. Refer to 13 on this.
This file is updated by the script /sbin/modify_resolvconf exclusively, with no other program having permission to modify /etc/resolv.conf directly. Enforcing this rule is the only way to guarantee that the system's network configuration and the relevant files are kept in a consistent state.
GNU Emacs is a complex work environment. More information is available at http://www.gnu.org/software/emacs/. The following sections cover the configuration files processed when GNU Emacs is started.
On start-up, Emacs reads several files containing the specifications of the user, system administrator, and distributor for customization or preconfiguration. The initialization file /.emacs is installed to the home directories of the individual users from /etc/skel. .emacs, in turn, reads the file /etc/skel/.gnu-emacs. If a user wants to customize the program, the .gnu-emacs should be copied to the home directory and the desired settings should be specified there:
.gnu-emacs defines the file /.gnu-emacs-custom as custom-file. If users specify settings with the customize options, these will be saved to /.gnu-emacs-custom.
When the package emacs is installed in SuSE Linux, the file site-start.el is installed in the directory /usr/share/emacs/site-lisp. The file site-start.el is loaded before the initialization file /.emacs. Among other things, site-start.el makes sure that special configuration files distributed with Emacs add-on packages are loaded automatically (e.g., the package psgml). Configuration files of this type are also located in /usr/share/emacs/site-lisp and always begin with suse-start-. The local system administrator can specify system-wide settings in default.el.
More information about these files is available in the Emacs info file under Init File: info:/emacs/Init File. Information about how to prevent these files from loading is also provided at this location.
The components of Emacs are split in several packages:
As soon as the Linux kernel has been booted and the root file system (/) mounted, programs can be run and further kernel modules can be integrated to provide additional functions. To mount the root file system, certain conditions must be met. The kernel needs the corresponding drivers to access the device on which the root file system is located (especially SCSI drivers). The kernel must also contain the code needed to read the file system (ext2, reiserfs, romfs, etc.). It is also conceivable that the root file system is already encrypted. In this case, a password is needed to mount the file system.
For the problem of SCSI drivers, a number of different solutions are possible: the kernel could contain all imaginable drivers. This might be a problem because different drivers could conflict with each other. Also, the kernel will become very large because of this. Another possibility is to provide different kernels, each one containing just one or a few SCSI drivers. This method also has the problem that a large number of different kernels are required, a problem then increased by the differently optimized kernels (Pentium optimization, SMP). The idea of loading the SCSI driver as a module leads to the general question answered by the concept of an initial ramdisk: creating a way of being able to run user space programs even before the root file system is mounted.
The initial ramdisk (also called ``initdisk'' or ``initrd'') solves precisely the problems described above. The Linux kernel provides an option of having a small file system loaded to a RAM disk and running programs there before the actual root file system is mounted. The loading of initrd is handled by the boot loader (GRUB, LILO, etc.). Boot loaders only need BIOS routines to load data from the boot medium. If the boot loader is able to load the kernel, it can also load the initial ramdisk. Special drivers are not required.
The boot loader loads the kernel and the initrd to memory and starts the kernel. The boot loader informs the kernel that an initrd exists and where it is located in memory.
If the initrd was compressed (which is typically the case), the kernel decompresses the initrd and mounts it as a temporary root file system. A program called linuxrc is then started. This program can now do all the things necessary to mount the proper root file system. As soon as linuxrc finishes, the temporary initrd is unmounted and the boot process continues as normal with the mounting of the proper root file system. Mounting the initrd and running linuxrc can be seen as a short interlude during a normal boot process.
The kernel tries to remount initrd to the /initrd directly after the actual root partition is booted. If this fails because the mount point /initrd does not exist, for example, the kernel will attempt to unmount initrd. If this does not work, the system is fully functional, but the memory taken up by initrd can no longer be unlocked and thus will no longer be available.
As soon as linuxrc terminates, initrd is unmounted and discarded, the boot process carries on as normal, and the kernel mounts the real file system. What is mounted as the root file system can be influenced by linuxrc. It just needs to mount the /proc file system and write the value of the real root file system in numerical form to /proc/sys/kernel/real-root-dev.
The file /boot/initrd is the initial ramdisk. It can be, but does not have to be, compressed.
The initrd has already been used for some time for the installation: the user can load modules and make the entries necessary for an installation (above all, for the source medium). linuxrc then starts YaST, which carries out the installation. When YaST has finished, it tells linuxrc where the root file system of the freshly installed system is located. linuxrc writes this value to /proc, terminates, and informs the kernel to continue booting into the newly installed system.
For an installation of SuSE Linux, you are, from the very beginning, booting the system being installed. A real reboot after installation only takes place if the kernel does not match the modules installed in the system. Because SuSE Linux uses a kernel for uniprocessor systems during installation, a reboot is only necessary if an SMP kernel was installed in the system with the corresponding modules.
In the past, YaST has provided more than forty kernels for installing in the system, with the only basic difference a specific SCSI driver. This was necessary to be able to mount the root file system after booting. Further drivers could then be loaded afterwards as modules. Because optimized kernels are now available, this concept is no longer feasible -- by now, over one hundred kernel images would be needed.
This is why an initrd is used now, even to start the system normally. The way it is used is similar to that for an installation. The linuxrc used here, however, is simply a shell script with the task of loading a given module. Typically, this is just one single module -- the very SCSI driver needed to access the root file system.
An initrd is created by means of the script mkinitrd (previously mk_initrd). In SuSE Linux, the modules to load are specified by the variable INITRD_MODULES in /etc/sysconfig/kernel. After installation, this variable is automatically occupied by the correct values (the installation linuxrc knows which modules were loaded). The modules are loaded in exactly the order in which they appear in INITRD_MODULES. This is especially important if a number of SCSI drivers are used, because otherwise the names of the hard disks would change. Strictly speaking, it would be sufficient just to load those drivers needed to access the root file system. Because the automatic loading of additional SCSI drivers may cause problems (how should it be ``triggered'' if hard disks hang on the second SCSI adapter), all SCSI drivers needed at the installation are loaded by means of initrd.
Note
Because the loading of the initrd with the boot loader runs
in the same way as loading the kernel itself (LILO notices, in its
map file, the location of the files), you must run lilo if
LILO after every change in initrd, if LILO is used as the
boot loader. If grub is used for
booting, this step is not needed.
A self-compiled kernel can often lead to the following problem: out of habit, the SCSI driver is hard-linked to the kernel, but the existing initrd remains unchanged. When you boot, the following occurs. The kernel already contains the SCSI driver, so the hardware is detected. initrd, however, now tries to load the driver again as a module. With some SCSI drivers, especially with aic7xxx, this leads to the system blocking. Strictly speaking, this is a kernel error. An already existing driver should not be allowed to be loaded again as a module. The problem is already known from another context, however (serial drivers).
There are several solutions to the problem: either configure the driver as a module (then it will be correctly loaded in the initrd) or remove the entry for initrd from the file /etc/lilo.conf. An equivalent to the latter solution is to remove the variable INITRD_MODULES then run mkinitrd, which then realizes that no initrd is needed.
It is quite possible in the future that an initrd will be used for many more and much more sophisticated things than loading modules needed to access /.
/usr/src/linux/Documentation/ramdisk.txt
/usr/src/linux/Documentation/initrd.txt
[4]initrd
linuxrc is started during the boot of the kernel, usually as a prelude to a Linux system installation, before the ``actual'' booting commences (the kernel must first be properly configured, of course). This allows you to boot a small, modularized kernel and to load the few drivers needed as modules from a floppy disk.
If needed, linuxrc assists in loading the related drivers.
You can also use linuxrc as a boot tool for an already installed system. You can even start a totally independent RAM disk-based rescue system, for example, if something serious should happen to your hard disk or you have simply forgotten your SuSE @nohyphen root password. More about this below, in Section 11.
After you have selected the language and keyboard, find yourself in linuxrc's main menu (see Figure 1.2). Normally, linuxrc is used to start Linux. Go to the start menu to start an installation (` Start installation / system').
In ` System Information' (Figure 11.1), check a number of other things, besides kernel messages, such as the I/O addresses of PCI cards or the size of the main memory recognized by Linux.
You can check some system information in ` System information'. Here, check the used interrupts, I/O ports used, main memory, and recognized PCI devices as detected by Linux.
The next lines show how a hard disk and a CD-ROM connected to an (E)IDE controller announce their start. In this case, you do not need to load additional modules:
hda: ST32140A, 2015MB w/128kB Cache, LBA, CHS=1023/64/63 hdb: CD-ROM CDR-S1G, ATAPI CD-ROM drive Partition check: hda: hda1 hda2 hda3 < hda5 >
If you booted a kernel that already had a SCSI driver compiled, you do not need this SCSI driver as a module as well. Quite typical announcements when loading SCSI adapters and connected devices might look like this:
scsi : 1 host. Started kswapd v 1.4.2.2 scsi0 : target 0 accepting period 100ns offset 8 10.00MHz FAST SCSI-II scsi0 : setting target 0 to period 100ns offset 8 10.00MHz FAST SCSI-II Vendor: QUANTUM Model: VP32210 Rev: 81H8 Type: Direct-Access ANSI SCSI revision: 02 Detected scsi disk sda at scsi0, channel 0, id 0, lun 0 scsi0 : target 2 accepting period 236ns offset 8 4.23MHz synchronous SCSI scsi0 : setting target 2 to period 248ns offset 8 4.03MHz synchronous SCSI Vendor: TOSHIBA Model: CD-ROM XM-3401TA Rev: 0283 Type: CD-ROM ANSI SCSI revision: 02 scsi : detected 1 SCSI disk total. SCSI device sda: hdwr sector= 512 bytes. Sectors= 4308352 [2103 MB] [2.1 GB] Partition check: sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 sda8 >
Select which kinds of modules you need. If you booted via disk, the corresponding data must be read by linuxrc and displayed in a list.
If you have booted from CD or from DOS (via loadlin), these modules are already set in linuxrc. This saves tedious loading, but requires additional memory.
linuxrc offers a list of available drivers. On the left is the name of the module and, on the right, a short description of its usage. For some components, there are a variety of drivers from which to choose (even newer alpha drivers).
When you have found a suitable driver, move to it with the cursor and press . This opens a dialog box in which to add additional parameters for this module.
Beware that -- in contrast to entering the parameters at the kernel prompt (as in MILO, LILO, or SYSLINUX) -- multiple parameters for the same module must be separated here by a blank space.
In most cases, it is not necessary to specify the hardware in detail. Most drivers find their components automatically. Specifying parameters is only necessary if you have a network card or an older CD-ROM drive with a proprietary controller card. If in doubt, just try pressing .
Recognizing and initializing certain hardware can take some time. Switching to virtual console 4 ( + F4) lets you watch the kernel messages while loading. SCSI drivers need a while, as they have to wait for each device to load.
The messages are displayed by linuxrc so you can verify that everything ran smoothly. If it fails, the messages might give a hint as to why.
Once you have set up hardware support via modules, proceed to the ` Start installation / system' menu.
From here, a number of procedures can be started: ` Start installation' (an update is also started from this item), ` Boot installed system' (the root partition must be known), ` Start rescue system' (refer to Section 11), and ` Eject CD'.
` Start Live-CD' is only available if you booted a ``LiveEval CD''. Download ISO images from the FTP server (live-eval-<VERSION>):
Tip
The item ` Start
Live-CD' can be of great use if, for example, you want to test, without
actually installing, if the computer in question or the
laptop you might want to buy is at all compatible with SuSE Linux -- such a test ought to be possible in every modern PC shop, without
any trouble.
For the installation (Figure 11.5), choose various sources for the installation and similarly for the rescue system (see Figure 11.5).
SuSE Linux contains several Linux rescue systems so that, in emergencies, your Linux partitions on the hard disks are reachable ``from the outside'': via a boot disk or the ``Rescue'' System, loaded from disk, CD, the network, or the SuSE FTP server. There is also a bootable SuSE Linux CD (the ``LiveEval CD'') that can be used as a rescue system. The rescue system includes several help programs with which you can remedy large problems with inaccessible hard disks, misconfigured configuration files, or other similar problems.
Another aspect of the rescue system is Parted, which is used for modifying the partition size. This program can be launched from inside the rescue system itself, if you do not want to take advantage of the resizer integrated in YaST. Information on Parted can be found at:
Tip
Always have a boot and rescue disk at hand,
because the slight effort for creating and maintaining the disk is negligible
in comparison to the time wasted and work involved when, in the case of
emergency, you cannot access your system or your CD-ROM drive.
There are three ways to set up the root file system on the disk:
As of Version 8.0, the rescue disk is currently based on libc5 (SuSE Linux 5.3), since it is possible in this to save some programs, such as an editor, fdisk, or e2fsck to a disk.
Note
The rescue disk cannot be mounted, because it is not a file
system. It
only contains the compressed images of one. Directions for reading the file
system are in the following paragraph.
To read the image, you will need to decompress the image file then mount the decompressed image as user SuSE @nohyphen root. If your Linux kernel support the loop device, the procedure is as follows:
The rescue system is launched by the SuSE boot disk you created or by your bootable CD or DVD. It is required that the disk and CD-ROM or DVD drives are bootable. If necessary, change the boot series in the CMOS setup. Following are the steps for starting the rescue system:
Subsequently, we will introduce a few tips on selection options:
Regardless of the medium chosen, the rescue system will be decompressed, loaded onto a RAM floppy disk as a new root file system, mounted, and started. Now it is ready for use.
A shell and lots of other useful utilities (net tools), such as the mount program, can be found in the /bin directory. In sbin, find important file and network utilities for reviewing and repairing the file system (e.g., e2fsck).
Furthermore, this directory contains the most important binaries for system maintenance, such as fdisk, mkfs, mkswap, mount, mount, init, and shutdown, as well as ifconfig, route, and netstat for maintaining the network.
An editor, vi, is located in /usr/bin. Also, tools like grep, find, and less, along with telnet are available.
To mount your SuSE Linux system using the rescue system, use the mount point /mnt. You can also use or create another directory.
As an example, assume your normal system is put together according to the /etc/fstab shown in the example File 26.
Caution
Pay attention to the order of steps outlined in the following section
for mounting the various devices.
To access your entire system, mount it step-by-step in the /mnt directory using the following commands:
Now, you can access your entire system and, for example, correct mistakes in configuration files such as /etc/fstab, /etc/passwd, and /etc/inittab. The configuration files are now located in the /mnt/etc directory instead of in /etc.
To recover even completely lost partitions with the fdisk program by simply setting it up again, determine where on the hard disk the partitions were previously located and make a printout of the /etc/fstab directory as well as the output of the command
Instead of the <disk> variable, insert, in order, the device names of your hard disks, such as hda.
The SuSE Linux rescue system contains the utilities e2fsck and dumpe2fs (for diagnosis). These should remedy most problems.
In an emergency, man pages often are not available. That is why we have included them in this manual in Appendix C.
Example: If mounting a file system fails due to an invalid superblock, the e2fsck program would probably fail, too. If this were the case, your superblock may be corrupted, too. There are copies of the superblock located every 8192 blocks (8193, 16385, etc.). If your superblock is corrupted, try one of the copies instead. This is accomplished by entering the command:
The -f option forces the file system check and overrides e2fsck's error so that -- since the superblock copy is intact -- everything is fine.
Linux is a multiuser and multitasking system. The advantages of these features can be appreciated, even on a stand-alone PC system.
In text mode, there are six virtual consoles available. Switch between them using + F1 to + F6. The seventh console is reserved for X11. More or fewer consoles can be assigned by modifying the file /etc/inittab.
To switch to a console from X11 without leaving X11, use + + F1 to + + F6. + F7 then returns to X11.
To standardize the keyboard mapping of programs, changes were made to the following files:
These changes only affect applications that make use of terminfo entries or whose configuration files are changed directly (vi, less, etc.). Other non-SuSE applications should be adjusted to these defaults.
Under X, the compose key (``multikey'') can be accessed using the key combination + (right). Also see the corresponding entry in /usr/X11R6/lib/X11/Xmodmap.
SuSE Linux is, to a very large extent, internationalized and can be modified for local needs in a flexible manner. In other words, internationalization (``I18N'') allows specific localizations (``L10N''). The abbreviations I18N and L10N are derived from the first and last letters of the words and, in between, the number of letters omitted.
Settings are made via LC_* variables defined in the file /etc/sysconfig/language. This refers not only to ``native language support'', but also to the categories Messages (Language), Character Set, Sort Order, Time and Date, Numbers, and Money. Each of these categories can be defined directly via its own variable or indirectly via a variable in the file language (see [5]locale).
The current setting can be shown with the command locale.
The other variables can be set via the YaST sysconfig editor.
The value of such a variable contains the language code, country code, encoding, and modifier. The individual components are connected by special characters:
You should always set the language and country codes together. Language settings follow the standard ISO 639 (http://www.evertype.com/standards/iso639/iso639-en.html and http://www.loc.gov/standards/iso639-2/). Country codes are listed in ISO 3166, see (http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html). It only makes sense to set values for which usable description files can be found in /usr/lib/locale. Additional description files can be created from the files in /usr/share/i18n using the command localedef. A description file for en_US.UTF-8 (for English and United States) can be created with:
This sets the variable to English language, country to United States, and the character set to ISO-8859-1. This character set does not support the Euro sign, but it will be useful sometimes for programs that have not been updated to support ISO-8859-15. The string defining the charset (ISO-8859-1 in our case) will then be evaluated by programs like Emacs.
If you use a Unicode xterm, it is necessary to specify UTF-8 as well. To achieve this, make a small shell script called uxterm to start xterm with UTF-8 loaded each time. See File 27.
uxterm to Start a Unicode xterm
#!/bin/bash
export LANG=en_US.UTF-8
xterm -fn \
'-Misc-Fixed-Medium-R-Normal-18-120-100-100-C-90-ISO10646-1' \
-T 'xterm UTF-8' $*
SuSEconfig reads the variables in /etc/sysconfig/language and writes the necessary changes to /etc/SuSEconfig/profile and /etc/SuSEconfig/csh.cshrc. /etc/SuSEconfig/profile is read or ``sourced'' by /etc/profile. /etc/SuSEconfig/csh.cshrc is sourced by /etc/csh.cshrc. This makes the settings available system-wide.
Files in the category Messages are, as a rule, only stored in the language directory (e.g. , en) to have a fallback. If you set LANG to en,_US and the ``message'' file in /usr/share/locale/en_US/LC_MESSAGES does not exist, it will fall back to /usr/share/locale/en/LC_MESSAGES.
A fallback chain can also be defined, for example, for Breton 
French or for Galician Spanish
Portuguese:
If desired, use the Norwegian variants ``nynorsk'' and ``bokmål'' instead (with additional fallback to no):
or
Note that in Norwegian, LC_TIME is also treated differently.
![\includegraphics[width=\linewidth]{linuxrc_sysinfo}](img28.png)
![\includegraphics[width=.9\linewidth]{linuxrc_module}](img29.png)
![\includegraphics[width=.9\linewidth]{linuxrc_scsi}](img30.png)
![\includegraphics[width=.9\linewidth]{linuxrc_param}](img31.png)
![\includegraphics[width=\linewidth]{linuxrc_installmedium}](img4.png)
![\includegraphics[width=.8\linewidth]{linuxrc_rescue_medium}](img32.png)
![\includegraphics[width=\linewidth]{linuxrc_network_protocol}](img33.png)