Linux rendszerindítási problémák és hardverhibák diagnosztizálása

Informatec Digital » Források » Linux rendszerindítási problémák és hardverhibák diagnosztizálása

Amikor egy Linux rendszer nem indul el, vagy szabálytalanul kezd viselkedni, a természetes reakció az, hogy azt gondoljuk, hogy „a Linux elromlott”. A gyakorlatban azonban a legtöbb esetben a mögöttes problémák konfigurációs hibák, megtelt lemezek, fájlrendszer-sérülések vagy hardverproblémák, amelyek egy kis módszertannal beazonosíthatók. A cikk célja pontosan ez: egy világos, konkrét parancsokkal támogatott eljárás bemutatása a Linux leggyakoribb rendszerindítási és hardverproblémáinak diagnosztizálására és javítására, mind fizikai, mind virtuális gépeken.

Ha olyan üzeneteket kapsz, mint a „root fájlrendszer nem található”, „Nincs szabad hely az eszközön”, „EXT4-fs hiba”, „XFS: Metadata CRC hiba” vagy a rettegett kernelpánik , itt megtudhatod, hogyan értelmezd ezeket, mely parancsokat használd, és milyen sorrendben cselekedj. Azt is megnézzük, hogyan állapítható meg, hogyan állapítható meg, hogy a probléma valóban szoftveres-e, vagy a hardver (RAM, SSD/HDD, hálózati kártya stb.) van-e a végét járva, és hogyan minimalizálható az adatvesztés kockázata a hibaelhárítás során.

A Linux rendszerindítási problémák tipikus okai

Mielőtt elkezdenél összevissza babrálni a dolgokkal, érdemes megérteni a leggyakoribb okokat, amiért a Linux nem indul el, vagy helytelenül indul el . A kiváltó ok megértése órákig tartó hibakeresést és sehová sem vezető megoldások kipróbálását takarítja meg.

Az első problémacsoport a rendszerindító kezelőből és a BIOS/UEFI konfigurációból ered : helytelenül generált GRUB bejegyzések, felülírt MBR a Windows kettős rendszerindítású telepítése után , a Secure Boot inkompatibilis a disztribúcióval, vagy a BIOS rossz lemezről próbál bootolni. Ezekben az esetekben gyakran nem is látod a GRUB menüt, vagy amikor kiválasztod a Linux disztribúciót, az lefagy, vagy visszatér a firmware-hez.

Egy másik fontos blokk a következőhöz kapcsolódik: lemez- és fájlrendszerSérült partíciók, hibás szektorok, EXT4 vagy XFS sérülés, megtelt rendszerlemezek vagy LVM hibák. Ezek általában üzenetek formájában jelentkeznek a rendszerindítás során, például: „Nem sikerült felcsatolni /…","EXT4-fs hiba","XFS: Lecsatolás és az xfs_repair futtatása"vagy akár vészhelyzeti üzemmódba kapcsolva kérik a végrehajtást journalctl -xb.

A problémák gyakoriak egy kernelfrissítés vagy egy rosszul telepített javítás után is . A hiányos letöltések, a be nem töltött modulok, a hardverrel már nem kompatibilis illesztőprogramok vagy az initramfs módosításai a rendszer lefagyását okozhatják a rendszerindítás közben, vagy kernelpánikot válthatnak ki indításkor.

Nem szabad megfeledkeznünk a rendszer konfigurációjáról sem: a túl szigorú biztonságos rendszerindítási szabályok (például az auditd HALT-tal konfigurálva, amikor a /var/log/audit megtelt), a helyhiány miatt meghibásodó kritikus szolgáltatások, vagy a konfigurációs fájlokban bekövetkező változások, amelyek megakadályozzák a létfontosságú démonok elindulását (network, systemd, cloud-init felhőkben, mint például az Azure stb.).

Végül pedig ott van a hardverréteg: piros SMART-jelzőkkel ellátott lemezek, ECC-hibákkal rendelkező RAM-ok, csomagokat veszítő hálózati kártyák vagy túlmelegedő SSD-k . A nyom gyakran a kernelüzenetekben (dmesg) vagy a SMART és EDAC számlálókban rejlik, ezért meglátjuk, hogyan kell ezeket figyelmesen elolvasni.

Hogyan lehet azonosítani az indítási hiba forrását?

