Re: lilo removal in squeeze (or, "please test grub2")
On Tue, 01 Jun 2010 05:32:37 -0400 (EDT), Stan Hoeppner wrote:
> From a seasoned sysadmin perspective, a "vendor" forced change away from
> something as critical as a bootloader, causes immediate push back. In LILO's
> current state, and given the way I run kernels, I could likely used LILO 22.8
> for the next 10 years without a problem, without any code changes. So it
> doesn't matter to me if it's currently maintained or not.
Actually, I've been tempted to volunteer to become the upstream maintainer
for lilo myself. I have worked on boot loaders before, on other platforms.
For example, I have made local modifications to the "Stand Alone Program
Loader" that ships with IBM's z/VM Operating System. The SAPL is used as the
boot loader for the CP (Control Program) component of z/VM, as well as other
stand-alone programs such as DDR (DASD Dump / Restore)
and DSF (Device Support Facilities). I won't go into the details of what
those local modifications are because they are not relevant here.
The point is that I've worked on boot loaders before, and I like working
on low-level stuff.
However, although the SAPL is written in assembly language, it is written
in s390 assembly language, which is totally different from x86 assembly
language. I don't know x86 assembly language at all. And I am just
learning C. So reason prevails over emotion and I don't volunteer. I
am simply not qualified. Someday I may be, but not today.
>
> The reason grub2 is being forced upon us all is the need of the "desktop"
> users who want a 20MB kitchen sink kernel and initrd that will support any
> piece of hardware on any machine they throw at it. Many sysadmins don't want
> or need that, and we're being forced to change our bootloader due to the
> perceived needs of others.
Actually, that is largely a myth. Lilo's only release-critical bug turned
out not to be a bug at all. It was this "bug" that gave rise to the belief
that stock kernels were getting too big for lilo to load. But the problem
was that a new kernel was installed without lilo being run. And this is
apparently the result of changes made to the stock kernel maintainer scripts
that cause "do_bootloader = yes" in /etc/kernel-img.conf to not be honored
anymore, as it once was. Whether this is a bug or a feature in the kernel
maintainer scripts I am not sure. But I am sure that this is not a lilo
bug.
To the best of my knowledge, even the largest of today's "kitchen sink"
kernel and initial RAM disk image combinations can be loaded by lilo with
no trouble at all if the large-memory option is used and the BIOS support
memory addressing above 16M, which is the case for almost all modern BIOS.
(The 16M limit is apparently a hold-over from the days of the 80286 chip.)
And if for some reason the BIOS do not support the large-memory option,
simply using MODULES=dep instead of MODULES=most in your initial RAM
file system is usually sufficient to allow lilo to work, even with these
large kernels.
(As a side note, it seems to me that the equivalent of the large-memory
option should be possible even if the BIOS do not support it by
asking the BIOS to read a block into storage below the 16M line and then
copying the block above the 16M line under program control. Conceptually
at least, it seems to me that that shouldn't be too hard. But I don't
know.)
>
> LILO isn't broken and it works well enough for may folks such as myself. We
> should have the option of keeping it, as an installable package, until _we_
> feel we need to change to something else. It's as much a philosophical issue
> as it is a practical one. There is no legitimate reason LILO can't be left in
> the distro as an optional package, just as it is now with Lenny.
>
> It's difficult to be "positive" when unnecessary change is being forced down
> one's throat.
I agree. But I also sympathize with the poor package maintainer who is
essentially functioning as both package maintainer and upstream support.
That cannot go on forever. Someone has to step up to the plate and take
over upstream support. I'd do it myself if I had the requisite skills.
But as of now, I just don't.
Perhaps one of the reasons that no-one has stepped up to the plate to take
over upstream support is the perception that lilo can't handle today's
large kernels and therefore we should just let it die. That is simply not
true. I use stock kernels most of the time. And I use lilo. And I've
never had a bit of trouble. I just have to make sure by the use of hook
scripts that lilo actually gets run when a kernel is installed or updated.
And that's easy enough to do.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: