Re: Symbolic links to kernel image files and initial RAM file system image files

[Stephen Powell <zlinuxman@wowway.com>]

On Wed, 20 Jul 2011 09:25:37 -0400 (EDT), Ben Hutchings wrote:
> On Wed, 2011-07-20 at 07:39 -0400 (EDT), Stephen Powell wrote:
>> On Wed, 20 Jul 2011 04:52:59 -0400 (EDT), Ben Hutchings wrote:
>>>
>>> Hook scripts will just perpetuate the use of the undocumented
>>> /etc/kernel-img.conf.
>>
>> Hmm.  I don't follow that logic.  If symbolic links are maintained
>> in hook scripts, then it makes sense to me that the user would set
>> "do_symlinks = no" in /etc/kernel-img.conf to avoid duplication
>> of effort.
>
> If the hook scripts are in some common package then they would need to
> be configured somehow.

I must not understand something.  What's to configure?  Just drop them
into /etc/kernel/postinst.d and /etc/kernel/postrm.d, respectively,
and you're done.  /etc/kernel-img.conf doesn't need to be touched.
You can put something into linux-base, if you want to, that issues
a warning if it finds "do_symlinks = yes" set in /etc/kernel-img.conf,
as you did in Squeeze for "do_bootloader = yes", but you would do that
anyway, I presume, regardless of the solution implemented.
The hook scripts that I have written are boot-loader-independent,
and I presume that any hook scripts that maintain symbolic links
that end up in production will be as well.

>>> I would like to see these 'traditional' boot loaders provide the option
>>> to update their configuration automatically.  This should be done with
>>> the aid of the new 'linux-version' command from linux-base.
>>
>> That's a nice idea, but there are implementation problems
>> that come to mind.  I don't know about zipl, I'll check; but I do know that
>> lilo, for example, is limited to 15-character names in its labels.
>> The traditional labels, used with the symbolic links, are something like
>> "Linux" and "LinuxOLD", which are well within the 15-character limit.
>> But if one attempts to auto-generate labels based on the name of the
>> kernel, I can easily see a problem with guaranteeing uniqueness while
>> still remaining within the 15-character limit.
>
> The version list could then be truncated, e.g.:
>
>     #!/bin/bash
>
>     generate_entry() {
>         ...
>     }
>
>     { read new_version; read old_version; } << (linux-version list | linux-version sort --reverse)
>     [ -z "new_version" ] || generate_entry Linux "$new_version"
>     [ -z "old_version" ] || generate_entry LinuxOLD "$old_version"
>
> ...
> I'm not convinced it's that complicated.
 
Oh, I get it now.  Keep the label names the same as before, but change
the image and initrd values to point directly to file names instead
of symbolic link names.  Yes, that would work.  I was thinking of
trying to incorporate the kernel name into the label.  Something like
"2.6.39-2custom1-686-pae" is too long.
 
But that still leaves each boot loader maintainer with the task of
coming up with his own script to automatically generate his boot
loader's configuration file with each kernel installed or removed,
allowing for invariant sections too, of course.  This would be the
equivalent of the "update-grub" command of grub-legacy, except that
something like it would have to be created for each boot loader.
That is more work and it does involve duplication of effort, but it
can probably be done that way.
 
I'm OK with it either way, but I am not a package maintainer for
any boot loader.  I would really like to get some participation in
this thread by boot loader maintainers.  They are more of a stake
holder than I am.  My interest is simply to see custom kernels
generated by make-kpkg or "make deb-pkg" work properly in the
Debian environment without users having to write their own hook
scripts to maintain the symbolic links.  But since I've already
done that for my own purposes, I have little work to do in the
future, regardless of the implementation chosen.  That is not the
case for the boot loader maintainers.

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