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 : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1702198171.779349.1311119811090.javamail.r...@md01.wow.synacor.com
