kasia in a nutshell

The kernel upgrade I wrote about yesterday turned out to have gone well after all. The new kernel booted up fine and is completely happy and cheerful. Why did I complain then? I couldn't connect to the machine.. and today I found out why.

This is a dual CPU, dual network card (on-board) rackmount server. It's really a quite nice machine. The only problem is we're not using both network cards. It's a server, not a router and we only need one of them.. so only one is connected to the network. So far so good.

Why couldn't I connect to it after the reboot last night? Quite simple, the wrong network card came up as eth0. The one not connected to a life-giving, data-bit-flowing network cable. Which would explain why I had some trouble connecting to it. It's really not wireless.

That's the problem. The machine randomly assigns eth designations to the two cards on reboot. Sometimes one is eth0, sometimes the other. That can become a problem when only one of them is actually hooked into a live network. Particularly when I do not have local access to the machine.

The only logical explanation I could come up with is something like this..

The linux kernel assigns the eth designation to network interfaces based on the nic's IRQ -- unless they're ISA cards, at which point one has to tell the kernel what to assign where.. but these are not ISA cards. The IRQ is assigned to the card at bootstrap based on the position (I'm really guessing a bit on this one, but it's an educated guess). There is either a bug in how the IRQs are assigned, a bios misconfiguration (I don't have local access, so can't really check easily, remember?) or because both cards are the same make/model/revision it gets confused and assigns the IRQs rather randomly. I find it hard to believe that this would be by design.