Otavio Salvador wrote: > The installer itself, sometimes, need modifications or fixes to be able to > handle newer kernel versions so the version that is hard-coded on those is > the version that is supported by the installer. It is not only a matter of > recompile installer against the new kernel (sometimes this works by this is > not guaranteed). Another important point is that there are architectures > that use different kernels depending on the subarch (e.g armel uses iop32x, > kirkwood and others) and dynamically it is more difficult to handle this. > > Specifically about the patch it is incomplete since it doesn't handle all > the architectures thus we can't take it.
Hi, Sorry I haven't had time to get back to this until just now. So, I don't have any of the subarch's to test this, but I believe they are already handled appropriately in the "UDEBS =" line in my patch. I'm concluding this based on the .cfg files, for example iop32x.cfg would produce 2.6.32-5 for the KERNELIMAGEVERSION var, and that is what I would automatically return from the automatic processing of the Packages file. Will it ever be the case that the kernel version as stated in the debian-installer_binary-ARCH_Packages file will differ from the hard-coded value in the cfg files? It seems like they would have to be the same, otherwise d-i would fail trying to download non-existent files, but I may be missing something. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920000313.27e767e7ade48b285bee5...@gmail.com
