The 2.5 gigabit port on my new board does not work on Linux, and I have never had an Ethernet problem before

One symptom worth separating from the driver question, because it looks identical and is not: a link that comes up and then drops under sustained transfer.

If the driver is loaded and the interface links at the expected speed, but large transfers stall or the link resets, look at cabling and heat before rebuilding anything. These controllers run warm, and 2.5 gigabit is much less tolerant of marginal cable than gigabit is — a run that was fine at the lower speed can fail at the higher one.

Forcing the link to gigabit is a good diagnostic. If everything is stable at the lower speed, the driver is fine and you have a physical problem.

Find out what is bound before doing anything:

lspci -nnk | grep -A 3 -i ethernet

That prints the device, its numeric identifier, and the kernel module in use. Note the identifier — it is what you search with, and it is far more reliable than the marketing name on the box.

Then, in order of preference:

1. A newer kernel. Support for these controllers has improved steadily, and the single most effective fix is a kernel newer than the one your distribution shipped. Several distributions offer a newer kernel as a supported option, and this is far better than any manual driver because it keeps updating.

2. The vendor's out-of-tree driver, built and installed, with the in-kernel one blacklisted so it does not claim the device first. This works and it is a module you must rebuild on every kernel update unless you install it through the mechanism that does that automatically.

3. A cheap add-in card on a different chipset. Genuinely the right answer for some people — it costs less than an evening.

The reason it is the network port is specific and it is not bad luck: the 2.5 gigabit controllers from one popular vendor are a recent family, and the in-kernel driver situation for them has been messy for years.

What happens is that the kernel ships a driver for that vendor's long-established gigabit chips, and it also claims the newer 2.5 gigabit ones because they identify similarly. The result is one of three states depending on your kernel version:

• No interface at all — nothing claimed it.
• An interface that exists and never links — the wrong driver bound to it.
• An interface that works and drops under load, or negotiates at a lower speed.

All three are the same underlying situation. The other operating system works because the vendor ships a driver there directly.

So the question is which driver is bound, and the fix follows from the answer.

If you go the out-of-tree route, install it through the framework that rebuilds modules automatically on kernel updates rather than compiling it by hand.

A hand-built module works until the next kernel update, at which point the machine boots with no network and no obvious reason. That failure lands weeks later, when nobody connects it to the driver they installed, and it is a genuinely unpleasant hour.