Well, you eventually discover exactly why these things go on "Price Blow-Out" sale.
Caveat Emptor and all that crap.
But this was a new one for me. Never seen anything quite like it before.
I did install the Windows 7 beta. That went really well. It looks like Vista and runs like XP, just like everyone says it does. Setup is incredibly fast on a new system. Reboot, plug in your serialz and there you have it. Very nice.
So this morning I called in sick. Because I was sick (troof!). Had an emergency dentist appointment (I've been having a lot of those lately). Now I have the rest of the day to hack around with this box.
I put Debian 4.0r6 back on it. Runs great, as usual. I do a few updates, reboot, and... why is this thing taking so long to boot up?
I check my network config. It tells me my NIC is now /dev/eth8.
ETH-fucking-EIGHT? WTF is this? This is the kind of crap that happens when you go moving your NIC around to different slots, but I haven't done that. It's a built-in NIC, for fuck's sake!
I know enough to take a look at /etc/udev/rules.d/z25_persistent-net.rules, and there they are, all NINE (0-8) incarnations of my single NIC.
And each and every one had a different MAC address.
What the motherfucking FUCK is this crap?
I wipe the file out and reboot (I've learned this from moving VMs around - they always change MAC values when you go to another host). Sure enough another new MAC address.
Then I remembered a post I read in BugTraq or somewhere about NVidia motherboards shipping with identical MAC addresses. Could this be how they fixed that problem? Flash the BIOS to change the MAC on every reboot?
Who the fuck knows? Damned Chinese junk!
I fixed it by changing eth0's line in z25_persistent-net.rules to read:
... since the first three bytes were always correct. It's a work-around and I'm screwed if I ever put another RTL NIC in that box (all I have are RTL NICs right now), but that's not in the cards at this point.
I shouldn't have to deal with this HORSESHIT, but I bought the box so I'm going to live with it. HOWEVER, the possibility exists that the MAC address could change at any time, which would be very, very bad (screwing up ARP tables and such), so I'm going to have to keep a close eye on this thing.
Thus begins the strange tale of EXP4 Revision 2.
UPDATE: turns out it was Linux all along. Check out this crap:
forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.56.
ACPI: PCI Interrupt Link [APCH] enabled at IRQ 22
GSI 16 sharing vector 0xC9 and IRQ 16
ACPI: PCI Interrupt 0000:00:07.0[A] -> Link [APCH] -> GSI 22 (level, low) -> IRQ 201
PCI: Setting latency timer of device 0000:00:07.0 to 64
forcedeth: using HIGHDMA
0000:00:07.0: Invalid Mac address detected: cd:8a:b3:4d:e0:00
Please complain to your hardware vendor. Switching to a random MAC.