[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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    
 : :'  :
 `. `'`
   `-



Reply to: