Bug 34356 - Lilo error: Hole found in map file
Summary: Lilo error: Hole found in map file
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: lilo   
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Doug Ledford
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-02 15:54 UTC by Michael Gersten
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:47:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michael Gersten 2001-04-02 15:54:19 UTC
I'm getting a "Hole found in map file (alloc_pages)" from lilo. The 
README for lilo indicates that this needs to be reported. This is Lilo 
version 21.


I have a drive 255/63/526. It has three partitions.

hda1: 1 12  Ms-dos
hda2: 13 372 Linux with ReiserFS
hda3: 373 526 Linux with ext2 FS

We have the reiser as the default boot. This system will run 
headless, with the power switch as the "turn-off", so we need a self 
repairing file system.

The Ext2 system is there so that incase something does happen, a 
monitor/keyboard can be hooked up for diagnostics (it is not 
mounted under normal situations).

We have the dos system marked as bootable. Changing this does 
not affect the problem.

1. If Lilo is run with NO compact option, we get the error message 
"Hole found in map file (alloc_pages)" as soon as one of the linux 
partitions is added (or tried to).

2. If compact is specified, no error message is reported, but the 
system will not boot properly:

A: At boot up, no message is displayed.
B: At boot up, the loader prints 
LILboot: Loading linuxUncompressing Linux... OK, booting the kernel.

all on one line. Note capitalization -- Loading _l_inuxUncompressing 
_L_inux. The lowercase "l"inux is from the default boot -- changing 
this in lilo.conf does change the output.

The message file specified in lilo.conf is NOT displayed.
No pause occurs to enter a new kernel.

The only reason the root is properly found is that we used rdev to 
specify the default root on hda2. (We got kernel panics before that).

This is going out into the field today or tomorrow. We need this 


# default=linux

other = /dev/hda1
        label = dos
        table = /dev/hda




Disk /dev/hda: 255 heads, 63 sectors, 526 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1        12     96358+   6  FAT16
/dev/hda2            13       372   2891700   83  Linux
/dev/hda3           373       526   1237005   83  Linux

Command (m for help): q

Comment 1 Michael Gersten 2001-04-02 17:47:04 UTC
Additional information: Lilo has no problems if it uses the kernels/
message files on the ext2 partition, when booted on the ext2 root.

It did have a problem when the reiser partition was root, using the reisfer 

In fact, testing cross setups (booting on one, using files from the other) 
shows that the problem only occurs when the map file is on the reiser file 

This is confirmed -- the /boot/map file can be on a dos partition, or a ext2 
partition, just not a reiser partition. This gives us a work-around -- it no 
longer has to be considered high priority.

Comment 2 Michael Gersten 2001-04-02 17:59:28 UTC
The work-around was premature. 

/sbin/lilo will not complain if the map file is on dos or ext2. However, the 
bootup behavior is the same.

Putting the entire /boot directory onto the dos partition...
Yes. If all of /boot is on the dos partition, it works fine.
This gives us a usable work-around.

(Still would prefer to have it all on reiser :-).

Comment 3 Jeremy Katz 2002-06-04 06:23:42 UTC
Does this work better with newer releases?  note that we don't really support
reiserfs and its possible that tail-merging there may cause problems, so it's
really only interesting if you hvae problems on ext2 or ext3

Comment 4 Jeremy Katz 2002-06-29 21:48:37 UTC
Closing due to inactivity.  If you have further information, please reopen this bug.

Comment 5 Red Hat Bugzilla 2006-02-21 18:47:57 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.