LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware - Installation (http://www.linuxquestions.org/questions/slackware-installation-40/)
-   -   Warning: The boot sector and map file are on different disks (lilo). (http://www.linuxquestions.org/questions/slackware-installation-40/warning-the-boot-sector-and-map-file-are-on-different-disks-lilo-4175414926/)

stf92 07-04-2012 04:46 PM

Warning: The boot sector and map file are on different disks (lilo).
 
Kernel 2.6.21.5, slackware 12.0

Hi:
I got the following message when running lilo:
Code:

Warning: The boot sector and map file are on different disks.
What does /boot/map do? What is its function? I could solve the issue by using the disk with the map file for the boot sector (boot=/dev/hdx) but I prefer to know something about the mysterious file /boot/map first.

Erik_FL 07-04-2012 08:51 PM

The map file contains a few different kinds of information, so the name is slightly inaccurate. The name "map file" comes from the use of the file to store maps of all the sectors making up files that can be loaded by LILO.

A file in a file-system is often not stored as one contiguous (sequential) set of sectors. For every file that can be read by LILO, there is a list of sectors making up the file. LILO creates the list of sectors at the time that the "lilo" command is used to process the "lilo.conf" file. If the locations of a file's sectors change, then the file will no longer be loaded correctly by LILO. That is why even updating a kernel file without changing the file name requires that the "lilo" command is used to update the map.

The map file itself does not have to be contiguous. The map file is divided into sections, with the first section having a directory of boot images. Each boot image is also a section. Every sector of a section (except the last) has the address of the next sector for the section. So each section is a chain of sectors. LILO stores all these sector addresses when the "lilo" command is used to process "lilo.conf".

I do not know for certain but it is fair to assume that there are limitations on which drive can contain the map file. Another reasonable assumption is that all the sectors of any file are on the same disk drive, though different files may be on different disk drives.

The BIOS identifies disks using drive IDs. Here I am referring to disk drives and NOT partitions. For example, "/dev/sda1" and "/dev/sda2" are both on the same disk drive "/dev/sda", and the same drive ID is used to access both. Only the sector address determines the position (therefore partition) within the disk drive. The BIOS does not know anything about file-systems or partitions. A drive ID is a hexadecimal number: 0x80 for the first disk, 0x81 for the second disk, etc. Floppy drives are 0x00 and 0x01. In addition to making the maps of sectors, the "lilo" command has to convert device names into BIOS drive IDs to identify disks containing files.

The assignment of drive IDs to drives can change. That typically happens when drives are connected or disconnected, or when BIOS settings are changed. In some cases, changing the boot order in the BIOS will change the drive IDs. If the drive IDs change then LILO may not correctly load an image file or the map file. One must run the "lilo" command again to translate the device names into drive IDs again.

GRUB does not store sector maps tied to partition or file sector locations. GRUB reads the menu file when booting, not when GRUB is being installed. In order to do that GRUB software can understand file-systems and partition tables. The GRUB configuration still has to be changed if disk drive IDs change or the order of partitions is changed. If the files containing the GRUB software are moved, then it may be necessary to reinstall GRUB.

One can think of LILO as the simple approach and GRUB as the complex approach. Both have their advantages and disadvantages. LILO relies on Linux to understand partitions and file-systems, while GRUB has its own set of software for that.

Erik_FL 07-04-2012 09:52 PM

Quote:

Originally Posted by stf92 (Post 4719395)
Kernel 2.6.21.5, slackware 12.0

Hi:
I got the following message when running lilo:
Code:

Warning: The boot sector and map file are on different disks.
What does /boot/map do? What is its function? I could solve the issue by using the disk with the map file for the boot sector (boot=/dev/hdx) but I prefer to know something about the mysterious file /boot/map first.

Perhaps I can explain better why it is a bad idea to have the map file on a different disk than the boot sector. In order to boot any operating system, all the parts of LILO have to be read. You can divide LILO into three parts (probably more).
  • LILO boot sector (either the MBR of a disk or a partition's boot sector)
  • LILO boot-loader program
  • Map file (configuration, menu and sector maps)

Assuming that all three parts are on the same disk, then one must simply make that disk the default boot device for the BIOS and make sure that it has the same BIOS drive ID as it did when LILO was installed. In addition to that, whichever operating system is being booted, must be on a disk drive with the correct BIOS drive ID. If that disk is different than the LILO disk, then two disks are involved in booting the OS.

Now let's assume that some third disk is attached, with yet another operating system. The operating system on the third disk can be booted if the LILO disk and the third disk have the correct drive IDs. However, if the LILO program is on the first drive and the LILO map file is on the second drive, then all three drives are required to boot the operating system on the third disk. If any one of those disks fails, the OS cannot be booted (without some reconfiguration).

The files for a boot-loader should be on the same disk with the boot sector, and really should be in the same partition that contains the boot sector. Though it is possible to install a boot sector to the MBR, that is not how it was intended to be used. The MBR software is intended to be OS agnostic. The default software looks for the first partition in the table with the "Boot" flag set, and then loads the partition boot sector for that partition. The partition boot sector of a primary partition is supposed to contain an operating system or boot-loader software. Logical drives in the Extended partition are not supposed to contain boot-loaders (because their first sector is never loaded by the MBR software).

What is the advantage to installing a boot-loader's boot sector to the MBR? The only one that I can think of is to install a boot-loader in a Logical drive partition in the Extended partition. Other than that, why not just set the "Boot" flag for the correct partition and install the boot-loader to the partition's boot sector? In fact there is an advantage to leaving the default MBR code there. One can easily change which boot-loader starts first by setting a "Boot" flag rather than installing and removing a boot-loader.

Many boot-loader installers assume that the boot sector and files for the boot-loader will be on the first hard disk (ID 0x80). Windows versions prior to Vista assume that. It is generally best to put all the boot loaders on the first hard disk. That also implies that the drive ID of the first hard disk should not be changed (at least when booting normally).

If one is going to use removable media that takes the place of the boot device, then it makes sense for all the parts of a boot-loader for the removable media to be on the removable media. Probably the OS being booted should be there too, since about the only predictable thing is that the drive ID will be 0x80 for the removable media being booted.

stf92 07-05-2012 09:35 PM

Thank you, Erik_FL, for your kind and very illustrative reply. Reading it has been a pleasure. After doing some tests, I have been able to boot from either of the two disks, 0x80 and 0x81, save for one thing (I'll refer from now on only to 0x81). After init runs, fsck finds the file system in fault, saying either the superblock is bad or I have not an ext2 filesystem.

On the other hand, lilo itself finds trouble (of course, this is the cause of fsck complaining):
Code:

Warning: Kernel & BIOS return differing head/sector geometries
I'm giving you below the full output of lilo:
Code:

root@darkstar:~# lilo -v -v -t
LILO version 22.5.7.2 (test mode), Copyright (C) 1992-1998 Werner Almesberger
Development beyond version 21 Copyright (C) 1999-2003 John Coffman
Released 20-Aug-2003 and compiled at 19:15:26 on Aug 25 2003.

Warning: LBA32 addressing assumed
raid_setup returns offset = 00000000  ndisk = 0
 BIOS  VolumeID  Device
Reading boot sector from /dev/hda
Warning: Kernel & BIOS return differing head/sector geometries for device 0x81
    Kernel: 65535 cylinders, 16 heads, 63 sectors
      BIOS: 1023 cylinders, 255 heads, 63 sectors
pf_hard_disk_scan: ndevs=2
  0300  4DDB4591  /dev/hda
  0340  514E0FB5  /dev/hdb
device codes (user assigned pf) = 0
device codes (user assigned) = 0
device codes (BIOS assigned) = 3
device codes (canonical) = 3
mode = 0x03,  columns = 80,  rows = 25,  page = 0
Using MENU secondary loader
Calling map_insert_data
Secondary loader: 17 sectors (0x3200 dataend).
bios_boot = 0x80  bios_map = 0x80  map==boot = 0  map S/N: 4DDB4591
BIOS data check was okay on the last boot

Boot image: /boot/vmlinuz -> vmlinuz-huge-smp-2.6.21.5-smp
Setup length is 15 sectors.
Mapped 8630 sectors.
Added lina *

Boot image: /usr/local/boot/vmlinuz -> vmlinuz-ide-2.4.22
Setup length is 10 sectors.
Mapped 2398 sectors.
Added linb

 BIOS  VolumeID  Device
  80    4DDB4591    0300
  81    514E0FB5    0340
The boot sector and the map file have *NOT* been altered.
root@darkstar:~#

Both drives are correctly jumped (the jumpers on the rear of a hard disk drive). Also, BIOS has scanned both drives (BIOS setup menu). Could you give any hint about the geometries not matching?

Erik_FL 07-05-2012 11:52 PM

Quote:

Originally Posted by stf92 (Post 4720479)

Both drives are correctly jumped (the jumpers on the rear of a hard disk drive). Also, BIOS has scanned both drives (BIOS setup menu). Could you give any hint about the geometries not matching?

There are essentially two ways to address a disk: Cylinder / Head / Sector (CHS) or Logical Block Addressing (LBA). CHS addressing is the old way of doing things. Using CHS addressing there can be gaps between valid addresses, depending on the geometry. For instance, if there are only 64 sectors, then an attempt to read Clinder 1, Head 1, Sector 64 would fail. When the software reads sector 63, it has to know that the next sector is 0. LBA eliminates the problem by assigning a sequential set of numbers to sectors with no gaps. With LBA there is only a sector address from 0 to n, where n+1 is the number of sectors on the entire hard disk.

The legacy BIOS disk function (INT 13) uses CHS addressing and limits the cylinder address to 1023. Modern disk drives have a much larger number of cylinders. In order to support disks with more cylinders than 1023, the BIOS does something called "address translation". In essence it lies about the geometry of disks to address as large a disk as possible with 1023 cylinders. Most drives don't have 255 heads, and they didn't used to have 63 sectors. Another reason for "address translation" is because the number of bits allowed for a Cylinder Head and Sector are different between the BIOS and the ATA hardware. As a result, without translation, one can only use the smallest range for a Cylinder Head and Sector (1023 * 16 * 63).

Most new disks are actually accessed by the BIOS using LBA, so the BIOS translates its fake CHS addresses into LBA. The BIOS also supports newer disk read and write functions that use LBA. When the software requests transfers using LBA, the BIOS doesn't have to translate anything.

If the BIOS has been set to use CHS for accessing a hard disk, then the BIOS has to translate the LBA into a real CHS address matching the geometry of the hard disk. When software requests transfers using CHS, the BIOS translates the fake CHS addresses into a LBA internally and then translate that LBA back to the real CHS geometry of the disk. So, using CHS in software and setting the disk drive (in the BIOS) to use CHS is the slowest and most complicated situation.

At boot time, LILO can either use LBA, or the BIOS CHS geometry. LBA is preferred, since sectors are numbered sequentially (geometry is unimportant). When LILO uses CHS addressing, it stores sector addresses in that format. The correct CHS addresses have to be determined at installation time when "lilo.conf" is processed. Linux can determine the disk geometry directly from the disk drive, and it can determine the disk geometry reported by the BIOS. When those two disagree (and they often do) the BIOS CHS geometry must be used by LILO to address sectors during booting. The BIOS functions will be used to access the disk. LILO does not access the hard disk directly.

Even though Linux can read the CHS geometry from a hard disk, it is not so easy to determine if the BIOS is actually using CHS to access the disk. When the BIOS uses LBA to access the disk, the real disk geometry essentially doesn't matter. Nowadays that is usually the case.

The best solution to the disk geometry mismatch is to tell LILO to use LBA and make sure that the BIOS is set to use LBA mode when accessing the hard disk.

The traditional LBA in the BIOS supports 32 bits (it's sometimes called LBA32), however disk drives only supported a 28-bit LBA until recently. Newer hard disks support 48-bit LBA, but both the BIOS and the hardware must have 48-bit LBA capability to use it. The BIOS now supports up to a 64-bit LBA.

With very large disks CHS addressing makes a major portion of the disk inaccessible. The largest CHS address, even with BIOS translation can only access an 8.4 GB disk drive. Some older boot-loaders only use the CHS addressing mode with the BIOS, and can only boot files that are located within the first 8.4 GB of the disk (EX: Windows NT 4.0).

Hopefully that clears up the question of why the geometries don't match. LILO should not have a problem if it is using LBA. The BIOS also should have no problem if the disk drive is set to use LBA.

stf92 07-10-2012 09:13 AM

Quote:

Originally Posted by Erik_FL (Post 4720511)
Hopefully that clears up the question of why the geometries don't match. LILO should not have a problem if it is using LBA. The BIOS also should have no problem if the disk drive is set to use LBA.

Sorry for the delay. You are right. Setting both things to LBA solved the problem. Thanks a lot, Erik.


All times are GMT -5. The time now is 08:35 AM.