Re: lilo removal in squeeze (or, "please test grub2")
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!)
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?
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.
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.
grub2 basics-->
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!
Reply to: