Re: creating kernel udebs from kernel-source
On Tue, Nov 30, 2004 at 10:55:23AM +0100, Fabio Massimo Di Nitto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sven Luther wrote:
>
> |
> |
> |> |> | multiplied by the number of architectures plus the number of
> |> | |> architectures having 2.6 kernels. |> |> ??? this makes no
> |> sence to me at all. and we are only talking |> about one kernel.
> |> |> |> You only multiply once by the number of arch. | | | Nope.
> |> you have the 2.4 kernels and the 2.6 kernel, so you add the |
> |> total number of kernels which is between the number of arches and
> |> | two time the number of arches.
> |>
> |> The patch doesn't merge kernel-source-* into one big kernel
> |> source that includes ver 1.0 to 2.8. It applies to only one
> |> kernel source (let say 2.6.9) and from that one generate propers
> |> udebs for the arch where it is building.
> |
> |
> | Ok, my fault, so we still have all the 2.4 and all the 2.6 kernels,
> | That still means 303 .udebs for the 2.6 kernels and 436 for the 2.4
> | ones. Not counting the .debs that needs to be generated too, which
> | should amount to 10-20 packages, if i am not mistaken (powerpc 2.6
> | has 20, and 2.4 has 37, while i386 2.4 has 23).
>
> Yes but the control file that is generated doesn't include all of them
> at the same time. That's the whole point of it. You still get control
> files x arch. That reduces the amount of binary packages processed
> in the run only to the ones that are actually generated. You will
> never get 300000 udebs together.
Ok, i will let those familiar with this problem (Kamion, joeyh, waldi i think)
take over here, since i don't know the details of the problem.
> |> | Actually, you have to take every available flavours as you |
> |> mentioned above. On powerpc this is 5 for 2.4 kernels and 3 for
> |> 2.6 | ones for a total of 8. (2.4 : powerpc, powerpc-small,
> |> power3, | power4, apus, 2.6: powerpc, power3, power4, soon to
> |> come ppc64 | iserie-legacy, generic and generic-power4
> |> additionally, and i have | had at least one case where the UP
> |> kernel failed and a SMP kernel | is needed, so maybe we should
> |> double some of these).
> |>
> |> You don't build udes for all the possible flavours simply because
> |> there is no need to. You build udebs only for the minimal amount
> |> that you need.
> |
> |
> | Sure you do, since these kernels are *incompatible* on the
> | instruction level set. And i wish you much luck trying to modprobe
> | a powerpc module into a power4 kernel. Or in an apus kernel for
> | that matter.
>
> We are saying the same thing Sven, if on ppc you need 3 or 4
> flavours it is ok, but there is no need to generate udebs for
> the -smp versions (as example). There is really no point since later
> the installer
> will take care of installing the proper kernel for the machine.
Except on the said power3 box, where the -smp kernel worked, but there somehow
was a bug or something in the -up one which failed to boot.
> I am not into ppc as you are but let's make a netrual example:
>
> arch foo has 20 kernel flavours, like foo32 foo64 + their -smp variants
> and whatever you want to add to it, but all of them can boot and install
> from a subset of them, like foo32 and foo64, you don't need to build
This is only the x86 exception. on other arches, this is not the case. Not on
powerpc, not on mips, not on m68k, probably not on the rest of them too.
On these, there is a separate kernel because it is needed, not because you
want some random optimizations. Try to install on a m68k/pmac with a
m68k/amiga kernel to take one example i am familiar with, and you will see
whta i mean.
> 20 sets of udebs, but just the common ones that can manage to boot
> everything since the installer will make the proper decision later.
No. This works for the -up against -smp ones, and maybe for the upcoming
ppc64/generic and ppc64/generic-power4, but for the rest of it, they are
trully separate kernel which will not run on boxes they are not meant to.
I suppose a common installer kernel could be made on those arches, but it
would amount to a *huge* amount of work, that is better spent elsewhere.
> |> I doubt anybody will ever require -smp udebs, right?
> |
> | I was not counting those in the above, we don't build them yet, but
> | i know of at least one power3 machine which worked fine with the
> | -smp kernel, but failed with the -up one. So i would be cautious
> | about this.
>
> That might easily bug in the kernel, because i can bring example in the
Sure, probably a bug in the sym53cxxx driver or something, not sure though.
> other way. This still doesn't mean that it is d-i task to workaround this
> kind of problems introducing extra sets of udebs
Well, how do you install on that box then, provided we can't fix the above
bug, if it is a bug ?
Me thinking that maybe we should use -smp variants for the power3 and power4
d-i kernels.
Friendly,
Sven Luther
Reply to: