Puncte:3

Porniți corect un RAID1 bazat pe software cu o unitate lipsă sau eșuată incorect

drapel gf

tl;dr. Există o modalitate de a porni corect un RAID1 bazat pe software cu o unitate lipsă sau eșuată (care nu a fost eșuată mai întâi de utilizator)?

Pentru a fi clar, este posibilă pornirea unui RAID1 bazat pe software fără un hard disk DACĂ ați eșuat corect unitatea înainte de a reporni. Știu că acest lucru este subiectiv, dar nu pare a fi o soluție plauzibilă și nici un răspuns acceptabil. De exemplu; O instalație primește o lovire de energie și hard disk-ul se defectează în același timp în care se întrerupe curentul. Încercarea de a porni cu un hard disk degradat care nu a eșuat „în mod corespunzător” va duce la trecerea sistemului în modul de urgență.

Am citit multe postări de pe aici și de pe alte forumuri care recomandă să instalați grub pe toate partițiile sau să reconstruiți grub manual, adăugați nofail la /etc/fstab opțiuni, sau alte soluții aparent simple; dar realitatea este că niciuna dintre aceste recomandări nu a funcționat.

Deși am acceptat că acest lucru nu este posibil, ceva despre asta nu este ușor. Deci, văd dacă altcineva are această problemă sau are o soluție la această problemă.

Mediul meu:

Am o placă de bază mai veche care nu acceptă UEFI, așa că am modul vechi de pornire/MBR.
OS:

cat /etc/redhat-release
Red Hat Enterprise Linux Workstation versiunea 7.6 (Maipo)

Nucleu:

uname âr
3.10.0-957.el7.x86_64

mdadm:

mdadm âversiune
mdadm â v4.1-rc1 22-03-2018

RAID-ul meu este RAID1 pe trei unități. (sda,sdb,sdc) și există 4 partiții

md1 - /boot
md2 - /home
md3 - /
md4 - swap

Am instalat grub pe toate partițiile și m-am asigurat că toate partițiile de pornire au marcajul de pornire. fdisk /dev/sd[a,b,c] toate arată a * în câmpul de pornire de lângă partiția corespunzătoare
-- și --
grub2-install /dev/sd[a,b,c] (ca comenzi separate, cu rezultate âinstalate cu succesâ).

Replicarea problemei:

  1. Opriți sistemul cu toate unitățile atribuite RAID și RAID-ul complet operațional.
  2. Scoateți hard diskul
  3. Sistemul de alimentare este pornit

Rezultate: Sistemul va porni dincolo de grub. Gdm va încerca să afișeze ecranul de conectare, dar după aproximativ 20 de secunde, va eșua și va ajunge la o consolă de urgență. Există multe părți lipsă dintr-un sistem „normal”. De exemplu; /boot și /etc nu există. Nu pare să fie afișate mesaje sau probleme de panică ale nucleului dmesg.

Din nou, cheia aici este; RAID-ul trebuie să fie complet asamblat, oprit și scos o unitate. Dacă eșuați corect o unitate și o eliminați din RAID, atunci puteți porni fără unitate.

Exemplu:
mdadm --manage /dev/md[1,2,3,4] --fail /dev/sda[1,2,3,4] (ca comenzi separate)
mdadm --manage /dev/md[1,2,3,4] --remove /dev/sda[1,2,3,4] (ca comenzi separate)

Știu că acest lucru pare banal, dar încă nu am găsit o soluție viabilă pentru pornirea unui sistem cu un RAID1 degradat. Ai crede că aceasta ar trebui să fie o problemă simplă cu o soluție simplă, dar nu pare să fie cazul.

Orice ajutor, contribuție sau sugestie ar fi foarte apreciat.

Puncte:6
drapel ca

Pornirea unei matrice MD RAID1 eșuată este cu siguranță posibilă - cel puțin dacă BIOS-ul omite discul eșuat (dacă nu, puteți pur și simplu să porniți manual de pe discul de supraviețuire).

Pentru problema ta specifică, probabil că te lovești de asta gândac. Un extras (dar citirea tuturor rapoartelor de eroare ar fi o idee bună):

Scriptul dracut-iniqueue RHEL 7.6 are o valoare implicită de 180 de secunde (ca definită în variabila RDRETRY), care este mai mare decât rădăcina systemd service de montare (90 de secunde). Acest lucru poate duce la un sistem de nepornire când root se află pe un dispozitiv software RAID1 degradat (utilizatorul este trimis la carcasă de urgență). Vedea https://bugzilla.redhat.com/show_bug.cgi?id=1451660# pentru un exemplu de problema. Rețineți că acest lucru se întâmplă numai atunci când dispozitivul RAID se așteaptă în sine să fie sănătos, dar a găsit în mod neașteptat matricea degradată în timpul încărcării.

Trecerea „rd.retry=30” la momentul pornirii remediază încărcarea matricei degradată problemă, deoarece matricea este pornită forțat înainte de rădăcina systemctl service-ul de montare expiră. Mai mult, timpul de expirare lung dracut rd.retry este incompatibil cu pagina de manual dracut.cmdline(7), unde este menționat timeout-ul ar trebui să fie de 30 de secunde.

...

Informații suplimentare: am urmărit problemă la modul în care mdadm --incremental, dracut timeout (rd.retry) și timeout implicit systemctl interacționează:

  • mdadm --incremental nu va porni/rula o matrice care este găsită în mod neașteptat degradată;
  • dracut ar trebui să forțeze pornirea matricei după ce a trecut 2/3 din valoarea timeout. Cu valoarea implicită actuală a RHEL, aceasta se ridică la 180/3*2 = 120s;
  • systemctl se așteaptă să monteze sistemul de fișiere rădăcină în cel mult 90 de ani. Dacă nu reușește, anulează scriptul dracut și trece într-o situație de urgență coajă. Fiind cu 90 de secunde mai mic decât timeout-ul dracut, înseamnă că dracut are nu au șansa de a forța pornirea matricei. Scăderea rd.retry timeout (setarea așa cum sugerează pagina de manual) permite dracut să forțeze pornirea matrice, permițând serviciului systemctl să reușească.

Ca bug-ul ar trebui să fi remediat în versiunile recente RHEL/CentOS 7, vă sugerez insistent să vă actualizați sistemul dacă puteți. Altfel, încearcă să treci rd.retry=30 ca opțiune de pornire a nucleului.

Will Roberts avatar
drapel gf
shodanshok. Mulțumesc! Aceasta a fost exact problema și schimbarea setării md.raid forțează RAID-ul să se reconstruiască înainte de expirarea timpului și permite sistemului să pornească corect.

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.