Booting problems with Linux
We have previously looked at some of the booting and filesystem aspects of Linux and PCs, including partitions and image files.
This time, we’ll take a much closer look at the initial booting process and how to overcome a very common problem associated with removing Linux from a computer that’s also running Windows.
Most of the problems experienced with booting into Linux (or any PC operating system) lie with the Bios, which is an archaic piece of software dating back to the first PCs, and on which Microsoft Dos and older versions of Windows used to rely.
These days, the Bios is used largely just to initialise the hardware and start the operating system, but its limitations still have an impact on how operating systems are installed.
After switching on a PC, the Bios must find and start the operating system on the hard drive. To do that, it loads the first sector of the hard drive into memory and executes the code there. A sector is 512 bytes, and is the smallest chunk of data a hard drive handles. This first sector is commonly referred to as the Master Boot Record (MBR) and contains the boot code, together with the disk’s partition table.
MBR structure
At just half a kilobyte, a sector isn’t a huge amount of space to do anything with, especially when you compare it with a typical 200GB hard drive (around 420 million sectors). It consists of two fixed sections. The first 446 bytes are reserved for executable code and it is this that is executed directly via the Bios on startup. After that comes 64 bytes for the partition table and a final fixed two-byte code to identify the sector as a valid MBR.
We recently saw in Hands On that a standard PC can have only four primary partitions, and now it may become clearer why: with just 64 bytes available for the partition table, that leaves 8 bytes per partition – just enough to locate each one on the disk, set the filesystem type and bootable flag. Take a look at screen 1 for an example of a real MBR, viewed in a hex editor. The final two bytes (0x55 and 0xaa) mark the end of the MBR. The partition table starts at position 0x01be (marked in red in the screenshot).
The fixed structure of the MBR means that only the final 66 bytes (including the 2 byte signature) are necessary for a valid MBR and partition table, since the first 446 bytes are used only for booting. It is here that the common Dos bootloader used by Windows sits, or if Grub is installed, the first stage of the bootloader.
In the case of the former, the code performs a very simple task: it scans the partition table for any partition marked as bootable (or ‘active’ in Dos terms) and then executes that. It cannot do anything else, which is why it’s unsuitable for any kind of dual-boot configuration or for starting a Linux kernel. Grub, on the other hand, is a far more versatile piece of software, but as such it needs a lot more space than 446 bytes can afford.
The first stage of the Grub bootloader does little except to locate the next stage. Due to the awkward restrictions imposed by the Bios, a small amount of extra space is available directly after the MBR. If you look at a partition table with Linux’s fdisk and set the units to sectors, you will see that the first partition begins at sector 63. You can see this for yourself by running the following command, assuming your hard drive is /dev/hda:
$ sudo fdisk -l -u /dev/hda
We know that the first sector is used for the MBR, which leaves 62 sectors spare, or 31KB (62x512 bytes). This anomaly is because of the old ‘cylinders, heads and sectors’ method for locating a position on a hard drive. Starting at sector 63 allows the first partition to start on a cylinder boundary; Linux doesn’t worry about this, but it’s maintained for compatibility. Grub uses this extra space for its ‘stage 1.5’ code.
The next stage of Grub must be loaded from a regular filesystem on a partition. Grub can read most partition types, including the standard Linux ones and Fat. This is where the images for a graphical interface version of Grub are found, too, and where the configuration data for the menu is kept.
On a typical Linux system, this data is found in /boot, which may be on its own partition or part of the root (main) partition.
MBR problems
This multi-stage setup gives a very flexible approach to booting, but also leads to problems if you simply delete Linux from your computer in a dual-boot scenario.
If the partition with the second stage is deleted, Grub can’t load itself completely, so the boot will fail.
All your data is, of course, still present and safe on any other partitions, but there will be no way to boot the computer’s hard drive directly without rectifying the problem.
One solution is to restore the Dos MBR that Windows installs. You can do this from an installation CD or by running the fdisk /mbr command from a Windows 98 CD. This will replace the boot part of the MBR without modifying the partition table. As above, this code will simply boot the primary partition marked active.
Grub ignores this flag, allowing you to boot any partition, primary or extended, from any hard drive. There is an alternative open source install-mbr command for Linux that will install a compatible piece of code instead.
Another option is to make a backup of your MBR’s boot code before you install Grub. The easiest way to do this is from Linux, using the dd command, which we’ve seen a number of times over the past few months. Since we do not want to modify the partition table, we need only copy the first 446 bytes:
$ sudo dd if=/dev/hda of=boot.bin bs=446 count=1
You can write this back to your hard drive with the reverse options:
$ sudo dd if=boot.bin of=/dev/hda
No size options are necessary here, since you are writing the entire file to the hard drive. If you have a full backup copy of your MBR, as I have re commended you always do, you can write the first 446 bytes only using a version similar to the first command:
$ sudo dd if=mbr.bin of=/dev/hda bs=446 count=1
This issue presents itself also in the reverse case; if you install a copy of Windows after Linux, it will erase the boot code on the MBR and replace it with the Dos version, preventing you from booting into another operating system. To get around this, back up your Grub boot code before installing Windows, and then rewrite it after the installation is complete.
There are other ways to get around these problems. One method is to use a small separate partition for /boot. If you delete the main Linux partition, Grub’s files are still intact and you will still be able to boot successfully. Another option is to install Linux onto a primary partition, mark it as active and install Grub onto this partition instead of the MBR. This leaves the Dos MBR in place, which in turn boots Grub.
This is the easiest to maintain, but does require that Grub is placed onto a primary partition so that the Dos boot code can start it. Most distributions allow you to place Grub on the MBR or the root partition at install time.
Feisty Fawn
As you read this, the latest version of Ubuntu Linux, known as Feisty Fawn or version 7.04, will have been released and made available to download. As usual, it comes in three main flavours: Ubuntu with the Gnome desktop, Kubuntu with the KDE desktop and Xubuntu with the lightweight XFCE desktop.
The new version has had significant interest during development, with some popular user-friendly features added to make life easier for users and get the desktop up and running as quickly as possible.
Following on from a somewhat disappointing Edgy Eft release, Feisty looks set to make much more of an impact, with some very favourable reviews of the development milestone releases. Next month, we will look at the new release, and as we have done previously with Dapper and Edgy, any necessary configuration steps to get the most out of it.
Source : PCW.co.uk
We have previously looked at some of the booting and filesystem aspects of Linux and PCs, including partitions and image files.
This time, we’ll take a much closer look at the initial booting process and how to overcome a very common problem associated with removing Linux from a computer that’s also running Windows.
Most of the problems experienced with booting into Linux (or any PC operating system) lie with the Bios, which is an archaic piece of software dating back to the first PCs, and on which Microsoft Dos and older versions of Windows used to rely.
These days, the Bios is used largely just to initialise the hardware and start the operating system, but its limitations still have an impact on how operating systems are installed.
After switching on a PC, the Bios must find and start the operating system on the hard drive. To do that, it loads the first sector of the hard drive into memory and executes the code there. A sector is 512 bytes, and is the smallest chunk of data a hard drive handles. This first sector is commonly referred to as the Master Boot Record (MBR) and contains the boot code, together with the disk’s partition table.
MBR structure
At just half a kilobyte, a sector isn’t a huge amount of space to do anything with, especially when you compare it with a typical 200GB hard drive (around 420 million sectors). It consists of two fixed sections. The first 446 bytes are reserved for executable code and it is this that is executed directly via the Bios on startup. After that comes 64 bytes for the partition table and a final fixed two-byte code to identify the sector as a valid MBR.
We recently saw in Hands On that a standard PC can have only four primary partitions, and now it may become clearer why: with just 64 bytes available for the partition table, that leaves 8 bytes per partition – just enough to locate each one on the disk, set the filesystem type and bootable flag. Take a look at screen 1 for an example of a real MBR, viewed in a hex editor. The final two bytes (0x55 and 0xaa) mark the end of the MBR. The partition table starts at position 0x01be (marked in red in the screenshot).
The fixed structure of the MBR means that only the final 66 bytes (including the 2 byte signature) are necessary for a valid MBR and partition table, since the first 446 bytes are used only for booting. It is here that the common Dos bootloader used by Windows sits, or if Grub is installed, the first stage of the bootloader.
In the case of the former, the code performs a very simple task: it scans the partition table for any partition marked as bootable (or ‘active’ in Dos terms) and then executes that. It cannot do anything else, which is why it’s unsuitable for any kind of dual-boot configuration or for starting a Linux kernel. Grub, on the other hand, is a far more versatile piece of software, but as such it needs a lot more space than 446 bytes can afford.
The first stage of the Grub bootloader does little except to locate the next stage. Due to the awkward restrictions imposed by the Bios, a small amount of extra space is available directly after the MBR. If you look at a partition table with Linux’s fdisk and set the units to sectors, you will see that the first partition begins at sector 63. You can see this for yourself by running the following command, assuming your hard drive is /dev/hda:
$ sudo fdisk -l -u /dev/hda
We know that the first sector is used for the MBR, which leaves 62 sectors spare, or 31KB (62x512 bytes). This anomaly is because of the old ‘cylinders, heads and sectors’ method for locating a position on a hard drive. Starting at sector 63 allows the first partition to start on a cylinder boundary; Linux doesn’t worry about this, but it’s maintained for compatibility. Grub uses this extra space for its ‘stage 1.5’ code.
The next stage of Grub must be loaded from a regular filesystem on a partition. Grub can read most partition types, including the standard Linux ones and Fat. This is where the images for a graphical interface version of Grub are found, too, and where the configuration data for the menu is kept.
On a typical Linux system, this data is found in /boot, which may be on its own partition or part of the root (main) partition.
MBR problems
This multi-stage setup gives a very flexible approach to booting, but also leads to problems if you simply delete Linux from your computer in a dual-boot scenario.
If the partition with the second stage is deleted, Grub can’t load itself completely, so the boot will fail.
All your data is, of course, still present and safe on any other partitions, but there will be no way to boot the computer’s hard drive directly without rectifying the problem.
One solution is to restore the Dos MBR that Windows installs. You can do this from an installation CD or by running the fdisk /mbr command from a Windows 98 CD. This will replace the boot part of the MBR without modifying the partition table. As above, this code will simply boot the primary partition marked active.
Grub ignores this flag, allowing you to boot any partition, primary or extended, from any hard drive. There is an alternative open source install-mbr command for Linux that will install a compatible piece of code instead.
Another option is to make a backup of your MBR’s boot code before you install Grub. The easiest way to do this is from Linux, using the dd command, which we’ve seen a number of times over the past few months. Since we do not want to modify the partition table, we need only copy the first 446 bytes:
$ sudo dd if=/dev/hda of=boot.bin bs=446 count=1
You can write this back to your hard drive with the reverse options:
$ sudo dd if=boot.bin of=/dev/hda
No size options are necessary here, since you are writing the entire file to the hard drive. If you have a full backup copy of your MBR, as I have re commended you always do, you can write the first 446 bytes only using a version similar to the first command:
$ sudo dd if=mbr.bin of=/dev/hda bs=446 count=1
This issue presents itself also in the reverse case; if you install a copy of Windows after Linux, it will erase the boot code on the MBR and replace it with the Dos version, preventing you from booting into another operating system. To get around this, back up your Grub boot code before installing Windows, and then rewrite it after the installation is complete.
There are other ways to get around these problems. One method is to use a small separate partition for /boot. If you delete the main Linux partition, Grub’s files are still intact and you will still be able to boot successfully. Another option is to install Linux onto a primary partition, mark it as active and install Grub onto this partition instead of the MBR. This leaves the Dos MBR in place, which in turn boots Grub.
This is the easiest to maintain, but does require that Grub is placed onto a primary partition so that the Dos boot code can start it. Most distributions allow you to place Grub on the MBR or the root partition at install time.
Feisty Fawn
As you read this, the latest version of Ubuntu Linux, known as Feisty Fawn or version 7.04, will have been released and made available to download. As usual, it comes in three main flavours: Ubuntu with the Gnome desktop, Kubuntu with the KDE desktop and Xubuntu with the lightweight XFCE desktop.
The new version has had significant interest during development, with some popular user-friendly features added to make life easier for users and get the desktop up and running as quickly as possible.
Following on from a somewhat disappointing Edgy Eft release, Feisty looks set to make much more of an impact, with some very favourable reviews of the development milestone releases. Next month, we will look at the new release, and as we have done previously with Dapper and Edgy, any necessary configuration steps to get the most out of it.
Source : PCW.co.uk
No comments:
Post a Comment