On Thu, 26 Aug 2010 18:48:57 -0400 (EDT), Ben Hutchings wrote: > On Thu, 2010-08-26 at 15:04 -0400, Stephen Powell wrote: >> Ben, >> >> I could use your help on bug number 594127. Am I not understanding >> the policy? Please read the bug log and advise. Thanks. > > Assuming that s390 kernels normally use an initramfs to boot, I think > you're right about the lack of an initramfs hook.
Thanks for your reply. Well, all the stock kernels do, of course. And, while it is possible to create a custom kernel that doesn't use an initramfs, every custom kernel that I've ever created uses one too. > > As for maintaining symlinks, that is not described by the policy at all, > though it should be. Strictly speaking, that is true. Symlinks are not explicitly mentioned. But what is the purpose of the boot loader hook scripts? Is it not to bring the boot loader in sync with the just-installed (or just-removed) kernel? Suppose two kernels are installed: A and B. B is the newer kernel, so vmlinuz points to it. vmlinuz.old points to A. (The same applies to the initramfs symlinks, of course.) And let's say that the boot loader config file (/etc/zipl.conf in this case) uses symlinks, which it historically does as set up by the Debian installer. Now suppose that a new kernel, C, is installed. The hook script will be invoked, and the map installer will be run, but it will accomplish nothing. vmlinuz still points to B and vmlinuz.old still points to A. Kernel C, just installed, is not bootable, even though the boot loader's map installer has just been run. On the other hand, suppose that instead of installing a new kernel C we de-install kernel B. vmlinuz is now a broken link, and when the postrm hook script invokes the boot loader, it will fail. For a boot loader of this type either the hook script must maintain the symlinks before invoking the boot loader, or it must maintain the boot loader configuration file (/etc/zipl.conf, /etc/lilo.conf, etc.) to point to the appropriate kernels directly, without using symlinks. If it doesn't do one of those two things before invoking the boot loader, then invoking the boot loader does not accomplish the intended purpose of the hook script. FOR OFFICIAL DEBIAN STOCK KERNELS ONLY, the symlinks can still be maintained by means of "do_symlinks = yes" in /etc/kernel-img.conf. But kernel image packages created by the Squeeze version of make-kpkg (package kernel-package) or kernel image packages created by "make deb-pkg" do not have any other means of maintaining the symlinks. If the boot loader hook scripts do not maintain the symlinks, they won't get maintained, and the whole purpose of having a boot loader hook script will be defeated. > > We could perhaps put hook scripts for that in > linux-base. It theory, I suppose symlinks could be maintained in a separate hook script. But now we're getting into the whole execution order issue again. Such a hook script must execute *after* the initramfs hook script which creates or deletes the initial RAM file system, but *before* the boot loader hook script executes. So what are we going to call it? zy-symlinks? Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. But we have to solve this problem some way. The template hook scripts which I provided at the beginning of the bug log do what needs to be done. They need to be tweaked a little to make them specific to a single boot loader, but the symlink logic is there. If you don't like my symlink logic, then you can write your own. I don't care what color the cat is as long as it catches mice. As to the severity, I set it to "serious" because your original bug report, 590028, was set to "serious", and the "fix" did not solve the problem (at least not in the general case). Another reason that I set it to serious is that, as I understand the policy, the package is not currently policy compliant. Bastian obviously disagrees with me, but unlike me he has offered no justification or rationale as to why the severity should be "important". Since both of you are on the kernel team, I will let you two duke it out as to what the severity should be. Normally, I wouldn't care all that much as to whether the severity should be serious or important. But in this case it makes a difference as to whether the bug is fixed in Squeeze or in Squeeze+1. And if it's not fixed in Squeeze, you're going to have to keep the boot-loader-specific logic in initramfs-tools for yet one more release. I'm trying to help you out here. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2127039792.409627.1282917047662.javamail.r...@md01.wow.synacor.com