A vakindítások elkerülésének kulcsa a részletes rendszerindítási mód engedélyezése és a naplók áttekintése . Alapértelmezés szerint sok disztribúció egy szép kezdőképernyőt jelenít meg, amely elrejti az üzeneteket, ami jól néz ki, de nem segít, ha valami rosszul sül el.

GRUB-ot használó rendszereken a csendes módot a /etc/default/grub fájl szerkesztésével tilthatja le . Keresse a következő sort:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

és cserélje ki erre:

GRUB_CMDLINE_LINUX_DEFAULT=""

Ezután futtassa az `update-grub` parancsot (vagy a disztribúciójában található azzal egyenértékű parancsot) a konfiguráció újragenerálásához. A következő rendszerindításkor az összes kernel és systemd üzenet megjelenik, így pontosan meghatározhatja a rendszer összeomlását okozó hibát.

Ha a rendszer részlegesen indul, vagy élő környezetből elérhető, akkor számos kulcsnapló érhető el a /var/log fájlban :

• /var/log/boot.log: mindent rögzít, ami az indítási fázisban történik; ha a hiba ebben a szakaszban van, akkor ezt kell először keresni.
• / var / log / messages o / Var / log / syslog (disztribúciótól függően): általános rendszeresemények, nagyon hasznosak a szolgáltatásokban, démonokban stb. fellépő hibák megtekintéséhez.
• dmesg: megjeleníti a kernel üzeneteit, beleértve a hardverhibákat, modulproblémákat, buszhibákat, PCI hibákat stb.
• JournalctlA systemd-t használó rendszerekben ez az elsődleges eszköz a teljes rendszerleíró adatbázis bejárására; journalctl -xb Látod a végső kezdetet teljes pompájában.

Ha a rendszer nem éri el az asztali képernyőt, de TTY vagy helyreállítási módba vált, akkor közvetlenül onnan futtathatod a `journalctl -xb` parancsot . Ha ez nem működik, akkor élő USB-ről kell indítanod a rendszert, csatolnod kell a rendszerlemezt, és a fájlokat az élő környezetből kell beolvasnod.

Ellenőrizze, hogy a probléma hardverrel vagy szoftverrel kapcsolatos-e

Mielőtt elkezdenéd a fejedben a konfigurációk szerkesztését, érdemes ellenőrizni, hogy a probléma nem közvetlenül a hardverrel van-e - lemezzel, memóriával, CPU-val, alaplappal vagy tápegységgel . Sok "véletlenszerűen" megsérülő telepítés valójában egy hibás SSD-re vagy RAM-ra utal.

Az első lépés, ha a számítógép nem is ismeri fel a meghajtót, a BIOS/UEFI megnyitása és a meghajtó listájának ellenőrzése. Ha a meghajtó egyáltalán nem jelenik meg, vagy csak időszakosan jelenik meg, ellenőrizze a csatlakozásokat, a SATA kábeleket és a tápegységet, vagy feltételezze, hogy a meghajtót esetleg újra kell hasznosítani.

Ha eléred a GRUB-ot vagy egy Live Boot-ot, a GRUB menüjéből elindíthatod a MemTest86+-t a RAM ellenőrzéséhez. Hagyd legalább nyolc meneten át futni; ha piros vonalakat látsz, a memória hibás , és a modulokat ki kell cserélni. A hibás RAM az adatvesztés melegágya.

A lemezek állapotának ellenőrzéséhez Linuxban használd a smartmontools programot . A telepítés után engedélyezd a SMART-ot, és tekintsd át a legfontosabb attribútumokat:

• Áthelyezett_Szektor_Ct: az áthelyezett szektorok száma; ha nagyobb, mint 0, akkor a lemezen már elkezdtek megjelenni a hibás szektorok.
• Jelenlegi_Függőben_Szektor_Ct: áthelyezésre váró szektorok; a 0-nál nagyobb érték a közvetlen meghibásodás magas kockázatát jelzi.
• Bekapcsolási_órák: összesített használati órák száma; minél nagyobb a szám, annál nagyobb a lemez meghibásodásának valószínűsége.

A `smartctl -H /dev/sdX` paranccsal gyorsan ellenőrizheted, hogy a lemez megfelelt-e az állapotteszten vagy sem. Ha az eredmény nem SIKERES, a lehető leghamarabb biztonsági másolatot kell készítened az adataidról, és el kell gondolkodnod a cseréjükön.

