Re: lilo removal in squeeze (or, "please test grub2")
On Tue, 25 May 2010 11:10:38 -0400 (EDT), Ferenc Wagner wrote:
> Stephen Powell wrote:
>> ... I installed the mbr package ...
>
> The extlinux package itself also contains an mbr.bin, which you can use
> (it's strong point is probably EBIOS support).
So it does. Well, I've now installed extlinux' version
of mbr.bin to the master boot record and purged the mbr package.
extlinux' built-in version of a master boot record boot loader works great.
>>
>> Speaking of documentation, that seems to be its main weakness.
>> Documentation is sketchy and spread out over a number of different files.
>
> /usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly
> comprehensive according to my standards, at least as far as the core is
> concerned. What did you miss? Some modules may be less well documented.
Yes, I found those two files. Reference documentation for each specific
boot loader option is there, but what is lacking is tutorial-type stuff.
For example, there is a global options section at the beginning that applies
to all bootable images, and there are options which are specific to each
boot image. I guessed at that mainly based on how /etc/lilo.conf works,
but I'm not sure it was directly stated anywhere. It may be hinted at
in the description of some individual configuration option but not explained
"up front". Also, there's no example configuration file. There are little
pieces of configuration files but no complete typical configuration file.
A "picture" is worth a thousand words.
>> It installs hook scripts that I don't want (and that have bugs).
>
> I hope we can fix them soon (they are Debian specific additions).
Remember, I'm used to using lilo. And based on analogies with lilo,
I built a /boot/extlinux/extlinux.conf file that looks like this:
-----
DEFAULT Linux
APPEND root=/dev/sda2 ro vga=779
TIMEOUT 50
PROMPT 1
LABEL Linux
KERNEL ../vmlinuz
INITRD ../initrd.img
LABEL LinuxOLD
KERNEL ../vmlinuz.old
INITRD ../initrd.img.old
-----
The kernel and initial RAM disk images are specified via the
traditional symlinks. As long as the symlinks are maintained
properly, my config file never needs updating, just like lilo's.
Consequently, I really don't want the extlinux hook scripts to
execute at all when I install or remove a kernel. I solved that
temporarily by issuing
chmod -x /etc/kernel/postinst.d/extlinux
chmod -x /etc/kernel/postrm.d/extlinux
That works for now; but if a package upgrade for extlinux is ever
downloaded, I'm afraid that new versions of the hook scripts will
be copied into these directories which are marked executable, and
my hand-made configuration file will get wiped out. I would suggest
testing the existence of some flag file. If the flag file exists,
then invoking update-extlinux should be bypassed. Thus, if the user
doesn't want his hand-made /boot/extlinux/extlinux.conf file to be
tampered with, he can create that flag file via "touch" and the hook
script will not run update-extlinux. Strictly speaking, this is
an enhancement request.
Second, it is important that any script run as a hook script not
produce any output at all to standard output. I found that out the
hard way when I was writing my own hook scripts for use with lilo.
That's because they run under debconf, which has redirected standard
output for its own purposes. Thus, anything written to standard
output is (1) never seen by the user and (2) has a good chance of
messing up debconf, which is examining the output. The invocation
of update-extlinux should have a redirection on it to redirect
output to standard error. For example,
update-extlinux >&2
This is a bona-fide bug.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: