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

[Stan Hoeppner <stan@hardwarefreak.com>]

Tom H put forth on 5/31/2010 1:04 AM:
> On Sat, May 29, 2010 at 11:46 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>> Tom H put forth on 5/28/2010 10:55 PM:
>>> On Fri, May 28, 2010 at 9:50 PM, Stan Hoeppner <stan@hardwarefreak.com> wrote:
>>>> Roger Leigh put forth on 5/28/2010 11:39 AM:
>>>
>>>>> For the most part, grub is a vast
>>>>> improvement over LILO, and except for the odd corner cases which
>>>>> grub doesn't cover,
>>>>
>>>> In what way is it a vast improvement over LILO? I've never had a problem with
>>>> LILO. It's always "just worked", which is what a bootloader should do. So
>>>> how exactly would grub be a better choice for me?
>>>
>>> The reverse argument can be made too. Both grub1 and grub2 just work.
>>> Unless you are continually installing dual- and triple-boot this or
>>> that, you are not going to be changing you config continually no
>>> matter what bootloader you use and you will therefore not be
>>> interacting with it that much. So, except for Stephen P's case, what's
>>> the big deal?
>>
>> I frequently roll new kernels from kernel.org source using the Debian
>> installation method, once every couple of months. I'm very comfortable with
>> using LILO for this. I've pretty much zero experience with Grub (any
>> version). If something goes wrong converting from LILO to Grub2, I'm screwed.
>>  And I'll probably have an unwanted and unneeded learning curve while
>> continuing my current practice of rolling kernels frequently.
>>
>> Please don't debate the merits of customs kernels. I have very valid reasons
>> for doing so. Let's focus on why or why not Grub2 will work for my needs, and
>> not hose my systems either during the migration from LILO to Grub2, or
>> installing custom kernels after the fact.
> 
> I have absolutely no problem with custom kernels. (What I don't
> understand is people who jump up and down on various lists when
> someone says that he/she compiles custom kernels!)

The reasons are very unflattering to the folks you point out, so I won't go
into detail and start a fire.

> I haven't used lilo for nine-ten years but I don't see how adding a
> custom kernel to grub rather than lilo should affect your kernel
> compilation. I don't use the Debian tools so after "make install", I
> run "update-initramfs ..." and "update-grub", and I'm done. I don't
> see how, if I were using lilo, I would have to follow a different
> procedure, except for setting editing lilo.conf and running lilo after
> update-initramfs. Am I missing something?

The part about that fact that I've never used grub, any of its variants.  It
may not present problems when installing my kernels.  I don't know.  That's
why I brought it up, hoping folks would share their experience.

> As I said in my previous post, I would install Squeeze's grub2 on a
> Lenny box and reboot to check that it is working before the upgrade to
> Squeeze.

Yep.

> I have gone through various big changes in OSs, WinNT to Win2k, OS9 to
> OSX (although I was a Sol-Lin admin too so it wasn't as great a shock
> as for Mac-only admins [1. see OT anecdote below]), Sol8 to Sol10 and
> they created more dislocation than a bootloader change. At the risk of
> sounding like a late-night infomercial (!), a smooth transition from
> lilo to grub2 is just a question of being positive (the un-unwanted
> and un-unneeded of above) - and putting in some work (the learning
> curve of above) of course.

>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.

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.

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.

> grub2 basics-->

Thanks for the tips below.  I'll be hanging onto them until/if they're needed.

-- Stan



> Setup
> 
> Although grub2 sources a file in /usr/lib/grub when creating its
> config, the files that matter are /etc/default/grub and /etc/grub.d/*.
> You set various variables like the kernel options, the default entry,
> whether to create entries with "single" appended, ... in
> /etc/default/grub. When you run update-grub (which is a script that
> runs "grub-mkconfig -o /boot/grub/grub.cfg"), the grub2 menu's
> configuration, /boot/grub/grub.cfg, is built by running the scripts in
> /etc/grub.d/.
> 
> I don't really like what the /etc/grub.d/ scripts do, so I "chmod 644"
> them except for the last one, 40_custom, and I write my grub.cfg
> there. It is a script of the form:
> cat << EOF
> my grub2 config
> EOF
> so my /boot/grub/grub.cfg ends up exactly like 40_custom except for
> the first two lines and the last one.
> 
> The disadvantage of using this method is that I have to add and remove
> kernels manually to 40_custom, whereas the standard way is that the
> 00_header, 10_linux, and 30_os-prober scripts populate the grub2 menu
> automagically. The initial run of update-grub, after you install
> grub2, will give you a good base to create 40_custom if that is the
> way that you want to go.
> 
> Unsurprisingly, since all that a bootloader does is point to and loads
> an initrd and kernel, /boot/grub/grub.cfg basically looks like
> lilo.conf (for a reference lilo config file, I am looking at Stephen
> P's kernel compilation page, which, btw, is included in the
> documentation of kernel-package) with a different syntax.
> 
> There are "global options" (default entry, grub root partition,
> console or gfxterm, timeout, ...) and "per-image options" where
> menuentry corresponds to label, linux to image, and initrd to initrd.
> 
> As an added twist, grub2 is modular so both (possibly redundantly but
> I have never tested this) the global and per-image sections have
> "insmod" invocations for filesystems, raid, lvm, framebuffer, ...
> 
> Recovery
> 
> You only have to net-boot or cd-boot a grub2 install to correct it if
> its first stage loader in the MBR is dead. If you net-boot or cd-boot
> to re-write to the MBR, you have to mount and chroot your install and
> run grub-install to re-populate the grub directories from
> /usr/lib/grub/i386-pc/ and to re-create grub2's loaders, boot.img and
> core.img.
> 
> If grub2's boot.img in the MBR is OK but the next stage, core.img
> isn't, you're dumped to a "grub rescue" prompt from which you have to
> identify and set the grub root partition, "insmod
> /boot/grub/normal.mod" to go the the normal grub prompt, load the
> kernel and initrd, and boot. (I've been meaning to overwrite core.img
> with zeroes and reboot to go through the motions but haven't done so
> yet).
> 
> If grub2's grub.cfg is missing or incorrect, you are dumped to a grub
> prompt from which you have to load the kernel and initrd and boot, by
> passing the same commands as a menuentry stanza does (with tab
> completion).
> 
> 1. I was on a night shift with a Mac admin who was teaching himself
> OSX when v10.2 or v10.3 was first out. He asked me for help because
> his box had rebooted unexpectedly. He had run a command that he'd
> found on the net. The command? "rc.boot", OSX's BSD rc script! That is
> a real learning curve!
> 
>