Activity log for bug #260059

Date Who What changed Old value New value Message
2008-08-21 13:27:15 Soren Hansen bug added bug
2008-08-21 14:13:07 Soren Hansen bug added attachment 'bootfail.png' (Screenshot of the boot failure)
2008-08-21 14:28:51 Soren Hansen description I just spent the better part of a day trying to find out why one of my servers refused to boot any kernels newer than 2.6.24-17-server. After countless hours of debugging, it turns out that the size of my initrd.img's had grown ever so slightly, but it was just enough to push it over a critical threshold that made lilo fail to get in rather mysterious ways. I'll attach a screenshot of the boot failure do demonstrate how non-obvious the cause is. These are the relevant sizes: -rw-r--r-- 1 root root 8216636 2008-05-13 13:10 /boot/initrd.img-2.6.24-17-server -rw-r--r-- 1 root root 8255405 2008-08-20 14:56 /boot/initrd.img-2.6.24-19-server The former boots just fine, the latter.. not so much. So the limit is somewhere in between those two. The system has both -updates and -security enabled, but even with just -security, it's quite conceivable that someone might pass the threshold, and suddenly find themselves with systems that fail to boot. The fix is simple: Add the "large-memory" option in lilo.conf and rerun lilo. I propose that we put large-memory in the default lilo.conf from now on, and add a check to lilo that will tell the user that their initrd.img is over a certain size and that they might want to add the "large-memory" option to lilo.conf. This *definitely* needs to into an SRU, IMNSHO. affects ubuntu/lilo importance critical I just spent the better part of a day trying to find out why one of my servers refused to boot any kernels newer than 2.6.24-17-server. After countless hours of debugging, it turns out that the size of my initrd.img's had grown ever so slightly, but it was just enough to push it over a critical threshold that made lilo fail to boot in rather mysterious ways. I've attached a screenshot of the boot failure do demonstrate how non-obvious the cause is. These are the relevant sizes: -rw-r--r-- 1 root root 8216636 2008-05-13 13:10 /boot/initrd.img-2.6.24-17-server -rw-r--r-- 1 root root 8255405 2008-08-20 14:56 /boot/initrd.img-2.6.24-19-server The former boots just fine, the latter.. not so much. So the limit is somewhere in between those two. The system has both -updates and -security enabled, but even with just -security, it's quite conceivable that someone might pass the threshold, and suddenly find themselves with systems that fail to boot. The fix is simple: Add the "large-memory" option in lilo.conf and rerun lilo. I propose that we put large-memory in the default lilo.conf from now on, and add a check to lilo that will tell the user that their initrd.img is over a certain size and that they might want to add the "large-memory" option to lilo.conf. This *definitely* needs to go into an SRU, IMNSHO.
2008-08-23 08:16:07 Soren Hansen bug added attachment 'lilo.conf' (lilo.conf)
2008-08-23 08:16:22 Soren Hansen bug added attachment 'lilo.log' (lilo.log)
2008-12-09 18:19:45 jscc88 lilo: status New Confirmed
2008-12-09 18:19:45 jscc88 lilo: assignee sebastiancobaleda
2008-12-09 18:19:45 jscc88 lilo: statusexplanation
2008-12-09 18:37:02 jscc88 lilo: status Confirmed Fix Released
2008-12-09 18:37:02 jscc88 lilo: statusexplanation I just spent the better part of a day trying to find out why one of my servers refused to boot any kernels newer than 2.6.24-17-server. After countless hours of debugging, it turns out that the size of my initrd.img's had grown ever so slightly, but it was just enough to push it over a critical threshold that made lilo fail to boot in rather mysterious ways. I've attached a screenshot of the boot failure do demonstrate how non-obvious the cause is. These are the relevant sizes: -rw-r--r-- 1 root root 8216636 2008-05-13 13:10 /boot/initrd.img-2.6.24-17-server -rw-r--r-- 1 root root 8255405 2008-08-20 14:56 /boot/initrd.img-2.6.24-19-server The former boots just fine, the latter.. not so much. So the limit is somewhere in between those two. The system has both -updates and -security enabled, but even with just -security, it's quite conceivable that someone might pass the threshold, and suddenly find themselves with systems that fail to boot. The fix is simple: Add the "large-memory" option in lilo.conf and rerun lilo. I propose that we put large-memory in the default lilo.conf from now on, and add a check to lilo that will tell the user that their initrd.img is over a certain size and that they might want to add the "large-memory" option to lilo.conf. This *definitely* needs to go into an SRU, IMNSHO. this is really, but is not a ubuntu bug. this is a kernel problem.
2008-12-22 15:58:49 Julian Alarcon lilo: status Fix Released New
2008-12-22 15:58:49 Julian Alarcon lilo: assignee sebastiancobaleda
2008-12-22 15:58:49 Julian Alarcon lilo: statusexplanation I just spent the better part of a day trying to find out why one of my servers refused to boot any kernels newer than 2.6.24-17-server. After countless hours of debugging, it turns out that the size of my initrd.img's had grown ever so slightly, but it was just enough to push it over a critical threshold that made lilo fail to boot in rather mysterious ways. I've attached a screenshot of the boot failure do demonstrate how non-obvious the cause is. These are the relevant sizes: -rw-r--r-- 1 root root 8216636 2008-05-13 13:10 /boot/initrd.img-2.6.24-17-server -rw-r--r-- 1 root root 8255405 2008-08-20 14:56 /boot/initrd.img-2.6.24-19-server The former boots just fine, the latter.. not so much. So the limit is somewhere in between those two. The system has both -updates and -security enabled, but even with just -security, it's quite conceivable that someone might pass the threshold, and suddenly find themselves with systems that fail to boot. The fix is simple: Add the "large-memory" option in lilo.conf and rerun lilo. I propose that we put large-memory in the default lilo.conf from now on, and add a check to lilo that will tell the user that their initrd.img is over a certain size and that they might want to add the "large-memory" option to lilo.conf. This *definitely* needs to go into an SRU, IMNSHO. this is really, but is not a ubuntu bug. this is a kernel problem. The user Juan Sebastian Cobaleda Cano is a troll, or something. We, in the Ubuntu-Co Team are checking all his changes in Launchpad. Sorry for the problems.
2009-03-02 02:55:15 Soren Hansen lilo: status New Confirmed
2009-03-02 02:55:15 Soren Hansen lilo: statusexplanation The user Juan Sebastian Cobaleda Cano is a troll, or something. We, in the Ubuntu-Co Team are checking all his changes in Launchpad. Sorry for the problems.
2009-03-09 20:46:03 Brian Murray lilo: status Confirmed Triaged
2009-03-09 20:46:03 Brian Murray lilo: statusexplanation Soren - it seems that there is a proposed fix in this bug report could you possibly test it out?
2009-11-06 07:40:42 Rob Frerejean removed subscriber Rob Frerejean
2010-02-06 04:29:12 r12056 nominated for series Ubuntu Karmic
2010-02-06 04:29:12 r12056 nominated for series Ubuntu Lucid
2010-07-11 07:22:27 Joachim Wiedorn bug added subscriber Joachim Wiedorn
2011-02-15 10:01:06 Launchpad Janitor branch linked lp:debian/lilo
2011-05-02 03:20:08 John Brondum removed subscriber John Brondum
2011-05-20 11:30:22 Launchpad Janitor lilo (Ubuntu): status Triaged Fix Released