Red Hat Bugzilla – Bug 34356
Lilo error: Hole found in map file
Last modified: 2007-04-18 12:32:30 EDT
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
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
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
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.
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 :-).
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
Closing due to inactivity. If you have further information, please reopen this bug.
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.