Ha magas hőmérsékletre gyanakszik, telepítse lm-érzékelők és futni sensors (o watch -n 2 sensors (valós idejű megtekintéshez). SSD és SATA meghajtók esetén hddtemp Megmutatja az aktuális hőmérsékletet, így észlelheti a hőmérséklet-emelkedést tétlenség közben is, ami hasznos... szerver optimalizálás.

Speciális hardverdiagnosztika Linuxban

A CPU, RAM és lemezterület mellett a Linux speciális eszközökkel rendelkezik az ECC memória, a hálózati kártyák, a GPU-k és más komponensek kiértékeléséhez . Ha néhány percet szán ezeknek a pontoknak az ellenőrzésére, sok órányi hibakeresést takaríthat meg.

Ha a szervered vagy munkaállomásod ECC memóriával rendelkezik , a kernel jellemzően EDAC segítségével naplózza a javított és nem javított hibákat. Egy egyszerű:

dmesg | grep EDAC

Lehetővé teszi, hogy lássa, vannak-e CE (javított hibák) vagy UE (javítatlan hibák) . A CE-k azt jelzik, hogy a RAM-ban hibák voltak, de a hardver képes volt kijavítani azokat; célszerű figyelni ezeket a modulokat, mert általában csak idő kérdése, hogy mikor válnak javíthatatlan hibákká. Az UE-k gyakran kernelpánikkal végződnek, hogy megakadályozzák a súlyos adatsérülést.

A memória szerkezetének és kapacitásának ellenőrzéséhez a `dmidecode -t memory` parancs megmutatja a modulok típusát (DDR3, DDR4, DDR5), kapacitását, a foglalt memóriaegységeket és egyebeket. A `dmidecode -t 16` paranccsal pedig megtekintheted az alaplap által támogatott maximális RAM-kapacitást, ami hasznos lehet, ha bővítésen gondolkodsz.

A hőmérséklet és a vizuális monitorozás területén az érzékelők és a HDD Temp adatait grafikus eszközökkel, például a psensor vagy az xsensors segítségével lehet támogatni , amelyek az időbeli hőmérséklet-ábrázolást mutatják, hogy észleljék a szokatlan hőmérséklet-csúcsokat vagy az állandóan a hőmérsékleti határon lévő berendezéseket.

Lemezek és USB-meghajtók diagnosztizálásához az eszközök listázásához az lsblk és az fdisk -l parancsok mellett nagyon hasznos a következők kombinálása:

• df-h y df -i: a tárhely és az inode-ok kihasználtságának százalékos aránya; lehet, hogy gigabájtnyi szabad tárhely van, de az inode-ok 100%-a foglalt, a rendszer akkor is panaszkodni fog a „nincs hely” hibára.
• fsck /dev/sdXN -y: logikai hibákat keres és javít a fájlrendszerekben (többek között EXT2/3/4).
• rossz blokkok /dev/my_disk: hibás szektorokat keres, és megjelöli azokat, hogy a rendszer ne használja őket (ennek megtétele előtt erősen ajánlott biztonsági mentést készíteni).

Hálózati kártya esetén a tipikus tünetek közé tartoznak a lekapcsolódások, a késleltetés vagy a megmagyarázhatatlan csomagvesztés. Az ethtool segítségével megtekintheti a statisztikákat, a netstat segítségével pedig a csomagvesztési arányokat (RX-DRP és TX-DRP). Ha a csomagvesztés százalékos aránya meghaladja a körülbelül 0,2%-ot , az egyértelműen befolyásolja a hálózati teljesítményt, és a hálózati kártya hibás lehet, vagy a meghajtóprogram nem megfelelően támogatja.

Megtelt lemez és szabad hely hibák: a klasszikus „Nincs szabad hely az eszközön” hiba

Sok gépen (különösen szervereken és virtuális gépeken ) az egyik leggyakoribb probléma, hogy a rendszerlemez teljesen megtelik. Amikor ez megtörténik, szolgáltatások, naplók, rendszerindítási folyamatok, sőt maga a kernel is I/O hibákat kezd dobni.

Az olyan környezetekben, mint az Azure, gyakran látunk ilyen üzeneteket a konzolon vagy az indítási diagnosztikában:

• Nincs több szabad hely az eszközön a cloud-initben, ami megakadályozhatja, hogy a virtuális gép befejezze a rendszerindítást.
• Ismétlődő üzenetek innen: „Nincs több hely a készüléken” amelyek kritikus szolgáltatásokat érintenek, beleértve a felhőügynököt is.
• Hibák a rendszernaplókban, amelyek azt jelzik, hogy az audit- vagy hálózati naplók nem írhatók.

A terület elfoglalásának gyors megtalálásához az alábbi parancsokat használhatja:

• du -ks /* | rendezés -n: méret szerint rendezve listázza a gyökérkönyvtárakat; a legnehezebbeken belül ismétlődik, amíg meg nem találják az igazi bűnöst.
• ls -altSr /var/log: a naplófájlokat méret szerint rendezve jeleníti meg, a legkisebbtől a legnagyobbig; gyakran láthat hatalmas régi naplókat, amelyek elforgathatók vagy törölhetők.
• find / -size +500M -exec ls -alFh {} \;: nagyméretű, egyedi fájlok keresése; szükség szerint módosítsa az 500 MB-ot.

A /var/log vagy /tmp tipikus feltöltése mellett vannak biztonsági konfigurációk, mint például auditd ami a gép leállását vagy beindulásának meghiúsulását okozhatja, amikor elfogy a hely a /var/log/audit fájlban. Ha be /etc/audit/auditd.conf neked van:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

A rendszer szabályozott módon leállhat, vagy megtagadhatja a rendszerindítást, ha nem tud írni az auditnaplókba. Ideiglenes megoldás lehet ezen értékek SUSPEND, IGNORE vagy más érvényes értékre váltása (ebben az összefüggésben soha ne SINGLE), hogy a rendszer elindulhasson és helyet szabadítson fel . A probléma megoldása után vissza kell térni az eredeti szabályzathoz, ha a megfelelőség szükséges.

Ha nincs mód a dolgok törlésére, mert a rendszer szó szerint nem indul el, akkor a mentési módokhoz folyamodhatsz : automatikus felhőjavító parancsokhoz (pl. az vm repair az Azure-ban), helyreállítási virtuális gépekhez, vagy egyfelhasználós módhoz, amellyel csatlakoztathatod a lemezt és törölheted a felesleges fájlokat, amíg legalább 10% szabad hely nem lesz a /var/log könyvtárat és a többi kritikus könyvtárat tartalmazó fájlrendszerben.

Sérült EXT4 és XFS: Hogyan javítsuk ki a sérült fájlrendszereket

Ha indításkor olyan dolgokat látsz, mint az „EXT4-fs error (device sda1)” , „bad extra_isize” , „no journal found” vagy XFS üzeneteket, mint például a „Metadata CRC error detected… Unmount and run xfs_repair” , akkor nem egyszeri problémával van dolgod: a fájlrendszer sérült, és amíg nem javítod ki, a gép nem fog normálisan elindulni.

Az első lépés annak azonosítása, hogy melyik eszközt érinti a probléma . A rendszerindítási naplókban nézd meg a kernel üzeneteiben zárójelben megjelenő szöveget: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname stb. Ez megmutatja, hogy közvetlen partícióról (sdXN) vagy LVM logikai kötetről (dm-N, /dev/vgname/lvname) van-e szó.

Miután hozzáférsz egy shellhez (vészhelyzeti mód, egyfelhasználós vagy mentőgép), futtasd az `lsblk -f` parancsot a teljes struktúra megtekintéséhez: lemezek, partíciók, LVM és fájlrendszer típusok. Nagyon fontos itt megerősíteni, hogy a partíció valóban ext4, xfs, vfat, LVM2_member stb. típusú-e, és ne kizárólag az `/etc/fstab` fájlra hagyatkozz, ha gyanítod, hogy rosszul van konfigurálva.

Az EXT4 fájlrendszerek javításához az fsck parancsot használjuk . Általános szabályként:

• Győződjön meg arról, hogy a fájlrendszer szereletlen (ha adatlemezről van szó), vagy hogy egy olyan mentési környezetből dolgozik, ahol nincs használatban.
• Lándzsa fsck /dev/sdXN o fsck /dev/vgname/lvnameMeg fogja kérdezni, hogy kijavítani szeretnéd-e az inkonzisztenciákat, újra létrehozni az átméretező inode-ot, beállítani a blokkszámlálókat stb.
• Ha sok kérdés jelenik meg, szakítsa meg a folyamatot a CTRL+C billentyűkombinációval, majd futtassa újra a fsck -y így automatikusan „igen”-nel válaszol; így nem maradsz le semmiről.
• Ha fájlokat helyez át ide elveszett+találtKésőbb ellenőrizned kell őket, és vissza kell tenned a helyükre.
• Futtassa újra az fsck parancsot, amíg a kimenet azt nem jelzi, hogy a fájlrendszer ragadozó ölyv.

Az XFS esetében az eszköz az xfs_repair . A tipikus munkafolyamat itt a következő:

• Először is, egy kis ellenőrzés: xfs_repair -n /dev/vgname/homelv hogy bármi módosítása nélkül lássuk, milyen kár keletkezett.
• Ha az elemzés elfogadható, ismételd meg a -n kapcsoló nélkül, hogy megpróbálhassa kijavítani: xfs_repair /dev/vgname/homelv.
• Ha a parancs azt írja ki, hogy a fájlrendszerben „értékes metaadat-változások vannak egy naplóban, amelyeket reprodukálni kell”, próbálja meg csatolni: XFS rendszereken számos függőben lévő változás pontosan a csatoláskor érvényesül. Ha mentő virtuális gépen van, ezt egy olyan ponton teheti meg, mint a /recovery.
• Ha nincs más megoldás, és a naplóhibák nincsenek kijavítva, akkor az utolsó megoldás a használata xfs_javítás -L A napló elvetése és az összeszerelés kikényszerítése úgy, mintha minden módosítás alkalmazásra került volna. Ez a legutóbbi adatok elvesztéséhez vezethet, ezért ezt csak végső megoldásként tegye.

Minden esetben fontos megérteni, hogy az fsck és az xfs_repair nem varázslatos : kijavítják a fájlrendszer struktúráját, de nem mindig tudják helyreállítani az összes adatot. Ezért olyan fontos, hogy rendelkezzünk korábbi biztonsági mentésekkel, és ha a felhőben vagy virtuális gépen vagyunk, akkor egy lemezpillanatképből vagy egy mentőgéphez csatolt másolatból dolgozzunk .

GRUB, UEFI, Secure Boot és más rendszerindítási klasszikusok

Amikor bekapcsolod a számítógépet, és még a GRUB menüt sem látod, vagy a BIOS/UEFI olyan hibákat dob, mint a "Nem sikerült megnyitni az \EFI\ubuntu\grubx64.efi fájlt - Nem található" , és egy ciklusba kerül, miközben megpróbál erről a bejegyzésről indítani, a probléma szinte biztosan a rendszerindító-kezelőben vagy a firmware-konfigurációban van.

Ezek a hibák akkor fordulhatnak elő, ha a Windowst kettős rendszerindítású konfigurációban telepítették (ami gyakran átveszi az MBR-t vagy felülírja az UEFI bejegyzéseket), véletlenül töröltek egy EFI partíciót, vagy a BIOS rendszerindítási sorrendjének megváltoztatása után. A modern laptopokon nem ritka, hogy a gép ciklusban újraindul, ha az „ubuntu” UEFI bejegyzés egy már nem létező fájlra mutat, és megpróbálja betölteni azt.

A hibás GRUB rendszerbetöltő javításának legegyszerűbb módja, ha egy Live disztribúcióból (például Ubuntuból) indítjuk a rendszert , és a Boot-Repair eszközt használjuk . A tipikus eljárás a következő:

• Kezdje egy USB Élő és nyisson meg egy terminált.
• Add hozzá a repository-t és frissítsd: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• Telepítse az eszközt: sudo apt install -y boot-repair.
• Futtassa a következővel: boot-repair és válassza ki a lehetőséget „Ajánlott javítás”.

A Boot-Repair elemzi a partíciókat, megkeresi a telepített rendszereket, újrakonfigurálja a GRUB-ot, újragenerálja a konfigurációs fájlt, és szükség esetén módosítja az UEFI bejegyzéseket, hogy a számítógép a megfelelő rendszerindító-kezelőből induljon el.

Az UEFI, a Secure Boot és a Fast Boot engedélyezve lévő rendszereken számos inkompatibilitási problémára érdemes odafigyelni. Nem minden disztribúció támogatja megfelelően a Secure Bootot, és néhány régebbi hardverekre tervezett disztribúció sem működik jól az UEFI-vel. Ha a disztribúció nincs aláírva, vagy a rendszerindító shim nem kompatibilis, az UEFI megtagadhatja a kernel betöltését.

Ezekben az esetekben a megoldás általában az UEFI-beállítások elérését, a Legacy/CSM mód engedélyezését a klasszikus BIOS-stílusú rendszerindításhoz, és a Secure Boot letiltását jelenti . Ha azonban Windows 11-et is használsz azon a számítógépen, vagy Windowsról Linuxra szeretnél migrálni , a Secure Boot letiltása megsértheti a Windows rendszerindítási követelményeit, ezért érdemes megfontolni, hogy melyik rendszer élvez prioritást, vagy keress egy Secure Boot-tal kompatibilis Linux disztribúciót, hogy elkerüld a BIOS minden egyes megnyitását.

A Windows gyorsindítása kettős rendszerindítás esetén is problémákat okoz. Ha a gyorsindítás engedélyezve van, a Windows nem kapcsol ki teljesen: a kernel egy részét hibernált állapotban hagyja a lemezen, blokkolva a teljes hozzáférést az NTFS fájlrendszerhez. Amikor a Linux megpróbálja csatlakoztatni ezeket a partíciókat, hibák léphetnek fel, vagy a rendszer akár le is fagyhat. Javasoljuk, hogy tiltsa le a gyorsindítást mind a Windows energiagazdálkodási beállításaiban , mind pedig, ha az UEFI engedélyezi, magában a BIOS-ban.

Helyreállítási módok és beépített javítóeszközök használata

Ha a GRUB megjelenik, de a Linux rendszer nem indul el, vagy ha gyanítja, hogy egy csomag befejezetlen maradt, vagy a rendszer megsérült egy frissítés után, kihasználhatja a GRUB speciális beállításait és a legtöbb disztribúcióban található helyreállítási módokat.

A GRUB menüjében általában van egy „ Speciális beállítások ” vagy hasonló nevű bejegyzés. Belül általában az összes elérhető kernel verziót látod, és mindegyikhez egy helyreállítási módot . Válaszd ki a legújabb verzió helyreállítási módját (és ha az sem sikerül, próbáld ki az előzőt).

A helyreállítási mód egy nagyon hasznos segédprogramokat tartalmazó menüt jelenít meg a következőkhöz:

• fsck: Ellenőrizze és javítsa ki a fájlrendszert (hasonlóan a Windows chkdsk parancsához).
• ragadozó ölyv: szabadítson fel helyet ideiglenes fájlok és egyéb maradék fájlok törlésével.
• dpkg: hibás csomagok, nem teljesített függőségek vagy elakadt telepítések javítása.
• grub: a rendszerindító-kezelő konfigurációjának újragenerálása.

Ezen beállítások sorrendben történő futtatása általában megold számos olyan problémát, amelyet a frissítések során fellépő áramkimaradások, a sérült csomagok vagy a megtelni készülő lemezek okoznak . Utána a rendszer általában felajánlja az újraindítást, hogy ellenőrizze, a rendszerindítási folyamat visszatért-e a normális kerékvágásba.

Az olyan felhőkben, mint az Azure , a vészhelyzeti és az egyfelhasználós módok mellett olyan speciális eszközök is rendelkezésre állnak, mint az Azure Linux Automatic Repair (ALAR) és az az vm repair parancs , amelyek automatizálják a folyamat egy részét: csatlakoztatják a rendszerlemezt egy mentő virtuális géphez, olyan műveleteket futtatnak, mint az „auditd”, a tipikus konfigurációk javításához, és lehetővé teszik a könnyű visszaállítást, ha valami hiba történik.

Stratégiák a Linux adatvesztés nélküli újratelepítéséhez

Vannak olyan helyzetek, amikor bármennyire is utánajársz, a rendszer annyira sérült, vagy a hardvered annyira szokatlan (mint például a HP N150 vagy a modern laptopok egzotikus vezérlőkkel), hogy a legésszerűbb dolog a disztró újratelepítése . Ez azonban nem feltétlenül jelenti azt, hogy elveszíted az összes adatodat.

Sok disztribúció, mint például az Ubuntu és származékai, telepítés közben kínálnak egy „az operációs rendszer újratelepítése a dokumentumok és beállítások megőrzése mellett ” nevű opciót. Ez újratelepíti az alaprendszert, de megpróbálja megőrizni a /home könyvtárat, és néha még néhány telepített alkalmazást is. Ez egy kényelmes lehetőség, bár nem bolondbiztos, ezért tanácsos manuálisan biztonsági másolatot készíteni mindenről, amit nem szeretne elveszíteni.

A jövőbeli újratelepítések elleni védelem legmegbízhatóbb módja, ha a lemezt több különálló partícióra rendezi :

• Egy a / (gyökér): alaprendszer.
• Egy másik azért /csomagtartó (és a /boot/efi fájlt az UEFI-ben), ha nagyobb kontrollt szeretnél a rendszerindítás felett.
• Exkluzív részleg a következők számára: / home vagy adatokért.

Így, ha a Linux rendszered használhatatlanná válik, csak a rendszer- és a rendszerindító partíciókat formázhatod, az adatpartíciót érintetlenül hagyva . Még ha csak egy partíciód van mindenhez, akkor is indíthatsz egy élő környezetből, csatolhatod a lemezt, dokumentumokat másolhatsz egy külső meghajtóra vagy a felhőbe, majd ha minden biztonságban van, tiszta telepítést végezhetsz.

Virtuális gépekben, legyenek azok VirtualBoxból, VMware-ből vagy felhőből származóak, érdemes az adatlemezeket is elkülöníteni a rendszerlemeztől . Az Azure-ban például ajánlott, hogy az LVM adatkötetek ne legyenek keverve ugyanabban a kötetcsoportban, mint a rendszerlemez, hogy megakadályozzuk, hogy az operációs rendszer meghibásodása az adatokat is befolyásolja.

Bevált gyakorlatok a problémák megismétlődésének megelőzésére

Miután megoldottad a rendszerindítási problémákat és helyreállítottad a rendszeredet (vagy legalábbis az adataidat), az okos dolog, ha teszel néhány lépést, hogy legközelebb kevésbé súlyos legyen a probléma, vagy teljesen megelőzd.

Az első, hogy a rendszert és a szoftvereket naprakészen tartsd , de ezt okosan tedd. A gördülő kiadású disztribúciókban, mint például az Arch, a gyakori frissítések elengedhetetlenek; a konzervatívabb disztribúciókban (Debian Stable, Ubuntu LTS) kicsit el lehet tolni őket, de nem ajánlott évekig érintetlenül hagyni őket. Jelentős kernel- vagy verzióváltozások előtt mindig készíts egy megfelelő biztonsági mentést.

Egy másik nagyon egészséges szokás, dokumentálja a nagyobb konfigurációs változtatásokat: melyik fájlt érintetted meg, melyik sort változtattad meg, és milyen volt előtte. Egy egyszerű trükk, hogy mindig az eredeti fájl másolatát mentsd el a következő utótaggal. .mögött (például sshd_config.bak), így könnyen visszaállíthatod, ha elrontod.

Az adatok tekintetében elengedhetetlen a rendszeres biztonsági mentés . Az rsync segítségével növekményes biztonsági mentéseket készíthetsz, a tar segítségével teljes könyvtárakat csomagolhatsz be, illetve felhő- és NAS-megoldásokat is használhatsz. Továbbá, ha az adataid egy másik partíción vannak, mint a rendszerpartíció, akkor is gond nélkül újratelepítheted őket, ha a lemez nem indul el.

Végül, mindig jó ötlet rendszeresen figyelni a rendszer állapotát: havonta ellenőrizd a SMART-ot, figyeld az inode-okat és a szabad területet a kritikus partíciókon (/, /var, /home), nézd meg a naplókat ismétlődő üzenetek után, és tartsd alacsonyan a hőmérsékletet és a porszintet a fizikai berendezéseken. Egy egyszerű karbantartási rutin sok kora reggeltől megkíméli a "hirtelen" leállt gépek javítását.

Ezzel a technikákból, parancsokból és bevált gyakorlatokból álló arzenállal a Linux rendszerindítási problémák és hardverhibák diagnosztizálása és javítása már nem a bizalom kérdése, hanem egy meglehetősen ésszerű folyamattá válik: először azonosítjuk, hogy a hiba oka a lemez, a fájlrendszer, a GRUB, a kernel, a konfiguráció vagy a hardver; majd alkalmazzuk a megfelelő eszközt (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, helyreállítási módok stb.); és a legrosszabb esetben már van egy jól szervezett B tervenk külön partíciókkal és biztonsági mentésekkel, amelyek lehetővé teszik az újratelepítést a világvége nélkül.