Into.the.Void.

The case is this, a debian server running Debian 4.0 etch has it’s motherboard broken. We send it for replacement but they don’t have another of the same model to send us so they send us a shiny new model. The new model houses a P35 chipset. The latest Debian 4.0 etch kernel is 2.6.18 which does not support the ICH9 chipset that the motherboard has. The result ? The machine can’t find any sata discs attached to it and it can’t boot. Wonderfull!

Asking around for a possible solution I got two types of answers: a) build a newer kernel on my own b) upgrade the whole system to testing (lenny) instead of stable (etch).
As far as solution (a), I was not willing to build a kernel of my own. It’s not that I can’t, it’s the fact that I find it ridiculous for a debian system to have to build a kernel of my own just like I did when I was using slackware. It’s debian, the distribution thought to be the most stable and well polished and and and…there must be an automated way to run a recent proper kernel.
Regarding solution (b), I was not willing to de-stabilize my system. I want and need to run stable versions of services on that server. A lot of people told me that “testing” is very stable. If debian testing is stable enough then they must mark it as stable and push the previous “stable” into the void. While it’s named “testing” I don’t trust it.

The solve the problem, I booted with a beta of the next version of iloog, mounted the debian partition and chrooted to it. Following some help I was given on IRC I added the testing sources to /etc/apt/sources.list:
deb http://ftp.ntua.gr/pub/linux/debian/ stable main contrib non-free
deb-src http://ftp.ntua.gr/pub/linux/debian/ stable main contrib non-free
deb http://security.debian.org/ stable/updates main contrib
deb-src http://security.debian.org/ stable/updates main contrib
deb http://ftp.ntua.gr/pub/linux/debian/ testing main contrib non-free
deb-src http://ftp.ntua.gr/pub/linux/debian/ testing main contrib non-free
deb http://security.debian.org/ testing/updates main contrib
deb-src http://security.debian.org/ testing/updates main contrib


Reading some stuff about “apt pinning” I added the following in /etc/apt/preferences:
Package: *
Pin: release a=stable
Pin-Priority: 700
---blank line---
Package: *
Pin: release a=testing
Pin-Priority: 650

(that —blank line— mark should really be an empty line. due to theming problems with this blog I can’t make it appear properly inside <code> tags)

Then I issued an: aptitude update
Then I got errors like:

Dynamic MMap ran out of room
Error occurred while processing vdr-plugin-skinenigmang (NewVersion1)
Problem with MergeList /var/lib/apt/lists/ftp.ntua.gr_pub_linux_debian_dists_lenny_main_binary-i386_Packages
The package lists or status file could not be parsed or opened.
Couldn’t rebuild package cache

The solution to those were to create another file named /etc/apt/apt.conf with the following inside it:
APT::Cache-Limit "15388608";

Running aptitude update again was fine. Then an apt-cache search linux-image showed me the list of available kernels. I now had a 2.6.24 kernel available. Finally an aptitude install linux-image-2.6.24-1-686 installed the new kernel.
I had to edit the /etc/grub/menu.conf a bit for it to play nicely (due to the chrooting I guess) but afterwards the server booted just fine.

I don’t know whether what I did is good or bad for a debian system. The fact is that it works and aptitude update does not want to upgrade any of my packages to the testing version.

<rant>
Please debian maintainers, if you have finished patching your machines due to the recent openssl vulnerability you created, rename your “stable” release to “ancient” and “testing” to “stable” so we have less trouble running your distro on new hardware. Thanks in advance.
</rant>

Filed by kargig at 00:21 under Linux
9 Comments | 5,604 views