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
21 lines
917 B
Plaintext
21 lines
917 B
Plaintext
# Scripturile shell rulează pe Proxmox/Linux și sunt deployate direct din
|
|
# working tree (scp către /opt/scripts). Cu core.autocrlf=true pe Windows ele
|
|
# ajungeau în working tree cu CRLF, iar bash le refuză pe Linux
|
|
# ("$'\r': command not found"). Forțăm LF indiferent de platformă.
|
|
*.sh text eol=lf
|
|
|
|
# Fișiere de configurare fără extensie, deployate pe noduri (ex.
|
|
# ups/config/battery-install-date -> /etc/nut/). Aceeași logică ca la *.sh:
|
|
# ajung pe Linux, deci LF.
|
|
proxmox/cluster/ups/config/battery-install-date text eol=lf
|
|
|
|
# Scripturile Windows rămân CRLF.
|
|
*.ps1 text eol=crlf
|
|
*.bat text eol=crlf
|
|
*.cmd text eol=crlf
|
|
|
|
# Regula udev și unitatea systemd pentru hotplug-ul adaptoarelor USB LAN ajung în
|
|
# /etc/udev/rules.d și /etc/systemd/system pe noduri. Un CRLF într-o regulă udev
|
|
# o face să nu se mai potrivească niciodată, tăcut.
|
|
proxmox/cluster/config/usb-lan-hotplug/* text eol=lf
|