Discussion:
Processed: Re: Bug#594127: Fix for bug number 590028 is incomplete
(too old to reply)
Debian Bug Tracking System
2010-08-23 21:40:02 UTC
Permalink
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 ***@bugs.debian.org with problems
--
To UNSUBSCRIBE, email to debian-s390-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Archive: http://lists.debian.org/***@bugs.debian.org
Stephen Powell
2010-08-24 14:10:02 UTC
Permalink
(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-bugs-dist-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loading...