Hi.

Question [A]:
Can I keep my current Linux installation after replacing my motherboard (only that)?

Details:
Nothing major will change. Actually, everything will remain the same (cpu architecture remains, ata remains ata, sdram remains sdram, etc...) except one thing. From now on there will be two cpus instead of one (as my new MoBo supports two P3 tualatin CPUs). That's the whole change.

Apology:
I know that this question was answered multiple times here at LQ (here and here for e.g.), but I need to know for sure.

I made a theory of mine to answer my own question, so I'd like to ask everybody (who reads this thread of course) to verify it.

The theory:
Since nothing major changes (replacing a P3 MoBo to another P3 MoBo), and I currently have a "generic" kernel supplied by my distribution of choice, my system should detect the new chipset without any problems (as it would detect a new sound card for example). Why I think this should happen, is that this "generic" kernel has all the drivers integrated, which is good, because during each boot up the kernel "re-detects" the system hardware. From the kernel's perspective the MoBo change is nothing else but another usual hardware change, and because of this it should boot normally.

Question [B]: Somewhere I read that after the MoBo replacement I need to generate a new initrd image. Is that so?

Question [C]: In one of the linked posts someone pointed out that it is possible to put in a single linux installation into completely different computers (assuming the CPU architecture is the same in each PC) without any troubles, but it is not recommended. Why?

My theory tells me that the kernel doesn't care what drivers it needs to load during hardware detection, so I don't really understand why isn't it recommended to put the installation into different PCs.

Thanks for reading!

A. System reinstall is not required. I've done worse and got away with it. A system reinstall isn't even advantageous.

B If your mobo chipset has changed, you want to have the driver(s) for the new chipset in the initrd. This affects disk, usb, and even video. Again, you can chance your arm with what you have got. If we had specifics we could call it exactly.

C. Putting a single installation is done, for example, in diskless workstations. It is not recommended for normal folks because network settings have to be individual.

Hi,

The big worry is if your kernel supports the new chipset along with new subsystems. If not then you may need to upgrade or custom your kernel.

The new MoBo will have a VIA Apollo Pro chipset. I think it is supported by the kernel, since it is an old piece of hardware.

I have seen motherboards that are the same model but different revision levels that wouldn't work. There is not a magic number of part changes that will tell you. For the most part you can substitute a same model board if most of the chips are the same. You may have little to no luck with any other choice. Plan on a clean install.

it depends if your new chipset is compatible to the old motherboard there in no reinstallation required.

Just spotted this. Do be careful; I have had much grief with via chipsets.
e.g. check your pci bus speeds. My last mobop replacement had to have an 'anything but via' chipset

I know someone who also has an old P3 board with the same via chipset, and he says there's nothing wrong with it.

It is a very old chipset on a very old motherboard (Gigabyte GA-6VTXD), so it is most likely that there were made some workarounds for the issues it had (if there were any) long ago.
The Abit VP6 also has the Via Apollo Pro chipset, and this MoBo is listed in the LQ HCL.
I hope there won't be any issues.
As soon as I get the board I'll report if there gonna be any problems.

I have had no trouble with via chipsets in all the time I have been running linux.

I am happy for you. I have had major grief. The kernel option
option ehci_hcd ignore_oc=1 was added to kernel 2.6.19 because in two of the usb ports the chip simply did not behave. They spewed 'overcurrent change' warnings with the sockets empty. I believe they subsequently disabled the offending ports internally rather than fix the issue. I had to boot with options like 'noapic' and 'acpi=off' because the via apic hardware was broken, and it assigned everything in the box the same few half assed irqs while devices dutifully went looking on the hard coded interrupt numbers. It insisted on handing one nic irq 12 but setting it up to react to irq 11 and I had to fix that with jiggery pokery - thank heavens for(spit) m$ windoze without which I would never have sorted that one. Those errors repeated on a subsequent via chipset - kt400 iirc. Hence my 'anything but via' approach.