8bdcb48291
Adaptoarele Realtek RTL8156 (r8152) sunt placa de retea principala pe DOUA noduri, nu doar pe pveelite: pve1 are enx6c1ff759e2cb ca bridge-port, exact aceeasi configuratie si aceeasi vulnerabilitate. pvemini e in regula, are Intel igc pe PCIe. Defectul nu e resetul USB in sine, ci ca interfata recreata nu mai ajunge inapoi in vmbr0: e declarata "inet manual", fara auto si fara allow-hotplug, deci se ridica doar ca efect secundar la boot. Nodul ramane pornit si invizibil, la nesfarsit - 16 ore pe pveelite in noaptea asta, plus inca un reset azi la 10:31, in timp ce lucram la asta. Regula udev prinde reaparitia interfetei si porneste o unitate systemd care da ifreload -a. Am ales ifreload, nu ifup, din doua motive: interfata e port de punte si doar ifreload reface legatura cu vmbr0, si e comanda verificata in teren - exact ea a readus pveelite in retea de doua ori azi. Doua capcane platite, amandoua consemnate in fisiere ca sa nu se reia: 1. Prefixul 70- NU functioneaza. ID_NET_DRIVER e populat abia de 80-net-setup-link.rules, deci la 70- variabila e goala si regula nu se potriveste - tacut, fara nicio eroare. udevadm test citea fisierul, dar RUN-ul nu aparea in lista finala. Prima rulare a testului a "reusit" doar pentru ca a lucrat plasa de siguranta la 90 s, nu regula. Cu 99-, revenirea e in 8 secunde. 2. PowerShell inghite ghilimelele cand paseaza argumente catre ssh, iar nodul primea [ = r8152 ] in loc de [ "$d" = r8152 ]. Scripturile remote se trimit acum codificate base64, nu prin niveluri de citare. Testat cu reset USB real pe pveelite (deautorizare/reautorizare pe magistrala, adica exact ce face controllerul cand cedeaza singur): revenire in 8 secunde, unitatea usb-lan-hotplug@eth0.service pornita si terminata cu succes. Instanta e eth0 pentru ca evenimentul add precede redenumirea in enxMAC - unitatea ignora %I si reaplica toata configuratia, deci nu conteaza. 8 secunde e sub tokenul corosync de 10 s, deci un reset USB nu ar mai trebui nici macar sa scoata nodul din cluster. Testul isi armeaza singur o plasa de siguranta - ifreload -a programat la 90 s - ca o regula gresita sa nu ceara drum pana la nod. A si folosit, la prima rulare. Pe pve1 am instalat fara testul distructiv, acolo ruleaza CT 101 si CT 110; verificat neinvaziv cu udevadm test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VAEUqrv26jCM5KwAPtkHb8
27 lines
1.0 KiB
Desktop File
27 lines
1.0 KiB
Desktop File
[Unit]
|
|
Description=Reataseaza adaptorul USB LAN %I in punte dupa un reset USB
|
|
Documentation=file:///etc/udev/rules.d/70-usb-lan-hotplug.rules
|
|
After=network.target
|
|
|
|
[Service]
|
|
Type=oneshot
|
|
|
|
# Dispozitivul tocmai a fost re-enumerat: driverul r8152 se incarca, interfata e
|
|
# redenumita din ethN in enxMAC, iar linkul negociaza. Reaplicarea configuratiei
|
|
# inainte ca astea sa se aseze prinde interfata intr-o stare intermediara.
|
|
ExecStartPre=/bin/sleep 3
|
|
|
|
# ifreload -a, nu ifup: interfata e "inet manual" si e port de punte, iar doar
|
|
# ifreload reface legatura cu vmbr0. E si comanda verificata in teren - exact ea
|
|
# a readus pveelite in retea pe 28.08 la 09:49, de la consola fizica.
|
|
# Aplica numai diferentele fata de /etc/network/interfaces, deci nu atinge
|
|
# interfetele tap/veth ale guest-urilor.
|
|
ExecStart=/usr/sbin/ifreload -a
|
|
|
|
# Reteaua e deja rupta cand ajungem aici; o incercare esuata nu trebuie sa lase
|
|
# unitatea in "failed" si sa blocheze urmatoarea reaparitie a interfetei.
|
|
SuccessExitStatus=0 1
|
|
|
|
[Install]
|
|
WantedBy=multi-user.target
|