[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: New LILO version, was Re: Woody upgrading problems, LILO and debconf



On Fri, May 25, 2001 at 09:22:37AM -0400, Dale Scheetz wrote:
> > Well the way it effectively operates is to just ask if you want to install a 
> > boot block with the new lilo.
> 
> It isn't clear to me that I would ever want to do that on an upgrade ;-)

i tend to agree, except that /boot/boot.b is replaced as lilo packages
work now.  (though it attempts to preserve it hopefully not breaking
the existing bootloader).  /boot/boot.b is referenced by a blocklist
in the mbr or so. (im not totally sure of the internal details of
lilo). 

> > 
> > Someone made the really good suggestion of having the boot.b type files in 
> > /usr/lib/lilo (or some such directory) and have them copied in when the lilo 
> > command is run.  
> 
> Why does boot.b need to be replaced, and how does this relate to the mbr
> issues?

boot.b is the second stage bootloader, it must match the first stage
loader in the MBR (or root bootblock) the first stage also locates it
via a blocklist which will be broken whenver /boot/boot.b is
overwritten.  

with my proposal /boot/*.b is never touched by the lilo package, those
files are not even IN the lilo package.  instead they are all in
/usr/lib/lilo.  when you run /sbin/lilo it would copy the required
bootblocks from /usr/lib/lilo to /boot/ then run the actual bootblock
installer which uses /boot/*.b.  

this way when lilo is upgraded your active bootloader living in /boot
is NEVER touched in ANY way by the upgrade process, including
attemping to move the existing files to .preserved hoping that didn't
just break the installed bootblock.   it would for the first time
allow the lilo package to be upgraded with a true *zero* percent
chance of breaking the active, working bootloader.  

then there would truly be no reason to rerun lilo in the postinst,
only reason to do so is to activate the new version.  which IMO should
be up to the admin to do at thier leisure.  

and as a bonus you get rid of that ugly *.preserved crap that litters
/boot after upgrades.  

> >                 If I implement that suggestion then I will make it not run 
> > liloconfig on postinst unless there is no /etc/lilo.conf.
> > 
> 
> My /etc/lilo.conf is a symlink to /boot/lilo.conf, which is a separate
> partition used by several root filesystems. I would suggest you do the
> following in the postinst script:
> 
> if [ "$1" != "upgrade" ] ; then
>   liloconfig
> else
>   echo "<some message about running lilocnfig>"
> fi

i think this makes more sense (and would actually work ;-)) :

if [ ! -f /etc/lilo.conf ] ; then
	liloconfig
else
	echo "something about liloconfig"
fi

i presume that you always have /boot mounted so your symlink isn't
going to show up dangling during upgrades no?

> then the rest of the installation details need not be known or accounted
> for, and are left to the sysadmin.

i think my proposal would facilitate this goal further as well.  (the
admin doesn't need to worry about whether that moving of *.b ->
*.b.preserved broke things, or have to clean up that mess later).  

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgpSy48tqqybK.pgp
Description: PGP signature


Reply to: