Puncte:2

Cum să setați timeout pentru așteptarea lipsei HDD-ului în timp ce sistemul pornește?

drapel it

Sistem: Ubuntu 20.04 cu boot EFI.


Clarificare de ce am nevoie de asta

Am configurat două schimb partitii:

  • Un schimb principal pe al doilea HDD. Este folosit pentru hibernare. (Funcția de hibernare este mai bine de utilizat pe HDD pentru a prelungi durata de viață a SSD.)
  • A doua partiție de schimb pe SSD cu sistemul. Acesta este cazul dacă folosesc SSD ca un singur disc - când al doilea HDD este îndepărtat și lipsește. În acest caz, vreau doar ca sistemul să funcționeze normal - chiar și fără funcție de hibernare (sau cu una care folosește swap pe SSD).

Ce am facut:

  • S-a creat o partiție de schimb pe HDD.
  • Setați UUID-ul său ca reluare pentru Grub.

/etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT="Quiet Splash CV=UUID=25d5d4af-736a-4232-a4bb-492499bc1038"
  • Setați ambele partiții de swap la fstab cu prioritate pentru schimbul pe HDD și pe nofail și x-systemd.device-timeout=3s Opțiuni. Această opțiune pentru cazul în care HDD-ul lipsește. Fără aceste opțiuni și când HDD-ul lipsește, sistemul se blochează în timpul pornirii timp de 90 de secunde.

/etc/fstab config pentru partiții de swap:

#schimba pe HDD
UUID=25d5d4af-736a-4232-a4bb-492499bc1038 niciunul swap nofail,pri=20,x-systemd.device-timeout=3s 0 0
#swap pe SDD
UUID=e78a171a-3c52-4cd1-b86a-17709f4b49d9 nici unul swap pri=10 0 0

Ce problema am:

Când SSD și HDD sunt conectate împreună la laptop, totul este în regulă. Când HDD lipsește în timpul pornirii sistemului Grub încearcă să găsească partiția cu swap pe HDD și se blochează pentru aceasta timp de aproximativ 33 de secunde.

După ce sistemul a pornit în jurnalele, au apărut următoarele mesaje despre expirarea timpului de așteptare pentru HDD-ul lipsă (pe care l-am eliminat în mod intenționat) cu partiția de swap:

