| Red Hat Docs > Manuals > Red Hat Linux Manuals > Red Hat Linux 7.2 > |
Copyright © 2001 by Red Hat, Inc.
| Abstract |
This document describes features that are new to Red Hat Linux 7.2, but may not have been available prior to our documentation being finalized. The Release Notes can also be found on the Red Hat Linux CD #1. |
We now use GRUB as the default boot loader. However, LILO is still available for legacy installations.
GRUB supports a password that controls access to the GRUB shell; because of GRUB's ability to run arbitrary commands, this can be an important aspect in maintaining system security. Please carefully consider the implications of this before deciding whether or not to set a GRUB password. This password is encrypted using MD5; see the grub-md5-crypt man page for more information.
When performing an upgrade from a previous version of Red Hat Linux, it is necessary to write the boot loader out to the same location that was used in the previous installation. For example, if the boot loader was written to the master boot record (MBR) originally, when the system is upgraded you must write the boot loader to the MBR as well. Otherwise, the system will most likely not be able to boot.
If you are using the GRUB boot loader, please note that you do not have to re-run GRUB after upgrading your kernel. This is different from the LILO boot loader, which required re-running LILO after each change. Simply modifying GRUB's configuration file (/boot/grub/grub.conf) to point to your new kernel will allow GRUB to boot it.
If you decide to switch to using the GRUB boot loader after installation, or you need to reinstall GRUB, you may do so using the /sbin/grub-install command. The command syntax must include the device specification showing where the boot loader should be installed. For example:
/sbin/grub-install /dev/hda |
To boot into single-user mode from GRUB, do the following from the GRUB menu screen:
Select the desired kernel.
Press the
Use the arrow keys to navigate to the kernel line (for example: kernel /vmlinuz-2.4.7-1 ro root=/dev/hda2)
Press the
Add the argument single to the end of the
line and press
Press the
The Disk Druid user interface has been redesigned to incorporate an interface that takes better advantage of a graphical environment.
Disk Druid can now create primary partitions by specifying a cylinder range.
Disk Druid now supports the ability to specify that a new partition must be created as a primary partition.
Text mode installations now have support for creating RAID devices.
Specifying spare drives for RAID devices is now supported.
Autopartitioning now allows you to specify which drives to use, and which to avoid touching at all.
There is now an option to view and edit the results of autopartitioning (for graphical installations only -- under text mode you will always see the results).
The ext3 journaling filesystem is now available.
Pre-existing filesystems may be selected for reformatting during the installation.
Pre-existing ext2 filesystems may be migrated to ext3 during installs and upgrades. This process does not affect the data on the filesystem.
Many additional sanity checks are made against user-created mount points; this should avoid most common problems (such as a / mount point of only 5 MB).
GNU Parted is now used as the partitioning backend, replacing the libfdisk library.
Parted determines the filesystem type by examining the actual filesystem written onto a partition, instead of relying on the filesystem type written in the partition table. This can lead to confusing situations when there are preexisting partitions.
For example, if you use fdisk to change the partition type of a VFAT partition to ext2, parted will still see this as a VFAT partition because there is still a VFAT filesystem on it. In this example, you must explicitly reformat the partition as ext2 via the Disk Druid interface before the partition will be treated as ext2. Anytime you use fdisk inside the installation program, and then proceed to the Disk Druid screen to set mount points, you should also review and edit each partition (in Disk Druid) and appropriately set its format options.
During the installation process, a kickstart file reflecting the user-selected installation options is written to /root/anaconda-ks.cfg. This file can be used to create a installation similar to the newly-installed system.
Kickstart runs in graphical mode (when this mode is available). However, it can be switched back to text mode by using the text directive in the kickstart file.
Kickstart Configurator (ksconfig) now supports creating partitions on a specific drive and an existing drive, configuring X, writing pre-installation and post-installation scripts, performing an upgrade, and the new kickstart features present in this release. It also allows users to preview their choices before saving the file, and has an integrated manual to assist in easy kickstart file creation.
Kickstart has several new features/directives:
interactive — reads in kickstart file, goes through install with UI filled in with kickstart values. It will wait for user input at each screen.
text — forces kickstart to run in text mode. The default is now to run in graphical mode.
The clearpart directive now accepts a --ondisk option:
--ondisk — you can specify which drives to create partitions on now.
A new command bootloader, which supports the following:
--append <args> — append <args> on the kernel line
--useLilo — use LILO instead of GRUB
--md5pass <crypted MD5 password> — password for GRUB to use
Added flags for xconfig directive to define:
--resolution 1024x768 — set screen resolution (1024 by 768 in this example)
--depth 16 — set display color depth (set to 16-bit color in this example)
The drivers.img driver disk image has been split into multiple disk images. For more information, please read the README file in the images/ directory on CD #1 (or in the install tree you are using for network installs).
The individual package selection screen now supports a flat view of all packages.
For FTP-based installations, it is now possible to loopback mount the Red Hat Linux ISO images on an FTP server. The ISO images should be loopback mounted as /disc1, /disc2, and so on — in the same directory. This directory should be then be specified when an FTP-based installation is started.
In order to maximize space in the install image, the BusyBox program now provides support for many commonly-used commands.
Rescue mode now prompts before attempting to mount filesystems from the installed system.
Partitionless installations are no longer supported; however, upgrades to previous partitionless installations are still supported.
USB floppy devices are now supported during installation.
| Next | ||
| Distribution General Notes |