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

From: Kevin McKinley (ronin2_at_bellatlantic.net)
Date: 08/16/03

  • Next message: David Fokkema: "Re: Hardware" 
    Date: Sat, 16 Aug 2003 10:38:34 -0400
To: debian-user@lists.debian.org

    On Wed, 13 Aug 2003 19:36:17 -0600
    bob@proulx.com (Bob Proulx) wrote:

    > > A longer answer is that writing a new boot block with the existing
    > > lilo.conf would simply re-write the current boot sector, which would
    > > boot the old kernel.
    >
    > Are we talking about the same question? At the point that the
    > question is asked if lilo should be run the new kernel is already
    > installed, the symlinks pointing to it, and running lilo will set up
    > the boot to go to the new kernel.
    >
    > I guess it all depends on what is in your existing lilo.conf file.
    > But if you are just doing the normal default Debian installed lilo.conf
    > file it should be fine.

    I don't normally use lilo -- I use grub instead, so before I released my
    revision to the newbiedoc I installed the Woody base system on my trusty
    Toshiba and used that installation to test my procedures.

    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.

     
    > 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
    > not closed to root cause yet so I have not reported it yet. I think
    > perhaps it failed to update your symlinks when you had the failure.
    > In that case you do need to correct the symlinks and run lilo again.
    > I only see this when I am going forward and backward while hacking a
    > new kernel. It normally works when just moving forward.
    >
    > > 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 don't like the symlinks thing anyway -- I would prefer to refer to a
    kernel by its full name (as grub does).

    I agree though, that installing a new boot block referring to the new kernel
    should be the default.
     
    > P.S. Let me second the review that your 'newbiedoc' is excellent.

    Thank you. If you can see ways to make it better please let me know.

    Kevin 

    -- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: David Fokkema: "Re: Hardware"

    Relevant Pages

    • Re: install woes
      ... looking at the Fedora 9 64bit DVD: ... I'd try the acpi=off, but I didn't need any boot options, as far as I remember ... appended the kernel, probably post-install. ... but on attempting to install, it freezes up at the test media screen. ...
      (Fedora)
    • Problems with Sarge on OldWorld 604e PowerMac: booting, quik, 2.6 kernel, etc.
      ... I'd like to use quik to boot this OldWorld 7300 PowerMac directly ... The problems arise when I want to install a 2.6 kernel. ...
      (Debian-User)
    • Re: No keyboard at boot in Debian
      ... I was recently toying with my ATI drivers and a new kernel. ... I moved udev ... Try booting the good install and running fsck on the other / partition. ... This boot issue seems to affect previous kernels as well. ...
      (comp.os.linux.misc)
    • Re: Linux Router & Fwall - old bios - wont mount root
      ... Both boot and swap are well within the first ... Once GRUB has loaded the kernel, ... With 9.3, you should be able to do about a 500MB install, ... which seems to indicate that you have a problem with the disk. ...
      (alt.os.linux.suse)
    • No keyboard at boot in Debian
      ... I was recently toying with my ATI drivers and a new kernel. ... I moved udev ... Is there anyway to salvage this install? ... This boot issue seems to affect previous kernels as well. ...
      (comp.os.linux.misc)