The most performant PC in the house had started to blue screen at odd intervals. I had taken this machine over recently and used it as the test bed for Windows 7. At first, the events were weeks apart, but recently the machine started spontaneously shutting down after about 30 minutes of use. I opened up the case and re-seated all the components and attempted to reboot. Hmm, it would not power on. I left it for half-an-hour and tried again. This time it booted, but I noticed the CPU cooler fan was spinning very slowly; had it failed and the CPU was in the process of frying?
I turned the machine off again and attempted to remove the cooler. Big mistake - I pulled the CPU out with it. The thermal paste had obviously cemented the cooler to the CPU. I carefully (but probably far too late) separated the CPU and cooler. There were a number of bent pins on the CPU which I straightened. The CPU reinserted OK, but the system would not boot again. Power would come on momentarily, but that was all. It was dead.
At this point I was uncertain if the damage was limited to just the CPU or affected the motherboard as well. The decision on replacement was made easier when I discovered that the AMD CPU was socket 939 which had been superceeded in 2006. I didn't really want to invest in an already deprecated socket type. OK, time to buy new motherboard, CPU and memory. I wanted to go for Intel, with a board that could also be supported by Debian Lenny. However, finding a reasonable modern board which had some explicit confirmation that the sound chip and LAN were supported by Debian was hard to come by.
I eventually decided not to worry about it. The main purpose of the machine was to run Windows 7. If I had to wait a while for full Debian support, well I had two other Debian systems to use.
In the end I chose the following hardware, which I figured provided a reasonable price/performance ratio:
The motherboard included a Realtek ALC881 sound chip and a Realtek RTL8168c/8111c ethernet device.
I removed the old motherboard, CPU and memory from the PC case and added the new components. I could retain all the peripherals; ATI Radeon HD 4670, two SATA hard drives and two IDE DVD drives. Most of the existing case connections found a home, except the 1394 port, which is not supported by the motherboard.
For the first power-on test, I left the peripherals disconnected. I connected the PC to the mains, crossed my fingers and pressed the power-on button. Success. An MSI splash screen, where pressing DEL got me into the BIOS configuration screens.
I connected up the IDE and SATA drives. Would it be able to boot up the existing OS installs? Well, no, it booted into the old Windows XP install - looks like I had the SATA disks the wrong way round. A quick cable change later, the PC booted into the Grub menu and I could start Windows 7. It seemed to cope reasonably well after I'd swapped motherboards from out under it. Both the LAN and sound worked, so it must have located appropriate drivers.
Now I was in a position to install the official Windows 7 Professional edition (I had pre-ordered it because of the very competitive deal offered) over the top of the RC test version I'd originally tried out. How nice to be completely legitimate...
I dicovered later that in order to use the Canon MP530 printer on
the Windows 7 machine from Windows XP clients, I had to re-install
the printer on the clients. This seemed impossible at first, as
Windows XP claimed the Canon drivers I had were not suitable for the
printer. I discovered that the printer is renamed under Windows 7,
such that it does not match the name in the Windows XP driver .inf
file. In order to install the Canon driver, the file
mp530pr.inf must be edited, changing:
;WindowsXP [Canon.NTx86.5.1] "Canon MP530 Series Printer" = CNM_0279XP, USBPRINT\CanonMP530837E, CanonMP530
to
;WindowsXP [Canon.NTx86.5.1] "Canon Inkjet MP530 Series" = CNM_0279XP, USBPRINT\CanonMP530837E, CanonMP530
How would Debian fare? Very well; also both the Realtek 8168c/8111c
ethernet and Realtek ALC881 sound worked, although I had to remember
to unblacklist the snd-hda-intel module from when I had
originally installed the ATI graphics
card. However, there was a strange problem with the network
device. See the section below, entitled udev naming of network devices
The network device, which was the only one in the system, was being renamed by udev to eth2, the clue being the message:
udev: renamed network interface eth0 to eth2
Why was it doing this? A quick search revealed that the udev rules,
specifically /etc/udev/rules.d/70-persistent-net.rules was
the culprit. It still contained the rules generated from the
previous motherboard (with two NICs, one wired, one wireless), hence
the 'new' ethernet device was named as eth2. The fix was to delete
the network rules file and reboot.
After booting, the interface was still called eth2. The boot message still appeared and in the persistent network rules file, the kernel name was mapped to eth2 again. What was causing this?
After much digging around in the udev source code, reading
descriptions of the functionality, I could not figure out how the
information regarding the previous eth0 and eth1 were being
persisted. Then I found an article which mentioned that udev rules
were also present in the initramfs used by the Debian Lenny
kernel. Yes, it looked like initramfs copied the
/etc/udev/rules.d/ rules at the time of kernel installation
when the mkinitramfs-kpkg was run. So, if I re-installed
the current kernel image, after I deleted the
/etc/udev/rules.d/70-persistent-net.rules file then the
boot information for the kernel should be correct.
So, I removed and installed the current kernel:
amber:~# apt-get remove linux-image-2.6.26-2-686 amber:~# apt-get install linux-image-2.6.26-2-686
Naturally, I ignored the dire warnings this produced. On reboot, eth0 was back.
