Puncte:0

20.04.3 Eșec ISCSI în timpul pornirii pentru autentificare

drapel pk

Începând cu poate acum o lună am început să am erori iscsi și eșecuri la montare. Acest lucru a coincis aproximativ cu actualizarea din 20.04.3. Încercând să trec la urmărire, am emis următoarele comenzi:

root@cor8910:~# iscsiadm -m discovery -t sendtargets -p readynas2 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:thunderbird 172.16.7.2:3260,1 iqn.2011-09.nas-8B-3E-60:vmguests

root@cor8910:~# iscsiadm -m discovery -t sendtargets -p readynas1 172.16.0.2:3260,1 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5

Ieșirea de mai sus este corectă Cu toate acestea la emitere iscsiadm -m node -o arată că primesc 4 înregistrări ÎNCEPE RECORD 2.0-874

node.name = iqn.2011-09.nas-8B-3E-60:thunderbird . . . node.conn[0].adresă = 172.16.7.2 node.conn[0].port = 3260

#termină înregistrarea #Începe înregistrarea 2.0-874 node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . node.conn[0].adresă = readyNAS1 #ÎNREGISTRAREA FINALĂ Acesta este RĂU, deoarece adresa de conexiune este gataNAS2, nu 1 și ar trebui să fie zecimal punctat ÎNCEPE RECORD 2.0-874

node.name = iqn.2011-09.nas-8B-3E-60:vmguests . . . node.conn[0].adresă = 172.16.7.2< br/> node.conn[0].port = 3260

#ÎNREGISTRAREA FINALĂ Acesta este corect, dar de ce adresa este zecimală punctată și de ce a fost sinonimul gazdelor anterioare? ÎNCEPE RECORD 2.0-874

node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].adresă = 172.16.0.2 TERMINARE ÎNREGISTRARE ÎNCEPE RECORD 2.0-874

node.name = iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 ... node.conn[0].address = readynas1 #termină înregistrarea Ultimul e bine si el. Nu pot scăpa de acea înregistrare proastă a nodului Documentul pe care l-am căutat pe google indică un /var/lib/iscsi pe care Ubuntu nu îl are.

root@cor8910:~# ls -al /etc/iscsi/nodes/ total 20

drw------- 4 root root 4096 Oct 9 15:31 iqn.1994-11.com.netgear:readynas1:7f8962cc:ubuntu18.04.5 drw------- 3 root root 4096 Oct 9 15:31 iqn.2011-09.nas-8B-3E-60:thunderbird

drw------- 4 root root 4096 Oct 9 15:31 iqn.2011-09.nas-8B-3E-60:vmguests

Cred că problema ar fi putut fi în subfolderul implicit pe care l-am mutat într-un loc mai sigur. Cu toate acestea, folderul thunderbird încă nu este conectat și montat prin fstab. ceilalti fac. Odată pornit, pot emite un iscsiadm pentru a vă autentifica pe toate și pentru a monta manual lun-ul thunderbird acolo unde profilul Thunderbird indică către el.

Aș dori să pot corecta orice este greșit, dar în absența de a descoperi ce este în neregulă dacă aș șterge open-iscsi și l-am reinstalat, asta ar rezolva problema? Cum știe configurația în cazul unității ultra 4 NAS a lui „readyNAS2” Netgear să se refere la ea prin zecimală punctată, unde „readyNAS1” 214 NAS Netgear preia sinonimul fișierului gazdă pentru adresa sa?

După ce m-am gândit la argumentele pro/contra, am șters iscsiadm și l-am reinstalat. Acest lucru a funcționat de fapt bine, ținte statice au fost găsite și autentificarea s-a desfășurat rapid. Cu toate acestea, la repornire, după reinstalare, problema a reapărut și am descoperit că există ceva în pornire care creează incorect nodurile statice. Potrivit omului iscsiadm singurul tip de descoperire este sendtarget, isns. FĂRĂ STATIC, dar pare să se construiască și să se folosească și să eșueze.

