Like the title says. I installed a GPU, everything posts and boots fine. The lights on the Ethernet port are lit up and will stay lit up indefinitely (I assume) if I leave it at the kernel select screen.
But as soon as I load a kernel, the lights go dark. It also is not shown as an active client on my gateway, so it’s not working at all.
I’ve tried lots of commands I’ve found to force it up. It looks to me like the NIC assigned to vmbr0 is correct. Etc. I just can’t get it to work.
If I remove the GPU, it immediately works again. NIC stays up after the kernel loads and I can access the web UI as normal.
rooteprox. *
root@prox:*# ip a
10: «LOOPBACK, UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 :: 1/128 scope host noprefixroute valid_lft forever preferred_lft forever
enpsso: ‹BROADCAST, MULTICAST> mtu 1500 qdisc noop state DOHN group default qlen 1000 link/ether a8:a1:59:be:f2:33 brd ff:ff:ff:ff:ff:ff
enp0s31f6: «NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 qdisc pfifo_fast master vmbro state DOWN group default qlen 1000 link/ether a8:a1:59:be:f2:32 brd ff:ff:ff:ff:ff:ff
vmbrO: ‹NO-CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether a8:a1:59:be:f2:32 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.3/24 scope global vmbro valid_lft forever preferred_lft forever
root@prox: *# cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface enp0s31f6 inet manual
auto vmbro
iface vmbro inet static
address 192.168.1.3/24
gateway 192.168.1.1
bridge-ports enp0s31f6
bridge-stp off bridge-fd o
iface enps0 inet manual
source /etc/network/interfaces.d/*
root@prox: ~# service network restart
Failed to restart network.service: Unit network.service not found.
There’s generally one or two slots connected directly to the CPU running in x16 or x8 if there’s two and both are connected, 4 lanes linking the CPU to the chipset, and the rest of the slots connect to the chipset and share that same x4 link. If your cpu has 24 lanes (Ryzen do/did a few years ago, Intel might but didn’t a few years ago), the remaining 4 lanes usually go to an NVMe slot
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
Aren’t the PCIe lanes directly connected to the CPU? So the connections would be rerouted in hardware to connect to the GPU?
I am not the poster but I am curious if you know what maybe happening on a hardware level.
There’s generally one or two slots connected directly to the CPU running in x16 or x8 if there’s two and both are connected, 4 lanes linking the CPU to the chipset, and the rest of the slots connect to the chipset and share that same x4 link. If your cpu has 24 lanes (Ryzen do/did a few years ago, Intel might but didn’t a few years ago), the remaining 4 lanes usually go to an NVMe slot