On Tue, Jun 29, 2010 at 04:24:48PM -0400, Stephen Powell wrote: > On Mon, 28 Jun 2010 19:07:16 -0400 (EDT), Ben Hutchings wrote: > > ... > > I can put a one-time warning into linux-base. But the default for > > squeeze must be 'no'. It should not be necessary to create > > /etc/kernel-img.conf at all in squeeze. > > Sorry I didn't think of this the first time, but there are up to > four steps to preparing a kernel for booting: > > (1) Installation of the kernel itself > (2) Creation of an initial RAM file system > (3) Updating symbolic links
they are deprecated and shouldn't be necessary. there are even more evil incarnations like reverse symlinks or whatever. which we no longer support since longer.. it be better to just get rid of them. > (4) Running the boot loader installer > > Not all steps are required in all cases, depending on the circumstances. > Neither grub version 1 nor grub version 2 generally use symbolic links; > so that hasn't been on the forefront of most people's minds. > Strictly speaking, the historic boot loaders such as lilo > and zipl don't *have* to use symbolic links, but as they > have historically been used in Debian systems, they generally do. > > Obviously, item 1 takes care of itself. For stock kernels, > item 2 also takes care of itself. And it appears that the > latest version of initramfs-tools provides hook scripts > of the same name in /etc/kernel/postinst.d and > /etc/kernel/postrm.d which take care of item 2 for kernel > image packages created by make-kpkg and make deb-pkg as well. > (Actually, that item does need some work, but I'll come > back to that later. For now, let's assume that item 2 > is taken care of.) Item 4 is what we've been talking about. > Each boot loader that needs some kind of update will have > to provide a hook script starting with "zz-". > > Now the question is, what should we do about item 3, maintaining > the symlinks? For stock kernels, that has historically been > handled by variables in /etc/kernel-img.conf: do_symlinks, > relative_links, and link_in_boot, mainly, though there are > other seldom-used variations. But you just said that the goal > was to be able to eliminate /etc/kernel-img.conf. So what > do we do about symlinks? Fortunately, the "update-initramfs -u" > issue doesn't affect the symlinks. The symlinks only need to be > maintained, if at all, when a kernel is installed, updated, > or removed. The symlinks are not, strictly speaking, associated > with a package. Should the boot loader script take care of > it? Or should this be a separate script? What do you think? get rid of them. they are ugly and useless. > I said I would come back to initramfs-tools; so now I'm back. > There are two issues with the script as written today. > (1) it does not redirect standard output to standard error > when invoking update-initramfs. Thus, the user sees no > output (since debconf swallows it) and, depending on the output, > it may cause problems for debconf. (2) it unconditionally > creates an initial RAM file system for kernel image packages > created by make-kpkg, even if the user doesn't want one. > There is a way to check to see if one is needed. I can > submit a revised version of the script if you like. Would > you like me to do so? hate those indirections due to debconf magic, but why would the hook scripts need one. thanks for hints, been staying away from debconf for long.. the unconditional is expected and there is a wishlist bug open for that it has not high priority as many things do not work if you don'T use an initramfs. thanks ps if you want the no cc thing set up your mua appropriately. here in d-kernel we do cc. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100629203540.gh9...@baikonur.stro.at
