Puncte:1

CentOS 7 (dracut) găsește nume inconsistente ale dispozitivelor de rețea care cauzează probleme pentru kickstart

drapel id

Folosesc opțiunile de boot biosdevname=1 net.ifnames=1 pentru a obține nume de dispozitive consecvente și previzibile. Încep să observ o problemă în care, în unele cazuri, numele dispozitivelor de rețea nu sunt consecvente. De exemplu, dacă trec la un shell de depanare dracut și mă uit la rezultatul rdsosreport.txt, văd asta:

+ adresă ip
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit 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 pentru totdeauna preferred_lft pentru totdeauna
    inet6 ::1/128 scope host
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: p3p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop stare JOS grup implicit qlen 1000
    link/ether a8:b4:56:50:97:08 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop stare JOS grup implicit qlen 1000
    link/ether a8:b4:56:50:97:09 brd ff:ff:ff:ff:ff:ff

Observați că există o combinație de denumire consistentă (p3p1) și stil moștenit (eth1).Cu toate acestea, dacă mă uit la interfețele din shell-ul de depanare dracut, văd asta:

initqueue:/run/initramfs# adresă ip
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue stare UNKNOWN grup implicit 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 pentru totdeauna preferred_lft pentru totdeauna
    inet6 ::1/128 scope host
       valid_lft pentru totdeauna preferred_lft pentru totdeauna
2: p3p1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop stare JOS grup implicit qlen 1000
    link/ether a8:b4:56:50:97:08 brd ff:ff:ff:ff:ff:ff
3: p3p2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop stare JOS grup implicit qlen 1000
    link/ether a8:b4:56:50:97:09 brd ff:ff:ff:ff:ff:ff

p3p1/p3p2 sunt numele corecte așteptate. Din anumite motive, la începutul secvenței initrd, acestea apar în format mixt. Presupunerea mea este că există un fel de cursă care se desfășoară aici și dacă i se acordă puțin mai mult timp, aceasta (udev?) se instalează în starea corectă, dar nu sunt sigur unde este exact. Din păcate, acest lucru cauzează probleme pentru unele dintre versiunile noastre automate de server, deoarece serverele apar după prima pornire (post-instalare) și încearcă să apară. et1 când numele real al interfeței este p3p2.

Am căutat prin modulele dracut pentru a încerca să-mi dau seama unde ar putea fi problema, dar încă nu am reușit să o determin concludent, așa că caut sugestii.

De asemenea, acest comportament nu se întâmplă tot timpul. Același server, pornind aceeași imagine uneori funcționează bine, iar alteori primește acest comportament de denumire mixt. Ceea ce, de asemenea, îmi spune că este un fel de cursă - uneori cursa este câștigată, iar alteori este pierdută.

Michael Hampton avatar
drapel cz
Sunt numele corecte la pornirea sistemului instalat?
guzzijason avatar
drapel id
@MichaelHampton nr. Sistemul instalat va ajunge cu fișierele de configurare `ifcfg-p3p1` și `ifcfg-eth1`, dar eth1 nu va exista. Deci, pentru ca sistemul instalat să funcționeze normal, trebuie să editez manual configurațiile rețelei. De asemenea, tocmai am atașat postării mele inițiale - comportamentul este inconsecvent, adică uneori problema se întâmplă, iar uneori nu. Ceea ce îmi spune, cursă.
Michael Hampton avatar
drapel cz
Se pare că, până când treceți de initramfs și intrați în programul de instalare, numele dispozitivelor ar trebui să se fi stabilit de mult, cu mult înainte de orice ați putea face în kickstart. Poți fi concret cu privire la ceea ce faci care are ca rezultat această configurare eșuată a rețelei?
guzzijason avatar
drapel id
Da, folosesc un initramfs personalizat, care configurează dinamic legătura LACP. Avem unele gazde single-homed, altele dual-homed și altele cu mai multe interfețe care sunt agregate într-o singură legătură. Funcționează „de obicei”, cu excepția cazului în care apare această problemă.
Michael Hampton avatar
drapel cz
Aceste lucruri personalizate sunt scrise ca un modul dracut? Acestea ar trebui să se încarce mult după ce numele udev s-au stabilit.De asemenea, fiți conștienți de faptul că dracut poate configura singur legătura, având în vedere o opțiune de linie de comandă pentru a face acest lucru.
guzzijason avatar
drapel id
Am făcut modificări la modulele dracut `40network` pentru nevoile noastre personalizate.
guzzijason avatar
drapel id
Cred că problema cursei poate fi din cauza biosdevname. Până acum, nu am reușit să reproduc problema când am folosit `biosdevname=0 net.ifnames=1`, care ar putea fi o opțiune pentru noi.
Puncte:0
drapel id

Răspunzând la propria mea întrebare aici. Se pare că problema a fost (parțial) autoprovocată.

Partea pe care nu o putem controla:

Folosind opțiunea de pornire biosdevname=1 are potențialul de a provoca curse în timpul fazei de redenumire a interfeței. Dacă poți trăi fără el, pur și simplu folosește net.ifnames=1 biosdevname=0 ar putea fi de preferat, chiar dacă numele rezultate sunt „mai puțin frumoase”.

Partea pe care o putem controla:

Site-ul nostru folosește un dracut modificat personalizat 40rețea modul. Unul dintre principalele lucruri pe care le face versiunea noastră este că verifică conținutul /sys/class/net/ caută interfețe viabile pe care să le adauge automat la o legătură. (nu știm întotdeauna în prealabil numele dispozitivelor, motiv pentru care modulul avea nevoie de ceva logică pentru a le identifica singur). Cursa menționată mai sus poate provoca o întârziere în redenumirea fișierelor în /sys/class/net/. Soluția a fost simplă: adăugați un somn de 5 secunde la script înainte de sondare /sys/class/net/. Asta da biosdevname (sperăm că mai mult decât suficient) timp pentru a termina redenumirea dispozitivelor. Testarea de până acum pare A-OK.

Michael Hampton avatar
drapel cz
Interesant. Ce nume obțineți cu `biosdevname=0`? Probabil a trecut un an de când am actualizat ultima cutie CentOS 7 pe care o aveam (la 8).
guzzijason avatar
drapel id
Cu `net.ifnames=1 biosdevname=1`, obținem nume precum "p3p1", "p3p2" (slot și port, destul de simplu). Cu `net.ifnames=1 biosdevname=0`, acele nume se schimbă în lucruri precum „enp193s0f0”, „enp193s0f1”.
Michael Hampton avatar
drapel cz
Ah, deci numele normale revin atunci când folosești `biosdevname=0`. Probabil cel mai bine să reveniți la asta, deoarece este ceea ce folosesc toți ceilalți. Aceste nume vechi au fost în mare parte abandonate cu ani în urmă.
guzzijason avatar
drapel id
Știu că moștenirea „eth0”, „eth1” numele au fost abandonate, din motive întemeiate. `biosdevname=1` este de fapt comportamentul implicit pe hardware-ul Dell, cu excepția cazului în care este dezactivat în mod explicit.
Michael Hampton avatar
drapel cz
Ne pare rău, am vrut să spun că numele Dell `biosdevname=1` au fost abandonate. Cu acest set la 0, numele dispozitivelor folosesc aceleași formate generale pentru toți furnizorii de hardware.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.