Bug#594127: Fwd: Re: Bug#594127: Fix for bug number 590028 is incomplete

[Ben Hutchings]

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.

[Stephen Powell]

Post by Ben Hutchings

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.

Post by Ben Hutchings
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.

Post by Ben Hutchings
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
: :' :
`. `'`
`-

[Ben Hutchings]

On Fri, Aug 27, 2010 at 09:50:47AM -0400, Stephen Powell wrote:
[...]

Post by Stephen Powell
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

[Stephen Powell]

Post by Ben Hutchings

Post by Stephen Powell
[...]
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
: :' :
`. `'`
`-

[Stephen Powell]

Post by Stephen Powell
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
: :' :
`. `'`
`-

[Ben Hutchings]

On Fri, 2010-08-27 at 09:50 -0400, Stephen Powell wrote:
[...]

Post by Stephen Powell
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.

[Stephen Powell]

Post by Ben Hutchings

Post by Stephen Powell
[...]
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
: :' :
`. `'`
`-

[Ben Hutchings]

Post by Stephen Powell

Post by Ben Hutchings

Post by Stephen Powell
[...]
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.

Post by Stephen Powell
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.

[Stephen Powell]

Post by Ben Hutchings
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
: :' :
`. `'`
`-