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

Re: Detecting install vs upgrade in postinst

On Sun, 2016-06-05 at 07:39 -0700, Josh Triplett wrote:
> Ben Hutchings wrote:
> > On Sun, 2016-06-05 at 11:29 +0200, Marco d'Itri wrote:
> > > On Jun 05, Ben Hutchings <ben@decadent.org.uk> wrote:
> > > > The postinst script for linux-image-* behaves differently on fresh
> > > > installation vs upgrade.  For a fresh installation, it updates the
> > > > default symlinks /vmlinuz and /initrd.img to point to the new kernel
> > > > and initramfs versions.  On upgrade it generally doesn't.
> > > BTW, can we remove these? At least on x86 they should not be useful 
> > > anymore since lilo has bit rotten.
> > 
> > Unfortunately there are many boot loaders (and custom configurations)
> > that rely on them, not just lilo.  But they can be disabled by adding
> > 'do_symlinks = no' to /etc/kernel-img.conf.
> Which bootloaders still rely on them?  Is there a list somewhere?  It
> might be feasible to go through and fix those bootloaders.  (Not just to
> avoid needing a hardcoded kernel path, but more generally to support
> booting more than just the current kernel and possibly one previous
> kernel.)
> For that matter, could do_symlinks default to no on i386 and amd64?

Perhaps.  I'd rather not make the hardcoded default architecture-
dependent, but the default set by the installer could be changed.

> In the meantime, how feasible would it be to extract the logic from the
> linux-image postinst and put it into a helper program?

That would be silly, because the old logic was awful.  But I did write
a helper program and added it to linux-base:

commit af7c52a66d513d7d67abc803d1b36c53e4463bc4
Author: Ben Hutchings <ben@decadent.org.uk>
Date:   Mon May 30 18:41:42 2016 +0100

    Add linux-update-symlinks command for use by package maintainer scripts
    This is simpler than the current logic in the linux maintainer
    - Now that I know that hard-linking and copying to the default locations
      were broken, I only need to worry about making symlinks
    - The logic for updating on installation/upgrade and removal is kept
      together rather than divided across two scripts
    - It uses existing functions in the DebianLinux module
    But it's also smarter: it builds a list of versions and the files that
    belong to them, prioritised based on the current type of change, the
    existing symlinks and version sorting.  So it can always point the
    symlinks somewhere sensible, unless the last image is being removed.

and the linux maintainer scripts will use that in future.


Ben Hutchings
Everything should be made as simple as possible, but not simpler.
                                                           - Albert

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: