# Proxmox i karty sieciowe realtek

**URL:** <https://forum.arturhome.pl/t/proxmox-i-karty-sieciowe-realtek/10087>\
**Category:** Inne tematy\
**Tags:** sieć, proxmox\
**Created:** [9 Wrzesień 2023 08:40 UTC](https://forum.arturhome.pl/t/proxmox-i-karty-sieciowe-realtek/10087 "2023-09-09T08:40:15Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Autor:** ![rm-rf](https://forum.arturhome.pl/user_avatar/forum.arturhome.pl/rm-rf/32/9001_2.png) [@rm-rf](https://forum.arturhome.pl/u/rm-rf)\
**Data wpisu:** [9 Wrzesień 2023 08:40 UTC](https://forum.arturhome.pl/t/proxmox-i-karty-sieciowe-realtek/10087/1 "2023-09-09T08:40:15Z")

</div>

Cześć,  
Jako że czuję, że będzie to przewijało się przez kolejne miesiące to postaram się zebrać informację jak poprawić problem z kartami realtek w PVE.  
Problem przewija się z większością kart `r816x` i w sumie nie znalazłem sposobu by poprawić sterownik w oficjalnym kernelu, za to kilka wpisów na bugtracku kernela jest.  
Po aktualizacji kernela karty realtek nie chodzą stabilnie i można je bardzo prosto “ubić” co wymaga restartu karty sieciowej - nie za fajne rozwiązanie jeśli chodzi o stabilność. Rozwiązanie sprawdzone na kilku instancjach i wszędzie problem ustąpił, tak więc przejdźmy do konkretów. Całość wykonujemy z konsoli - czy to konsoli PVE czy zdalnie przez klienta np. PuTTY. Przed

1. Edytujemy plik `sources.lst` w wybranym edytorze `nano`/`vi`

```auto
nano /etc/apt/sources.list

```

I do linijek odpowiedzialnych za `main` i i `updates` dopisujemy `non-free` oraz `non-free-firmware`, przykładowe wpisy dla pve z debianem w wersji bookworm:

```auto
deb http://ftp.pl.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://ftp.pl.debian.org/debian bookworm-updates main contrib non-free non-free-firmware

```

1. Instalujemy pakiet `headers` dla kernela - potrzebny do kompilacji modułów dla kernela oraz moduł `dkms` dla karty sieciowej

```auto
apt update
apt install pve-headers
apt install r8168-dkms

```

1. Sprawdzamy status instalacji modułu przez polecenie:

```auto
dkms status

```

Naszym oczom powinno ukazać się mniej-więcej coś takiego:

```auto
r8168/8.051.02, 6.2.16-8-pve, x86_64: installed

```

Jeśli pakiet ma status installed to wszystko jest do tej pory w jak najlepszym porządku.

1. Czas pozbyć się ładowania domyślnego sterownika:

```auto
echo "blacklist r8169" >> /etc/modprobe.d/r8168-dkms.conf

```

Sprawdzamy czy na końcu pliku pojawiła się linijka `blacklist r8169`:

```auto
cat /etc/modprobe.d/r8168-dkms.conf

```

Jeśli tak to spokojnie wydajemy polecenie `systemctl reboot` i czekamy na ponowne uruchomienie terminala.

**[FAQ]**  
**1. Jaką masz kartę ethernet spokojnie sprawdzisz przy pomocy polecenia:**

```auto
lspci -k

```

tam będzie wpis podobny do tego (tu już z poprawionym sterownikiem, u Ciebie sterownik będzie inny):

```auto
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
        Subsystem: Dell RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
        Kernel driver in use: r8168
        Kernel modules: r8168

```

**2. Nie zauważyłem u siebie problemu**  
Prawdopodobnie siedzisz na starszym kernelu niż problematyczny. Kernel 6.x zaczął mieć ten problem lecz nie jestem w stanie powiedzieć, od którego wydania dokładnie. Wersję kernela sprawdzisz poleceniem:

```auto
uname -r

```

co da odpowiedź np:

```auto
6.2.16-8-pve

```

Jeśli twój kernel zaczyna się od cyfry `6` to warto zaaplikować powyższy sterownik zamiast domyślnego

**3. Mam kernel w wersji 6.x i nadal nie widze problemu**  
Tak więc albo masz dużo szczęścia i Twój vendor płyty głównej nie namieszał z kartą, albo jeszcze nie obciążyłeś karty odpowiednio dobrze by przestała odpowiadać.

**4. Kiedy problem zostanie naprawiony po stronie kernela?**  
Tego nie wie nikt - póki co na bugtrack są wpisy ludzi ale nikt się nie podejmuje szukania tego problemu, tak więc pewnie 90% użytkowników przesiądzie się na moduł `non-free` i problem zostanie olany jak to ma miejsce z innymi problemami, np. z ACPI gdzie patche w kernelu pojawiają się nawet z rocznym opóźnieniem gdzie wdrożenie nowych flag to nie szukanie problemu jak to ma miejsce z tym sterownikiem.
