Are there bugs in mkboot? Need another pair of eyes.

[Chris Metzler <cmetzler@speakeasy.net>]

Hi.  I posted this a week and a half ago and didn't see much response, so
I figured I'd try one more time before filing bugs on debianutils.


Hi.  mkboot (part of the debianutils package) appears to be bugged to me,
both in use and in looking at the code.  But I've looked in BTS and in
/usr/share/doc/debianutils, and have searched web, usenet, and mailing
list archives, and haven't turned up anything.  Since I'm almost always
not the first person to spot a bug, I suspect I'm just missing something.
So I'd like someone else to look at it, if they can.

There are two issues that I see; both involve the use of mkboot to create
a floppy off which one can boot.

1.  The man page for mkboot indicates that it uses the kernel /vmlinuz
by default, but that you can specify a different kernel on the command
line.  However, it doesn't say that when you supply the pathname for a
kernel to use, that pathname *can't* be the actual path to the kernel,
and that it *must* be a symbolic link instead.  But that appears to be
the way mkboot functions; if you supply a symbolic link to the kernel
you want, it works ok, while if you supply a full pathname to the actual
kernel file, it bombs.  It makes an ext2 filesystem on the floppy,
copies the kernel over, and then quits there, without doing anything
with a bootloader to make the floppy bootable.

Looking at the mkboot script, the problem appears to me to be in the
function "makelilo", and occurs just after the kernel is copied over,
in the following lines of code:

    # if a symbolic link, look for the real file
    kfile=`readlink $1`
    # see if we need an "initrd=" line in lilo.conf
    kdir=`dirname $kfile`

$1 is the command-line argument that carries the kernel path to use.
If a symbolic link is supplied, readlink returns the file that it
links to (which could itself be a symbolic link, by the way; did the
author of this script mean to use "readlink -f"?).  But if the kernel
path supplied *isn't* a symbolic link, readlink returns a null string.
In that case, the next line sees dirname not having enough arguments,
and the script bombs.

Or am I missing something?


2.  For the purposes of making a boot floppy, mkboot completely
assumes the use of lilo; if you do not have lilo around, the
script will bomb in one of two places.  This is not documented
in the man page, and the debianutils package doesn't have a
dependency on lilo.

There are functions present in the script for checking whether lilo
and/or grub are in use; but from my read of the main portion of the
script, those functions are only called in the case where mkboot is
being run as part of the new kernel installation process (that is,
with the "-i" flag), and they're only called to determine whether to
update your hard drive's MBR or whether to suggest updating grub's
menu.lst.  They're not used in the portion of the script that
involves making a boot floppy.

Instead, when making a boot floppy, the machine simply assumes the
use of lilo.  It attempts to construct a sensible lilo.conf for the
floppy, and then runs lilo on the floppy.  In my case, I don't even
have lilo installed; I use grub exclusively.  Since the attempt to
construct a sensible lilo.conf starts by reading in and parsing
/etc/lilo.conf, this fails because the file isn't present, and so
the script bombs there.  If the file *is* present but lilo itself
is not (say, you had lilo once upon a time, but replaced it with
grub; but the /etc/lilo.conf is still around), the script will instead
bomb when it tries to run lilo on the floppy.

Am I right about these?  Are these bug-report worthy?

Thanks.

-c


-- 
Chris Metzler			cmetzler@speakeasy.snip-me.net
		(remove "snip-me." to email)

"As a child I understood how to give; I have forgotten this grace since I
have become civilized." - Chief Luther Standing Bear