Re: kernel-package system: install a boot block using the existing /etc/lilo.conf?

• Previous message: Kevin Mark: "Re: fetchmail error"
• In reply to: Kevin McKinley: "Re: kernel-package system: install a boot block using the existing /etc/lilo.conf?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sat, 16 Aug 2003 21:02:41 -0600
To: debian-user@lists.debian.org

Kevin McKinley wrote:
> Bob Proulx wrote:
> > installed, the symlinks pointing to it, and running lilo will set up
> > the boot to go to the new kernel.
> [...]
> When I got to the "install ... existing lilo.conf" question, if I answered
> yes rebooting the system when the script finished would boot the old kernel.
> Doing as I wrote would boot the new kernel.

Interesting. I just verified with an update of a machine from the
bf24 2.4.18-bf24 to 2.4.20-2-k7 (using the 2.4.20 kernel from
woody-proposed-updates) that this would work and it did. I wonder if
there was a bug in a previous postinstall which has been fixed?

> > I have noticed a bug in the kernel-image*.postinst script which does
> > not always get the /vmlinuz et al symlinks correct, leaving them
> > pointing to the old kernel. I tried debugging that problem but have

I can definitely recreate this problem. Time to debug it further and
get to root cause of it. Won't be able to do it this weekend,
however. But I think it might be related to your experiences.

> I don't like the symlinks thing anyway -- I would prefer to refer to a
> kernel by its full name (as grub does).

I can imagine that is all a compromise. The symlinks are relatively
easy for the postinstall to rotate through from one kernel to the
next. The current symlinks point to the latest installed kernel and
the old symlinks rotate to vmlinuz.old et al. To refer to the full
names it would mean reading, modifying, writing the lilo.conf file
each time and working around any of the local admins modifications to
that file. Using the symlinks avoids that need. Which I imagine is
why the maintainer chose the course chosen.

Also, when going to an initrd kernel lilo.conf already needs to be
edited for that purpose. The maintainer apparently did not feel
confident in the ability to read, modify, write that file while
working around local admin edits and therefore there is a manual step
there currently for the admin to do insert the initrd image config.
So there are two times where editing of the lilo.conf file was
avoided. Which leads me to assume there is some type of dragon on the
map there. Probably the working around the edits of the local admin.

> > > What you want to do is install a new boot block which refers to the new
> > > kernel you just compiled.
> >
> > Which should be the default.
>
> I agree though, that installing a new boot block referring to the new kernel
> should be the default.

Actually when I said "should" I meant "works for me". I have not seen
the case you describe yet in my set of installations. Other than the
problem where the symlinks did not actually get updated.

> I don't normally use lilo -- I use grub instead, ...

GRUB is good. But I wish the package would automatically set itself
up a little more than it does currently. Once configured it is self
sustaining. But the initial setup is manual. Simple, I know. Two
lines edited in /boot/grub/menu.lst plus four more if you are dual
booting. And three lines added to /etc/kernel-img.conf. But it would
be nicer if it just worked out of the box. I still use it. It is
just like Debian. More work to install but easier and self-sustaining
once it has been installed making it quite worthwhile.

Bob

-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

• application/pgp-signature attachment: stored

• Previous message: Kevin Mark: "Re: fetchmail error"
• In reply to: Kevin McKinley: "Re: kernel-package system: install a boot block using the existing /etc/lilo.conf?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]