Re: Kernel version to use in the sarge based debian-edu
Gjermund Skogstad wrote:
> 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.
We dont want people to install critical servers by partitioning the
serverers wrongly. So either we need to have this fixed in autopartkit
(bugs is submitted, hopefully just waiting for the build process to
finalize this), or we need a partman-auto-lvm to fix this.
>>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?
here is how it goes:
- boot of cdrom
- drivers to access cdrom is loaded
- damn - driver for sata is loaded first, and blocks the use of PATA
cdrom
the fix:
- install by network - this is for experts only, don't install a
debian-edu-server like this on your own
- work around the bug in the installer, easier, but I dont want to go
through the process here
>>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?
For servers I still prefer SCSI over 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).
Yeah I'm sure that is why they did remove it from the 2.6.11-kernel, but
I have had serious problems with the tg3 on both my (and other)
laptop(s), and on servers. Stay clear if you have a choice. The bugs I
have experienced are:
- packets not received
- need for packet retransmit
- lockup as soon as the driver is loaded
Mostly the bugs goes away when using the bcm44xx driver, but that is a
hassle anyway ...
> 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. :)
done
>>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.)
Well - you may be right, Anyway - we really should have 2.6.11 with
another driver for megaraid than the current one. And I dont want to
maintain that in adition to everything else it takes to get a
Sarge-based debian-edu out.
> 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.)
As long as we accept java from sun, I guess we can include everything :)
(except other java implementations if I understand the terms correctly)
> 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 ...
For reliable servere, I'd say 2.4 as the default for now. That is also
the default of Debian Sarge for i386
> 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?
Well, we have based our installer on the Sarge-installer for some time.
I'm not sure when new installer will be started with newer kernels. We
want to maintain as little as possible, remember ?
--
Finn-Arne Johansen
faj@bzz.no http://bzz.no/
Leverandør av support på, drift og videreutvikling av Skolelinux-løsninger
Reply to: