Thanks for your reply. > Yes it's possible. Users are supposed to have a kernel 2.6 when they > run etch. For user that lived up to here with a 2.4 kernel (wow!) then > the "fix" is to install etch's 2.6 kernel, then to upgrade to > unstable/lenny.
I think it would be best if I gave you some more background to explain the situation. ie why we're running such an old kernel & C library under Lenny. My situation is one where where we have around 300-400 boxes on a low-bandwidth network in sites throughout South Africa. A few years ago the boxes were changed over from NT to Debian testing (this was around sarge or woody). This was a massive roll-out where technicians went to each site with a custom boot CD. This was as part of other maintenance, not just for conversion from NT do Debian. Running those boxes against stable was not practical at the time because stable had very ancient software. We needed current kernel, X, kde etc. Since then we've been upgrading and upgrading our in-house software running on those boxes, but not (in most cases) upgrading the entire Debian installation as a whole. Bandwidth is too limited to run dist-upgrades. We basically run 'apt-get update' and 'apt-get install <list of packages that we want new versions of, along with others that will cause problems if they aren't installed at the same time>' Fast-forward a few years forward up until today. It is still possible to install software on those ancient setups. Several hacks are required in custom software update scripts due to incompatibility between new testing & old testing but overall it works pretty well. The latest incompatibility is this libc6 problem. There have been a lot of problems recently where I've had to add more hacks to get the upgrades to run. Including forcing removal of (old) essential packages in some cases. I could add another hack.. like disable that libc6 check, or upgrade to etches' 2.6 kernel before installing lenny's libc6 (thanks for the suggestion). I'm rather hesitant to do the latter. We only upgrade the kernel (manually) in specific cases where there are hardware problems. Automatically upgrading 100's of 2.4 to 2.6 (with our ancient configs) is asking for trouble. I think it's about time we changed over from "testing" in sources.list to "etch". I read somewhere that for etch there are plans to back-port more kernels, which will be very useful for supporting newer hardware. When we finally have to start upgrading pre-sarge boxes to Lenny then I can put all the hacks together at one time (including automatic upgrades from 2.4 to 2.6), rather than being surprised every other week with failed software updates & having to hack together a fix ASAP. Just thought I'd give you some background :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]