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

Re: powerpc kernel-patch 2.6.6-5 in incoming since over a month !!!



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!



Reply to: