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

Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process

On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote:
> ...
> I can put a one-time warning into linux-base.  But the default for
> squeeze must be 'no'.  It should not be necessary to create
> /etc/kernel-img.conf at all in squeeze.

Sorry I didn't think of this the first time, but there are up to
four steps to preparing a kernel for booting:

(1) Installation of the kernel itself
(2) Creation of an initial RAM file system
(3) Updating symbolic links
(4) Running the boot loader installer

Not all steps are required in all cases, depending on the circumstances.
Neither grub version 1 nor grub version 2 generally use symbolic links;
so that hasn't been on the forefront of most people's minds.
Strictly speaking, the historic boot loaders such as lilo
and zipl don't *have* to use symbolic links, but as they
have historically been used in Debian systems, they generally do.

Obviously, item 1 takes care of itself.  For stock kernels,
item 2 also takes care of itself.  And it appears that the
latest version of initramfs-tools provides hook scripts
of the same name in /etc/kernel/postinst.d and
/etc/kernel/postrm.d which take care of item 2 for kernel
image packages created by make-kpkg and make deb-pkg as well.
(Actually, that item does need some work, but I'll come
back to that later.  For now, let's assume that item 2
is taken care of.)  Item 4 is what we've been talking about.
Each boot loader that needs some kind of update will have
to provide a hook script starting with "zz-".

Now the question is, what should we do about item 3, maintaining
the symlinks?  For stock kernels, that has historically been
handled by variables in /etc/kernel-img.conf: do_symlinks,
relative_links, and link_in_boot, mainly, though there are
other seldom-used variations.  But you just said that the goal
was to be able to eliminate /etc/kernel-img.conf.  So what
do we do about symlinks?  Fortunately, the "update-initramfs -u"
issue doesn't affect the symlinks.  The symlinks only need to be
maintained, if at all, when a kernel is installed, updated,
or removed.  The symlinks are not, strictly speaking, associated
with a package.  Should the boot loader script take care of
it?  Or should this be a separate script?  What do you think?

I said I would come back to initramfs-tools; so now I'm back.
There are two issues with the script as written today.
(1) it does not redirect standard output to standard error
when invoking update-initramfs.  Thus, the user sees no
output (since debconf swallows it) and, depending on the output,
it may cause problems for debconf.  (2) it unconditionally
creates an initial RAM file system for kernel image packages
created by make-kpkg, even if the user doesn't want one.
There is a way to check to see if one is needed.  I can
submit a revised version of the script if you like.  Would
you like me to do so?

  .''`.     Stephen Powell    
 : :'  :
 `. `'`

Reply to: