[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

MILO, initrd and kernel-image-2.4.18, again

Herbert Xu wrote:

>I've found your problem.  You should use this MILO command
>boot hda1:/vmlinuz initrd=/initrd.img root=/path/to/rootdev ramdisk_size=8192
>instead of 
>boot hda1:/vmlinuz initrd=hda1:/initrd.img root=/dev/rd/0 ramdisk_size=8192

Jay Estabrook wrote:

>If your MILO version is one of the recent 2.2 vintage, I think you
>need to specify the boot line as:
>    boot hda1:/vmlinuz initrd=/initrd.img root=/dev/hda1
>The first important part is that there is no device specification on
>the initrd argument. MILO only has one device open at a given time,
>and you specified it for the kernel and don't need it again. The
>initrd processing will assume the image file is on the same device
>as the kernel.
>And the "real" root you want to use is /dev/hda1 (I assume); this will
>become active as soon as everything that's needed from the initrd is
>loaded. IIRC, it's various standard scripts in the initrd that cause
>the appropriate modules to be loaded for what's going to be needed to
>handle the "real" root; in your case, the IDE drivers, in other cases,
>perhaps the EXT3 journalling support.
>> The MILO version is the one from the testing directory on the
>> servers. Just before the kernel starts, MILO coughs up some message
>> about loading the initial ramdisk, but it goes by too fast to read.
>I think it's saying it can't find it.

Andrew Cater wrote:

>I also have kernel 2.4.18 on the machine.  When I put in the option for this
>it goes through, loads initrd then dies saying can't mount root filesystem.
>aboot.conf is included as an attachment.
>HELP HELP - I'm well out of my depth here!
>I took the wording of the second aboot.conf entry with a small change
>from Herbert Xu's suggestions for MILO in an earlier message.

Thanks to Herbert and Jay for pointing out that the "initrd" boot
argument should not have a device specifier, and that the "root"
argument should be the real root device rather than the ramdisk.


I tried directing the Linux console to a serial port so that I could
see all the boot messages, which previously had gone by too fast to
read. Apparently the MILO image from "testing" does not have serial
port support compiled in (why not?), but with the Linux console going
elsewhere, the MILO output was left on the monitor.

It turns out that if you specify a nonexistent file for the "initrd"
parameter (like "hda1:/initrd" or "/foobar"), MILO neither produces an
error message nor halts the boot process, as it does when it can't
find the kernel image. Is anyone still maintaining the MILO source?
Maybe I'll submit a patch to fix this.

After I removed the drive specifier from the "initrd" argument, MILO
was able to find the image file. It then declined to load it because:

  error: initrd is too large - would overwrite kernel - aborting

or words to that effect. It then booted the kernel, which promptly
died with the usual message about being unable to mount the root
device, unsurprisingly. It seems to me that halting the boot would be
the appropriate action in this case as well; it's unlikely to succeed
if the requested initial ramdisk can't be loaded.

The initrd image generated by the kernel package is 4.4 megabytes. I
re-ran the mkinitrd script with the "-k" option, deleted a lot of
unneeded kernel modules from its working directly, and ran mkcramfs to
create a new initrd image. This was less than half the size of the
original. I tried booting with this initrd image, the original kernel,
and the corrected boot arguments, and everything worked fine. I'm
running it now. MILO does let you know when it succeeds in loading the
ramdisk image, just not when it fails -- how odd.

In summary: the initrd image generated by the current kernel-image
package is too large to be booted by MILO. I suspect that Andrew
Cater's problem, quoted above, has the same cause. This is independent
of the use of the "ramdisk_size" argument; it's a MILO limitation, not
a kernel limitation. Perhaps it could be fixed by recompiling MILO
with a different value for some preprocessor symbol.  I don't know
what the current limit actually is; a 2.1MB image works, whereas a
4.4MB image fails, so 4MB seems a reasonable guess.

One other gripe: the "loadmodules" script that mkinitrd creates for
the ramdisk on my system specifies only the "ext3" module; presumably,
the kernel infers that it needs "ide-disk" from the "root=/dev/hda1"
boot argument. My system doesn't contain any ext3 filesystems, so I'm
not sure why the script thought this was needed.

I hope all this is of some use.

Ian Bruce

To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: