lilo loads wrong data for big initramfs (?)

Roland wrote:
> I tried installing yaird and build a smaller initramfs [...] and now I am able to boot

Thank you, I am now able to boot too. Has anyone tried to use the

Some details for those using this on a -server kernel: my `uname -r` returns a -generic suffix; you'll have to symlink /boot/config-*-server and /lib/modules/*-server. The error message was less than obvious: "unknown kernel version".

This is but an ugly workaround. I wonder if lilo's option to load the initrd into high-memory would suffice.

Luis wrote:
> I wonder if lilo's option to load the initrd into high-memory would suffice.

I wondered correctly. I've added
large-memory
to /etc/lilo.conf and I can now boot. Now, a difficult ltsp chroot awaits me...

BTW, I vote this bug to "blocker". LILO is required for those who are putting /boot on LVM (which in my case sits atop a RAID1 volume, but that looks unimportant).

Thanks for the 'large-memory' option tip. It makes sense that there would be problems without that, since without the option it seems lilo tries to load everything under 15 MB, and with an 8+ MB initramfs and a nearly 2 MB kernel, it seems plausible that something could go wrong.

I agree that this is a serious bug -- it almost rendered my system unbootable after an upgrade to Hardy, and if I hadn't had the Gutsy kernel still around, my system would have been a real pain to recover.

Thanks lbruno,
I'm also running a /boot on lvm on raid1 config with lilo, and got the
    checking if image is initramfs...it isn't (bad gzip magic numbers); looks like an initrd
error after the upgrade from gutsy to hardy.
"large-memory" in lilo.conf fixed it. Thanks again.

it's good to know I'm not the only one with this problem! I've been trying to mount the raid volume on a hardy livecd, at first just to try and recover everything, but it seems like it can be fixed with the "large-memory" option ... however I haven't been able to mount the raid volume to do so ... could it be because I'm using 64-bit hardy? any suggestions?

Dbenitez escreveu:
> seems like it can be fixed with the "large-memory" option ...
> however I haven't been able to mount the raid volume to do so
>
Switch to another VT when you get the red background and a quick fsck
/dev/md0 might do the trick.

Well the solution I used is mounting the array in a livecd, adding "large-memory" to lilo.conf, chrooting into the filesystem and running liloconfig ... so I suggest doing that ...

also, is this issue going to be fixed in LILO in future versions?

Dbenitez wrote:
> is this issue going to be fixed in LILO in future versions?
>
Maybe this bug should be CC: to the installer team. Actually, they're
the ones who should be writing out "large-memory" in this case.

I've subscribed the ubuntu-installer team on this.

LILO can't boot the bigger kernel in Hardy without the "large-memory" option. Needed when /boot is on LVM.

I declined the Intrepid nomination because there's generally no need to nominate bugs for the current development release; it's implicit. That doesn't mean it shouldn't be fixed in Intrepid.

The debian buglog mentions that LILO can't boot over 8MB of initramfs on
some systems, depending on BIOS. Their solution is "MODULES=dep". Since
update-initramfs is running at the end of the installation, seems doable.

  affects ubuntu/lilo

I came across this problem too, but it first affected my kernel and caused the system to panic at boot. I only got to this page to figure out the solution after I used a rescue mode boot to install the amd64 "server" kernel.

you have to get into ubuntu in recovery mode

there you can recolve all problens in your sistem

The closure of this bug by "jscc88" was wholly inappropriate; recovery mode is *not* an answer to a system being unbootable by default after installation!

However, it happens that this bug has been fixed in Jaunty courtesy of work in Debian. Here's the changelog entry:

lilo (1:22.8-6.1) unstable; urgency=low

  * Non-maintainer upload.
  * Add some information about large initrd boot problems:
    - Document the issue and workarounds in README.Debian
    - Alert users to the issue in NEWS.Debian
    - Prompt users to add large-memory to /etc/lilo.conf
    - Thanks to debian-l10n-english for the review!
    (Closes: #479607)
  * Include French debconf translation update by Christian Perrier

 -- Paul Wise <email address hidden> Sat, 25 Oct 2008 21:25:18 +0800

Incidentally, I've tested this successfully using today's daily server CD, after applying fixes for bug 309555 (which will be fixed in tomorrow's daily server CD.

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".