Re: Kernel version to use in the sarge based debian-edu
tirsdag 7. juni 2005, 12:55, skrev Finn-Arne Johansen:
> Showstoppers for using 2.6-kernel
> 1) So far the 2.6-kernel needs lvm2, and the current autopartkit does
> not work with lvm2.
In my opinion this should not be viewed as a valid showstopper for using 2.6
kernel in debian-edu, but rather be viewed as a showstopper for the next
release of debian-edu.
> 2) were we need 2.6 kernel (sata-controllers mostly), the cdrom is often
> not accessible during installation.
This is new to me (probably me not having enough experience with SATA yet).
How come this being the case with no cdrom during install?
> 3) Some scsi raid controllers are not availible on the 2.6.8-kernel used
> by the installer, they are not even availible on the Debian sid
> 2.6.11-kernel.
True, but is this a bigger issue than missing support for SATA?
> 4) not sure, but I think a very common (crappy?) ethernet driver is
> missing on the 2.6-8 kernel, At least it's missing from 2.6.11 from sid.
> the driver is tg3 (yeah, I know it's crap, but I have it on my laptop)
>
Hm ok. For all I know it might be just that, but never the less I'm not
prepared to accept the suggestion that a driver is less reliable based only
on the fact that there's some closed source involved (in this case a piece of
aggregated firmware).
Therefore (out of curiosity and the fact that one of my servers actually use
this driver) I do wonder in which way this driver is crappy ..
Would you be kind enough to help me out by explaining in short terms what you
put into this choice of words. :)
> Showstopper for 2.4-kernel
> 5) some controllers does not work
>
> I've sent a patch for 1), and I've bugged 2). I found someinfo about 3)
> from ubuntu, I've experienced 4), but not bugged it.
>
Regarding number 4 this is not an issue with 2.6.8 and to be honest I do see
this debate surrounding the aggregation of firmware as a big political
steer-up about basicly nothing. (Firmware is typically so close to hardware
that it should be viewed as part of the hardware rather than software in its
own rights.)
Adding to this it seems like this firmware tainted driver is likely to end up
in an alternative kernel, morally correct and securely placed by debian in
the non-free dept.
(In other words: Big deal.)
With regard to what kernel to use I'm not sure what is the better solution -
stick with 2.4 or go for 2.6. Either way it seems that new HW only will be
increasingly harder to support from a 2.4 in near future ...
Maybe the better solution will be to reverse the strategy used in debian woody
- base the distribution on the new kernel and supply the old one as an
option?
Regards
Gjermund Skogstad
Reply to: