Comment 10 for bug 260059

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)?