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
Attachment:
pgpVYYadKmyZl.pgp
Description: PGP signature