guiverc avatar
drapel cn
Dacă acest lucru este legat de 20.04.3 și *probabil* kernel-ul HWE, așa cum sugerați (actualizare de la jumătatea lunii august 2021, deci mai mult decât acum *lună*; https://fridge.ubuntu.com/2021/08/27/ubuntu -20-04-3-lts-released/ *afișează data lansării ISO, dar aceasta este la mai mult de o săptămână după ce mașinile instalate au fost actualizate la acesta*), ați încercat să utilizați nucleul GA? Ubuntu are două opțiuni de stivă de kernel - GA, care rămâne stabilă pe durata lansării LTS, și HWE, care face upgrade la stive ulterioare în primii ~ doi ani ai produsului.
drapel pk
Nu sunt familiarizat cu activarea hardware. O să mă uit la asta mai atent mâine. De asemenea, nu sunt familiarizat cu alegerea între două versiuni ale nucleului. Prin asta, vrei să spui că nu aplici .3? Cu siguranță nu folosesc hardware nou. Această mașină are câțiva ani, Dell 8910. Am făcut upgrade la 64 GB și am adăugat unitatea NVM 1G. Această mașină este mult mai rapidă acum și nu a trebuit să dau încă 2500 USD la Dell. Vă rugăm să vedeți comentariul pe care l-am adăugat mai devreme la întrebarea AskUbuntu. Este în partea de jos. Si multumesc. https://answers.launchpad.net/ubuntu/+source/open-iscsi/+question/699043
drapel pk
Celălalt lucru este că am făcut upgrade doar când a sosit prin notificarea de actualizare a software-ului asincron, care pare să sosească mult după ce actualizările sunt disponibile.
guiverc avatar
drapel cn
Nu (nu are nimic de-a face cu .3; 20.04.2 și 20.04.3 folosind stiva GA vor folosi nucleul 5.4, 20.04.3 folosind HWE este 5.11 unde 20.04.2 folosind HWE a folosit 5.8). Mediul de instalare (ISO) utilizat are o alegere implicită pentru stiva de nucleu; unele vă permit chiar să vă selectați stiva în momentul instalării (de exemplu, ISO-uri care folosesc programul de instalare „subiquity”), consultați https://wiki.ubuntu.com/Kernel/LTSEnablementStack și like-uri paginile wiki, dar actualizarea .3 a fost la mijlocul lunii august odată cu schimbarea stivei HWE, diferența cheie, care determină o nouă reluare ISO cu stiva mai nouă instalată, upgrade-urile utilizatorilor existenți au primit o săptămână înainte de noul ISO)
drapel pk
Cu zeci de ani în urmă mi s-a spus, și am învățat pe calea grea, în upgrade-uri, deși atractiv, uneori funcționează grozav, uneori eșuează lamentabil. Acesta este ceea ce m-a determinat să pun depozitul de e-mail thunderbird într-un iscsi. Am încercat să-mi partajez 18.04.7? directorul principal cu 20.04. Încerc să nuanțez diferența dintre ceea ce descrieți și doar spuneți aplicației de actualizare/upgrade software (acesta este un mediu desktop) și pur și simplu am apăsat aplicația actualizare | butonul de upgrade și la sfârșit a spus că trebuie să repornească, așa că am făcut-o. Nu-mi amintesc nicio opțiune de selectare a nucleului. Este 5.11.0.37-generic.
guiverc avatar
drapel cn
ISO-urile care folosesc programul de instalare `ubiquity` sau `calamares` nu oferă o alegere pentru nucleu - ISO-ul însuși (de exemplu, ceea ce ați descărcat și ați scris pe suportul dvs. de instalare) controlează însuși această alegere (de exemplu, dvs. decideți la momentul descărcării dacă utilizați un ISO). folosind acei instalatori).
drapel pk
Oh, stai, te-ai referit la fiecare 2 ani LTS vs, în acest caz actual, 20.10, 21.4, 21.10? Am o dimineață devreme și trebuie să mă culc acum... agn mulțumesc! Lasă-mă să cercetez asta când mă întorc mâine.
guiverc avatar
drapel cn
Nu, Ubuntu 20.04, 20.04.1, 20.04.2, 20.04.3, care sunt disponibile pentru desktop, server, *flavors* și multe altele. de exemplu. https://releases.ubuntu.com/20.04/ etc sunt oferite diverse ISO-uri pentru fiecare lansare; majoritatea utilizatorilor iau doar valoarea implicită - dar ISO-uri alternative sunt disponibile. Pentru *arome* (cum ar fi Lubuntu), mediile 20.04 și 20.04.1 au fost implicit la nucleul GA, 20.04.2 și mai târziu sunt implicite la HWE; Ubuntu Desktop 20.04 LTS ISO implicit folosește HWE pentru toți, Ubuntu Server 20.04 LTS este implicit GA pentru toți.
drapel pk
Am ajuns din urmă. Pe această imagine de boot, unitatea nvme, am făcut o instalare nativă. Sunt destul de sigur că totul era bine atunci. Problema a apărut după sau aproximativ când s-a actualizat la 20.04.3. Mașina pornește bine fără iscsi, așa cum a făcut inițial pe nvme. Cred că problema nucleului este interesantă, dar nu problema aici, deoarece versiunea desktop a fost actualizată la 20.04.3. Când am instalat de pe USB, nu-mi amintesc să fi fost întrebat ce nucleu. Cred că problema este în iscsid, în generarea subdir-ului iscsi sub /etc/ specific static.
Puncte:0
drapel pk

Aparent, open-iscsi este foarte sensibil la ce comenzi sunt emise și în ce ordine sunt emise. Cheia pentru a înțelege acest lucru este obținerea unui mediu „virgin” pentru testare. Am creat un VM cu cel mai recent 20.04.3 iso și am continuat pentru a configura open-iscsi. Deoarece nu am avut o redefinită /etc/hosts fișier în VM nu existau sinonime pentru adrese zecimale punctate. Cred că asta poate fi o parte a problemei.

Am încercat fără rezultat secvența de comenzi descrisă mai sus. Nu a eșuat, nici nu a încercat. M-am întâmplat apoi pe această adresă URL. Este important să o citiți încet și cu atenție și să o urmați cu meticulozitate. https://www.hiroom2.com/2018/05/05/ubuntu-1804-open-iscsi-en/ În timp ce acesta a fost scris pentru 18.04, a funcționat perfect în VM. Am reprodus acele rezultate pe desktopul meu de „producție” cu rezultate identice.

Acordați o atenție deosebită în secvența de instrucțiuni la

Dacă v-ați conectat la ținta iSCSI înainte de a schimba node.startup în automat, trebuie să vă conectați din nou la ținta iSCSI după ce ați schimbat node.startup în automat.

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.