Re: lilo removal in squeeze (or, "please test grub2")

[Andreas Barth <aba@not.so.argh.org>]

* Stephen Powell (zlinuxman@wowway.com) [100523 21:21]:
> On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote:
> > After some discussion about lilo on #debian-devel in IRC, it has pretty
> > much been determined that kernel sizes have crossed the line past where
> > lilo can reliably determine the payload size.

We're speaking about #505609 I assume?


I'm not sure this bug requires an removal of lilo (see below), however
I think this means we should strongly discourage usage of lilo.


> > (1) The release notes need to be updated to reflect that lilo is no
> > longer a bootloader option;

The release notes should be updated in case we keep lilo that we
recommend to move to another boot loader now.


> > (2) The debian-installer team needs to remove the lilo-installer udeb;

This should indeed happen - if someone activly requires lilo, then
doing it by hand should be ok-ish.



> I am not a Debian package maintainer or a Debian developer.  I am just an
> ordinary system administrator.  So I'm sure that my opinion will not count
> for much.  But I am opposed to the removal of lilo.  Both grub-legacy and
> grub-pc use sectors on the hard disk outside of the master boot record
> (cylinder 0, head 0, sector 1).  In other words they use cylinder 0, head 0,
> sector 2 and possibly subsequent sectors on cylinder 0 head 0.  This breaks
> the design of the backup software that my employer uses.  This backup software
> backs up the master boot record and all partitions; but since the extra
> sectors used by grub-legacy and grub-pc are outside the master boot record
> and are not part of any partition, they don't get backed up.  Consequently,
> if we have a hard drive failure and restore from a backup, we have an
> unbootable machine.  Lilo uses only the master boot record.  A lilo-booted
> machine can be backed up and restored with our existing backup software
> just fine.  Given these requirements, I wouldn't use grub-pc even if it
> were bug free and well documented.  (But neither is the case!)

Would it be possible to move (perhaps optionally) the extra grub sectors
into an (perhaps dummy) partition (this question is for the
grub2-people)? Would that be ok for you?


> As for the claims that kernels are too big now, I find that hard to
> believe, especially now that we have the large-memory option available.
> The standard stock Debian kernel image file that I use for Squeeze,
> vmlinuz-2.6.32-3-686, is currently 2234080 bytes.  Are you trying to tell
> me that there's no room for a 2M kernel below the start of the EBDA?
> 
> I am able to load *both* the kernel *and* the initial RAM filesystem
> below the EBDA (i.e. the large-memory option is not used) if I use
> MODULES=dep instead of MODULES=most in the initial RAM filesystem
> under Lenny.  I'll bet I can do it with Squeeze too.

This sounds like we should add an wrapper around lilo that warns that
lilo is deprecated and warns if the images are too large.



Andi