Re: kernel security upgrades
just as pre-comment: I know that d-i development is in a quite late
phase, and I don't know enough about d-i to know which ideas are easy
and which ones are bad - so, my questions are real questions, and please
feel free to just cluebat me enough if I'm silly. (And thanks to Frans
and the others who helped me.)
* Frans Pop (email@example.com) [050326 12:15]:
> On Saturday 26 March 2005 11:45, Andreas Barth wrote:
> > system 5. remove old udebs:
> > breaks businesscard cds the hard way, because they want to retrieve
> > them
> You are still somewhat confused....
> Businesscard CD can be broken because it downloads the kernel for the new
> system and version numbers are hardcoded in the selection of kernels. As
> the udeb responsible for this is included on the CD, it cannot be
> Netboot, floppy and S/390 installations can be broken because udebs,
> corresponding to the kernel version the installer was booted with, are no
> longer available.
> For these methods the first problem does not exist because the udeb used
> to install the kernel is retrieved from the net and so can be updated to
> use the new kernels.
Hm, do I understand it right that in the bussinesscard-case, the udeb
responsible for selection of the kernel is on the CD, whereas the kernel
is taken from the net, whereas in any other case, either both are local
or both are retrieved (and therefor, the "can't find kernel"-problem
doesn't exist)? That gives me two additional ideas, namely retrieving
the udeb (also) via the net, or putting the kernel also on the
businesscard cd (of course, I know it's a rather bad moment in time to
make such a change).
Or, the generic solution would be to update update the udeb now in a way
that it always downloads an appropriate meta-package (yes, that would be
quite many meta-packages), so that we can can update the kernel and just
update the meta package, and get the right mapping?
Is any of these ideas feasible?
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C