/var/log/boot.log:[ESC[0;1;31m TIME ESC[0m] Timp expirat în așteptarea dispozitivului ESC[0;1;39m/dev/disk/by-uuid/46e39f74-e1b3-4705-9bac -84ee2593b4d
4ESC[0m.

/var/log/syslog:Feb 23 14:23:26 Nucleul dispozitivului 2: [ 0.032426] Linia de comandă a kernelului: BOOT_IMAGE=/boot/vmlinuz-5.13.0-28-generic root=UUID=a59635ec-2cef-4396- bdf3-be7e4b23fc73 ro quiet splash resume=UUID=25d5d4af-736a-4232-a4bb-492499bc1038 vt.handoff=7

/var/log/syslog:Feb 23 14:56:14 Device-2 systemd[1]: dev-disk-by\x2duuid-25d5d4af\x2d736a\x2d4232\x2da4bb\x2d492499bc1038.device: Job de\v-dispozitiv: -25d5d4af\x2d736a\x2d4232\x2da4bb\x2d492499bc1038.device/start a expirat.

Ceea ce vreau:

Pentru a seta timeout pentru așteptarea lipsei HDD-ului nu mai mult de 5 secunde. Acum este setat implicit undeva în sistem pentru 30-33 de secunde.


Am încercat următoarele:

  • Pentru a găsi proprietatea timeout în Grub config. În /etc/default/grub pot fi specificate două opțiuni legate:
  • GRUB_HIDDEN_TIMEOUT
  • GRUB_RECORDFAIL_TIMEOUT

Dar nu sunt pentru acest caz. Informații despre aceste opțiuni pot fi găsite aici:

Am încercat să analizez codul pentru Grub în /etc/grub.d/ și am înțeles că un astfel de timeout probabil specificat în configurația de pornire a sistemului - în systemd. Am încercat să găsesc opțiunea de timeout corespunzătoare în systemd config:

sudo grep -iR timeout /etc/systemd/
/etc/systemd/system/rescue.target.wants/grub-initrd-fallback.service:TimeoutSec=0
/etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service:ExecStart=/usr/bin/nm-online -s -q --timeout=30
/etc/systemd/system/emergency.target.wants/grub-initrd-fallback.service:TimeoutSec=0
/etc/systemd/system/multi-user.target.wants/ua-reboot-cmds.service:TimeoutSec=0
/etc/systemd/system/multi-user.target.wants/unattended-upgrades.service:TimeoutStopSec=1800
/etc/systemd/system/multi-user.target.wants/grub-initrd-fallback.service:TimeoutSec=0
/etc/systemd/system/multi-user.target.wants/snapd.recovery-chooser-trigger.service:# blochează pornirea serviciului până când este detectat un declanșator sau se atinge un timeout
/etc/systemd/system/sleep.target.wants/grub-initrd-fallback.service:TimeoutSec=0
/etc/systemd/system.conf:#DefaultTimeoutStartSec=90s
/etc/systemd/system.conf:#DefaultTimeoutStopSec=90s
/etc/systemd/system.conf:#DefaultTimeoutAbortSec=
/etc/systemd/user.conf:#DefaultTimeoutStartSec=90s
/etc/systemd/user.conf:#DefaultTimeoutStopSec=90s
/etc/systemd/user.conf:#DefaultTimeoutAbortSec=
/etc/systemd/logind.conf:#HoldoffTimeoutSec=30s

Am încercat să schimb opțiunile cu o valoare de 30 de secunde la 5 secunde:

/etc/systemd/system/network-online.target.wants/NetworkManager-wait-online.service:ExecStart=/usr/bin/nm-online -s -q --timeout=5
/etc/systemd/logind.conf:#HoldoffTimeoutSec=5s

Dar acest lucru nu a dat rezultatul așteptat.

De asemenea, am încercat să setez la fel etichete pentru partițiile de schimb și pentru a specifica reluarea partiției de schimb după această etichetă (/dev/disk/by-label/...), nu prin UUID. Dar, în acest caz, nu există nicio determinare care partiție swap din ambele va fi folosită pentru a încărca sistemul din starea de hibernare.

Am gasit intrebarea similara: Cum să setați timeout pentru jobul de pornire systemd „dev-md125.device” (mdadm) Dar în el nu există detalii despre cum să configurați timeout în systemd pentru HDD.

Aici există un exemplu de setare TimeoutStartSec pentru httpd.service

Este posibil să specificați un astfel de timeout pentru montarea HDD-ului în timpul pornirii sistemului?

Mulțumiri.

drapel cn
Nu utilizați partiții, utilizați un fișier de swap și problema dvs. este inexistentă: puteți pune fie swap într-un director pe fiecare dintre discuri. „(Funcția de hibernare este mai bine de utilizat pe HDD pentru a prelungi durata de viață pentru SSD.)” Îndoială că va afecta durata de viață a unui SSD. SSD-ul meu durează mai mult decât notebook-ul meu de 10 ori și când primesc un notebook nou, primesc un SSD nou (mult mai rapid). Tot ce aveți nevoie este o copie de rezervă a datelor personale pe SSD.
drapel it
Nu am gândit în această direcție. Asta e interesant. Multumesc pentru idee! Am un SSD Toshiba destul de vechi - nu vreau să-l opresc de 3 ori pe zi hibernare)
drapel cn
Oh, atunci ar putea fi într-adevăr o problemă. Ssd-urile vechi aveau o mulțime de erori mici care stochează date. Aș putea sugera, de asemenea, că ar fi mai bine să nu hibernați dacă utilizați SSD-ul pentru a porni.Pornirea este atât de rapidă încât îmi opresc întotdeauna mașina (timpul de pornire va fi sub 15 secunde, cred că?).
drapel it
@Rinzwind, Da, de obicei, folosesc puterea oprită. Timpul de pornire este destul de rapid - este de aproximativ 20-30 de secunde. Dar hibernarea este uneori utilă - multe aplicații cu starea lor pot fi salvate în hibernare - și să aștept 1 minut în timp ce hibernarea sunt încărcate de pe HDD pentru mine nu este o problemă. În plus, dacă schimbul se află pe HDD, hibernarea va fi gratuită pentru SSD - vreau să spun că nu-l va răni (dar desigur că nu este atât de rapid ca pe SSD). Și setările de hibernare deschid, de asemenea, opțiunile `somn hibrid` și `sleep-then-hibernate` - acest lucru este, de asemenea, uneori util. Deci, cred că această configurație merită.
drapel it
@Rinzwind Am analizat abordarea cu fișierele de schimb și nu înțeleg cum pot ajuta în situația mea. În cazul fișierelor de schimb (de asemenea, ambele - pe HDD și SDD) trebuie să specific și partiția UUID a locației fișierelor de schimb în proprietatea `Grub2` `GRUB_CMDLINE_LINUX_DEFAULT` în format `resume=UUID= resume_offset=` sursa: [HOWTO: Utilizați fișierul de schimb în loc de partiție și hibernare](https://ubuntuforums.org/showthread.php?t=1042946) Și trebuie să existe aceeași problemă în timpul pornirii cu UUID-ul lipsă pe care se află fișierul de schimb. Ați putea vă rog să clarificați cum vă pot ajuta?

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.