Oh bugger. I tried emailing John Coffman, the author of LILO, to get his
take on this (the previous comment), but the mail bounced.
It pretty much sums up my _suspicions_:
LILO has a heuristic to determine when the "large-memory" option is needed, but
it underestimates, leading to this edge case. We are very close to the
estimated compression ratio that LILO has.
My proposed solution:
Make LILO be more pessimistic about its estimate. This (untested) patch should
do it:
--- boot.c.orig 2008-08-30 12:44:51.000000000 +0200
+++ boot.c 2008-08-30 14:36:51.000000000 +0200
@@ -84,7 +84,7 @@
die("Can't load kernel at mis-aligned address 0x%08lx\n",hdr.start);
descr->flags |= FLAG_LOADHI; /* load kernel high */
hi_sectors = sectors - setup; /* number of sectors loaded high */
- hi_sectors *= 3; /* account for decompression */
+ hi_sectors *= 4; /* account for decompression */
if (hi_sectors < HIGH_4M) hi_sectors = HIGH_4M;
}
geo_close(&geo);
It basically makes LILO assume that the initrd has a compression ratio
of 4, therefore much sooner warning the user that "large-memory" is
required (and actually behaving as if "large-memory" was specified).
Soren: Could you test that this patch correctly gives a warning if you
run LILO (without the large-memory option)?
--
lilo needs to warn if initrd is too large
https://bugs.launchpad.net/bugs/260059
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
