Symbolic links to kernel image files and initial RAM file system image files
It's hard to believe that it's been over a year since we discussed this
topic. (See
http://lists.debian.org/debian-kernel/2010/06/msg01049.html.) Time
flies when you're having fun, I guess. ;-) Anyway, back when the boot
loader hook script policy was being formulated, shortly before the
Squeeze freeze, I brought up the subject of symbolic links to kernel
image files and initial RAM file system image files, their maintenance,
and their use by boot loader configuration files. This subject is not
really addressed in the current hook script policy for boot loaders.
Nevertheless, traditional boot loaders, such as lilo and zipl,
particularly the way their configuration files are set up by the Debian
installer, do use these symbolic links. The last time I checked, the
"do_symlinks = yes" setting in /etc/kernel-img.conf was still honored by
the maintainer scripts for official stock Debian kernel image packages;
therefore, as long as the user runs only official Debian stock kernel
image packages he can keep current by setting "do_symlinks = yes" in
/etc/kernel-img.conf (along with companion options such as link_in_boot
and relative_links).
However, the last time I checked, "do_symlinks = yes" in
/etc/kernel-img.conf is not honored by the maintainer scripts
that are packaged with a kernel image package created by current
versions of make-kpkg or "make deb-pkg". Consequently, for custom
kernel image packages at least, we have a chink in the armor for boot
loaders to get out of sync with installed kernel images. Boot loader
hook scripts are not currently required to maintain symbolic links, and
none of the boot loader hook scripts that I have looked at do so. But
neither do the hook scripts provided by these traditional boot loaders
edit the configuration file (similar to the "update-grub" command of
grub version 1) to reference the kernel image files and their initial
RAM file system image files directly, so that symbolic links are not
needed. Thus we have the situation where the boot loader is implicitly
assuming that the symbolic links are going to be maintained somehow,
someway, and, for custom kernels, no official part of the Debian system
is maintaining them.
For my own use on my own systems, I have written
hook scripts which maintain the symbolic links; and if anyone wants
them, they are available for download on my web site. But obviously
they are not part of the official Debian system. While we still have
plenty of time before the Wheezy freeze, I would like to discuss what,
if anything, should be done about this situation. I see several
alternatives:
o Require boot loader hook scripts to either edit their configuration
files or maintain the symbolic links
o Provide hook scripts in some other package (base-files?
initramfs-tools?) that maintain symbolic links
o Eliminate symbolic links entirely and require boot loader hook
scripts to edit their configuration files
o Bury our heads in the sand and ignore the problem
(Obviously I don't care for that last one or I wouldn't have started this
thread!) The second option would seem to be the quickest solution, but
the quickest solution is not always the best solution. Perhaps there
are other alternatives that I haven't thought of. What are your
thoughts?
P.S. For this initial post I have CC-ed debian-boot and debian-devel, as
there may be interested parties on that list that are not subscribed
to debian-kernel, but it is my intention that the discussion take place
on debian-kernel. So please excuse this initial cross-post.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: