Bug#594127: Fix for bug number 590028 is incomplete
On Sun, 29 Aug 2010 21:53:24 -0400 (EDT), Ben Hutchings wrote: I don't think this urgently needs to be fixed before squeeze, as it is only affects unofficial kernel packages. And that is the first explanation from *anyone* as to why the severity should be important instead of serious. If Bastian had said that in the first place, it would have been helpful. I was only trying to follow the policy as I understood it. But regardless of what is done about symlinks, s390-tools is still lacking an initramfs hook, which is not policy compliant. That is very easy to fix, however. Well, you all are now well aware of the problem, and you can decide what you want to do about it. And I have a circumvention which I will publish on my kernel building web site for anyone else who may wish to implement my solution until an official solution is available. -- .''`. 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/2003377395.464049.1283167122449.javamail.r...@md01.wow.synacor.com
Bug#594127: Fix for bug number 590028 is incomplete
On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] After thinking about this some more and actually trying to implement the hook scripts, I think I agree. These symlinks are horrible and by default we should not create them. As a stopgap, boot loader packages may create and then use the links, but I would much prefer that they construct a menu of all installed kernel versions, as GRUB and extlinux do. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: Digital signature
Bug#594127: Fix for bug number 590028 is incomplete
On Sun, 29 Aug 2010 16:20:20 -0400 (EDT), Ben Hutchings wrote: On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] After thinking about this some more and actually trying to implement the hook scripts, I think I agree. These symlinks are horrible and by default we should not create them. As a stopgap, boot loader packages may create and then use the links, but I would much prefer that they construct a menu of all installed kernel versions, as GRUB and extlinux do. Hmm. Well, I agree that the approach taken by grub-legacy and extlinux is more flexible. It allows more than two kernels to be bootable. But boot loaders such as lilo and zipl have historically used symlinks, and the symlink maintenance logic in my generic boot loader hook scripts, http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader and http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader, isn't really that complex. I'm curious as to why you consider symlinks to be horrible. For now, on my own systems, I have extracted the symlink maintenance logic from the above generic boot loader hook scripts and have created new hook scripts which I call zy-symlinks. It allows me to use the new boot loader packages with their kernel hook scripts which only invoke the boot loader installer without modifying them. I also have my own generic initramfs hook script which I use with zipl, http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader. (By the way, I like the way you were able to avoid a bashism, namely substring expansion, by using a case statement in lilo's initramfs hook. Very clever!) But Debian clearly needs to do *something* about this problem *somewhere*. -- .''`. 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/631424779.459359.1283131904359.javamail.r...@md01.wow.synacor.com
Bug#594127: Fix for bug number 590028 is incomplete
On Sun, 2010-08-29 at 21:31 -0400, Stephen Powell wrote: On Sun, 29 Aug 2010 16:20:20 -0400 (EDT), Ben Hutchings wrote: On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] After thinking about this some more and actually trying to implement the hook scripts, I think I agree. These symlinks are horrible and by default we should not create them. As a stopgap, boot loader packages may create and then use the links, but I would much prefer that they construct a menu of all installed kernel versions, as GRUB and extlinux do. Hmm. Well, I agree that the approach taken by grub-legacy and extlinux is more flexible. It allows more than two kernels to be bootable. But boot loaders such as lilo and zipl have historically used symlinks, and the symlink maintenance logic in my generic boot loader hook scripts, http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader and http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader, isn't really that complex. I'm curious as to why you consider symlinks to be horrible. Because of the limitation to two versions, arbitrarily designated 'current' and 'old'; the fact that they could be in /, /boot, or even configured to be elsewhere; and the problem of stale links. For now, on my own systems, I have extracted the symlink maintenance logic from the above generic boot loader hook scripts and have created new hook scripts which I call zy-symlinks. It allows me to use the new boot loader packages with their kernel hook scripts which only invoke the boot loader installer without modifying them. I also have my own generic initramfs hook script which I use with zipl, http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader. (By the way, I like the way you were able to avoid a bashism, namely substring expansion, by using a case statement in lilo's initramfs hook. Very clever!) But Debian clearly needs to do *something* about this problem *somewhere*. I met Colin Watson last night and he said that he (as GRUB maintainer) and Daniel Baumann (as syslinux maintainer) had discussed writing a common boot loader policy. Due to the interaction with kernel packages and initramfs builders, I think we could combine this with the extension of the kernel and initramfs hooks policy. I don't think this urgently needs to be fixed before squeeze, as it is only affects unofficial kernel packages. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594127: Fix for bug number 590028 is incomplete
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
Bug#594127: Fix for bug number 590028 is incomplete
On Fri, Aug 27, 2010 at 09:50:47AM -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] No, that means it has to be repeated in many different packages. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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/20100827152502.gs5...@decadent.org.uk
Bug#594127: Fix for bug number 590028 is incomplete
On Fri, 27 Aug 2010 11:25:02 -0400 (EDT), Ben Hutchings wrote: On Fri, Aug 27, 2010 at 09:50:47AM -0400, Stephen Powell wrote: [...] Personally, I think that the requirement to maintain symlinks, if used, is implicit in the purpose of the boot loader hook script. [...] No, that means it has to be repeated in many different packages. That's true. I guess I wasn't thinking along those lines because I created a one-size-fits-all boot loader hook script for my own use before boot loader packages started including boot-loader-specific hook scripts. The alternative, obviously, is a separate hook script to maintain symlinks. That immediately raises two more questions: (1) How do we make sure that it executes *after* the initramfs hook and *before* the boot loader hook, and (2) which (required) package will own and maintain it? Your thoughts? -- .''`. 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/1946156595.417436.1282932133585.javamail.r...@md01.wow.synacor.com
Bug#594127: Fix for bug number 590028 is incomplete
On Fri, 27 Aug 2010 14:02:13 -0400 (EDT), Stephen Powell wrote: The alternative, obviously, is a separate hook script to maintain symlinks. That immediately raises two more questions: (1) How do we make sure that it executes *after* the initramfs hook and *before* the boot loader hook, and (2) which (required) package will own and maintain it? Your thoughts? I just thought of something else. Currently, the default value for do_symlinks in /etc/kernel-img.conf is yes, if I'm not mistaken. But in Squeeze, that will only apply to stock kernels. In order to take care of symlinks for kernels created by make-kpkg and make deb-pkg, a symlink hook script will be needed. But then, for stock kernels, symlinks will be maintained twice, which is duplication of effort. So the default value for do_symlinks should change to no, once the hook script is in place. As for the hook script itself, it doesn't need to examine /etc/kernel-img.conf. The logic could say, for example, if /vmlinuz exists and is a symbolic link, or if /boot/vmlinuz exists and is a symbolic link, then maintain symbolic links. Otherwise don't. Or maybe you want to check for all four of the standard symlink names (vmlinuz, vmlinuz.old, initrd.img, initrd.img.old) instead of just vmlinuz. Your thoughts? All of this still leaves zipl without a (required) initramfs hook, though. -- .''`. 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/1655031521.417755.1282933247863.javamail.r...@md01.wow.synacor.com
Bug#594127: Fix for bug number 590028 is incomplete
Quoting from http://www.debian.org/Bugs/Developer#severities Severity levels ... serious is a severe violation of Debian policy (roughly, it violates a must or required directive), or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. The previous post shows that a *must* directive is being violated. Therefore, setting severity to serious. -- .''`. 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/2081948446.389791.1282846668676.javamail.r...@md01.wow.synacor.com
Bug#594127: Fix for bug number 590028 is incomplete
severity 594127 important thanks On Thu, Aug 26, 2010 at 02:17:48PM -0400, Stephen Powell wrote: The previous post shows that a *must* directive is being violated. Therefore, setting severity to serious. Don't play bts ping-pong. Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 -- 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/20100826184757.gb10...@wavehammer.waldi.eu.org
Processed: Re: Bug#594127: Fix for bug number 590028 is incomplete
Processing commands for cont...@bugs.debian.org: severity 594127 important Bug #594127 [s390-tools] Fix for bug number 590028 is incomplete Severity set to 'important' from 'serious' thanks Stopping processing here. Please contact me if you need assistance. -- 594127: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594127 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.12828484968700.transcr...@bugs.debian.org
Bug#594127: Fwd: Re: Bug#594127: Fix for bug number 590028 is incomplete
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. As for maintaining symlinks, that is not described by the policy at all, though it should be. We could perhaps put hook scripts for that in linux-base. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Bug#594127: Fix for bug number 590028 is incomplete
On Mon, 23 Aug 2010 17:32:36 -0400 (EDT), Bastian Blank wrote: On Mon, Aug 23, 2010 at 05:17:31PM -0400, Stephen Powell wrote: (1) the hook scripts provided, /etc/kernel/postinst.d/zz-zipl and /etc/kernel/postrm.d/zz-zipl, do not maintain the symbolic links. The zipl boot loader typically uses the historic symbolic links (/boot/vmlinuz, /boot/initrd.img, /boot/vmlinuz.old, and /boot/initrd.img.old) in its configuration file (/etc/zipl.conf) so that the configuration file does not need to be updated with each kernel install or remove, as grub-legacy's configuration file does (/boot/grub/menu.lst). The advantage of using the symbolic links is that the configuration file never needs to be maintained when a kernel is installed or removed. The disadvantage of this method is that the symbolic links themselves must be maintained when a kernel image is installed or removed. They are still maintaned by the kernel. If you think this is wrong, go there. For stock kernels, yes, if do_symlinks = yes is specified in /etc/kernel-img.conf. But the maintainer scripts packaged with kernel image packages created by the squeeze version of make-kpkg, which is what I use, do not maintain symbolic links, even if do_symlinks = yes is specified in /etc/kernel-img.conf. I have verified this by experimentation. I haven't yet tried building a kernel image package with make deb-pkg (part of upstream kernel source code for 2.6.31 kernels and later), but I doubt that its maintainer scripts maintain the symbolic links either. For this reason I think the severity should be serious (rc). (2) The second reason that this fix is incomplete is that the package does not contain an initramfs hook script. The latest version of initramfs-tools, 0.98, now expects boot loaders which rely on a list of blocks saved at boot loader map installer time, such as lilo and zipl, to provide a hook script in /etc/initramfs/post-update.d to react to update-initramfs -u This script does not use the zz- prefix, nor does it need to maintain symbolic links, but it does need to re-run the boot loader, redirecting standard output to standard error as the kernel hook scripts do. No, it does not yet. Present behavior of initramfs-tools is as follows: if the file /etc/initramfs/post-update.d exists, and is a directory, then the run-parts utility will be invoked to run whatever executable files are found in that directory in alphabetical order. If /etc/initramfs/post-update.d does not exist, or is not a directory, zipl will be invoked anyway as long as /etc/zipl.conf exists. So yes, zipl will still get run. Nevertheless, current policy does require an initramfs hook script. Packages for boot loaders that need to be updated whenever the files they load are modified *must* also install hook scripts in /etc/initramfs/post-update.d. (See http://kernel-handbook.alioth.debian.org/ch-update-hooks.html, section 7.3, initramfs hooks.) And since s390-tools does not provide this hook script, the package is not policy compliant. Therefore, the initial severity of serious is correct. -- .''`. 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/1225016804.325400.1282658643136.javamail.r...@md01.wow.synacor.com
Bug#594127: Fix for bug number 590028 is incomplete
Package: s390-tools Version: 1.8.3-2 Severity: serious s390-tools version 1.8.3-2 was recently migrated to testing, and it contained a fix for Debian bug report 590028. However, this fix is incomplete, for two reasons: (1) the hook scripts provided, /etc/kernel/postinst.d/zz-zipl and /etc/kernel/postrm.d/zz-zipl, do not maintain the symbolic links. The zipl boot loader typically uses the historic symbolic links (/boot/vmlinuz, /boot/initrd.img, /boot/vmlinuz.old, and /boot/initrd.img.old) in its configuration file (/etc/zipl.conf) so that the configuration file does not need to be updated with each kernel install or remove, as grub-legacy's configuration file does (/boot/grub/menu.lst). The advantage of using the symbolic links is that the configuration file never needs to be maintained when a kernel is installed or removed. The disadvantage of this method is that the symbolic links themselves must be maintained when a kernel image is installed or removed. Historically, the maintainer scripts for the kernel image package, whether they are for a stock kernel or a custom kernel created by make-kpkg, maintained the symbolic links, subject to configuration statements in /etc/kernel-img.conf, such as do_symlinks, relative_links, and link_in_boot. The maintainer scripts for stock kernel images still support this, as far as I know. However, the maintainer scripts for kernel image packages created by newer releases of make-kpkg, as well as the maintainer scripts for kernel image packages created by make deb-pkg (from 2.6.31 kernel source packages and later) do not contain logic to maintain the symbolic links. For boot loaders which rely on symbolic links, such as zipl and lilo typically do, the boot loader hook scripts must maintain the symbolic links. (The alternative, of course, is for the boot loader hook scripts to maintain the boot loader configuration file directly, /etc/zipl.conf in this case, so that symbolic links are not needed.) (2) The second reason that this fix is incomplete is that the package does not contain an initramfs hook script. The latest version of initramfs-tools, 0.98, now expects boot loaders which rely on a list of blocks saved at boot loader map installer time, such as lilo and zipl, to provide a hook script in /etc/initramfs/post-update.d to react to update-initramfs -u This script does not use the zz- prefix, nor does it need to maintain symbolic links, but it does need to re-run the boot loader, redirecting standard output to standard error as the kernel hook scripts do. I one again encourage you to look at the following generic scripts which I have been using for months quite satisfactorily. I believe that they can be made zipl-specific without much effort: http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader (for installation in /etc/kernel/postinst.d) http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader (for installation in /etc/kernel/postrm.d) http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader (for installation in /etc/initramfs/post-update.d) -- .''`. 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/752774451.308739.1282598251474.javamail.r...@md01.wow.synacor.com
