Swapping motherboard under an existing Debian squeeze install
 

Here's a naive question: Is it inadvisable to change out a motherboard under an existing Debian squeeze x86_64 installation? I don't know how much tailoring Debian does during installation, and I don't know how much nuisance I will cause myself. The machine in question is a household file server. It is not a particularly critical machine, and it is backed up.

The particulars are that I want to swap out a MSI K9N SLI and swap in a Gigabyte GA-M57SLI-S4, rev2. Both use the nForce 570 SLI chipset. Memory, CPU, and graphics card will stay with the computer, I just want to swap the board itself.

I understand that I could get in trouble if I tried to slide a 32 bit board in under a 64 bit OS, but that's not the case here. What problems will I encounter?

I'm sure this has been discussed before, at least the general idea, but I have not managed to come up with suitable search terms. My searches have produced a great many interesting but irrelevant results.

It's no real bother.

Your home brewed initrd will be junk, but the board should stand up and start X, if the video card & monitor are the same. Either way, you'll get to runlevel 3. I would set initdefault in /etc/inittab to console level (3 usually).

Once running, optimise. check your correct modules are loading (don't forget sensors). Get the hd speed and stuff in /etc/modprobe.d right for the new system. Tell us if you notice any problems.

Debian (and almost all derivatives) uses runlevel 2 by default and all other runlevels (except 0,1 and 6 of course) are the same. If you don't want to start X you have to disable the DM. But since this is a server I don't know if even a X environment is installed.
I doubt that it won't work perfectly out of the box after the change.

One problem you will run into if ethernet ports are on the motherboard is that udev will have cached a rule assigning interface "eth0" to the MAC address of the old ethernet port. On the new motherboard, the new MAC address will be bumped up to be "eth1" and the network configuration for "eth0" will not be used on "eth1". Check file "/etc/udev/rules.d/70-persistent-net.rules". If you find "eth0" did not come up, but "eth1" did, you can simply delete "/etc/udev/rules.d/70-persistent-net.rules" and reboot. Then udev will re-create it, but now with the new MAC address, and use "eth0" appropriately.

Skaperen, that's good info about the ethernet interface naming, and just the sort of thing I was looking for. I will rename 70-persistent-net.rules, and watch what happens. I did think about enumeration order of device names for disks and partitions, and accounted for that in fstab. I wonder if there are 6 x 10^23 other similar considerations.

I'll get to it this weekend, I hope. Right now, my office (and radio shack, and library) is awash in computer parts.

Pass the beer nuts.

I'm sure there are at least that many other considerations to make. Better get started now :D

If you just rename one of those sequentially numbered rules files, they will still be used, but maybe in a different order. If you want to disable some rules, move it out of that directory.

Just for the record, the swap did not take place. The GA-M57SLI-S4, which had been carefully stored, had apparently not been stored carefully enough. It was dead. No POST, no nothing. I spent more hours than I care to admit excluding and swapping components. Finally, I had only a known good power supply, known good memory, a known good video card, a known good CPU, and the GA-M57SLI-S4. Still, no dice. When the board was powered up, the various fans spun up and the diagnostic speaker made two ticks and nothing else.

Two diagnostic ticks seems to mean a corrupt BIOS. I spent a great deal of time trying miracle cures, blind flashes, and other ineffective techniques. Finally I decided that keeping this up until I fried another component, although my natural inclination, wouldn't cause bliss, so I paid a visit to Newegg.