Dear Sven, > Ok, i have written such a one, well it is fairly basic, and does : > > #!/bin/sh > mkvmlinuz -k $2 -o /boot/vmlinuz-$1
The existing mkvmlinuz can do this if you put the line /boot/vmlinuz-$release in /etc/mkvmlinuz/output . We could also deduce the locations of the compressed image from the location of the uncompressed image, but IMHO it's better to bail out. > Mmm, we should probably check $1 to make sure it is a initrd kernel or > something such, mkvmlinuz works for both non-initrd and 2.4 kernels. > Well, if we are not allowed to do it, then we can forget about > automatic installation of non yaboot using subarches kernel. Also, > this file is generated by yaboot-installer on a new install. The installation system is different because it's not a package and therefore Policy doesn't apply. > Yep, but this script could also be contained in the kernel packages > or something such. It's not necessary for all users of the kernel-image packages. And it has its uses independent of the official kernel-image packages (I use it to flange the d-i kernel and initrd together for Newworld Powermacs example). > A debconf question in the mkvmlinuz postinst would be the way to go, in > my opinion, since mkvmlinuz would already be postinsted when the > kernel-image is postinsted, not sure though, maybe the kernel-image > should pre-depend on mkvmlinuz then or something such. > > Also, i believe that a mkvmlinuz debconfed question would be in order > anyway. It should : > > 1) detect the subarch you are on. > 2) depending on subarch, propose to run mkvmlinuz or not. > 3) if the user chooses mkvmlinuzization, add the postinst_hook to the > /etc/kernel-img.conf file. > 4) maybe warn or something if kernel-img already contains a > postinst_hook. Sounds good. If Policy doesn't allow 3), the postinst could still check the file and present a warning. > Well, the real problem would be handling of this file by multiple > users/packages, Manoj, could you give us your opinion on this ? I just looked up the relevant section (10.7.4, shared configuration files) and have to admit that I'm at a loss. I need to think about this a bit more, and it would help greatly if Manoj commented on the issue, since he introduced this file and wrote the manpage. > What about the kernel-source ones ? There is no kernel-source-2.6.7 yet. I threw together a tarball using vanilla 2.6.7 and the patches from Christoph and ignored the missing build-time dependency. The tarball can be found at <URL:http://www.th eorie.physik.uni-muenchen.de/~jens/kernel-source-2.6.7.tar.bz2>, but as I said it contains the tainted drivers and should only be used for testing. Regards, Jens. -- J'qbpbe, le m'en fquz pe j'qbpbe! Le veux aimeb et mqubib panz je p�zqbpbe je djuz tqtaj!
