Diagnozowanie problemów z uruchamianiem systemu Linux i awarii sprzętu

Informatec Digital » Zasoby » Diagnozowanie problemów z uruchamianiem systemu Linux i awarii sprzętu

Gdy system Linux nie uruchamia się lub zaczyna zachowywać się nieprawidłowo, naturalną reakcją jest myśl, że „Linux jest zepsuty”. W praktyce jednak najczęściej przyczyną są błędy konfiguracji, zapełnione dyski, uszkodzenia systemu plików lub problemy sprzętowe , które można zlokalizować za pomocą prostej metodyki. Celem tego artykułu jest właśnie to: zaprezentowanie przejrzystej procedury, wspieranej przez konkretne polecenia, służącej do diagnozowania i naprawiania najczęstszych problemów z rozruchem i sprzętem w systemie Linux, zarówno na maszynach fizycznych, jak i wirtualnych.

Jeśli napotkasz komunikaty takie jak „nie znaleziono głównego systemu plików”, „brak miejsca na urządzeniu”, „błąd EXT4-fs”, „XFS: błąd CRC metadanych” lub przerażający Kernel Panic , dowiesz się, jak je interpretować, jakich poleceń użyć i w jakiej kolejności działać. Zobaczymy również, jak ustalić, czy problem jest rzeczywiście związany z oprogramowaniem, czy też sprzęt (pamięć RAM, dysk SSD/HDD, karta sieciowa itp.) jest na wyczerpaniu, i jak zminimalizować ryzyko utraty danych podczas rozwiązywania problemów.

Typowe przyczyny problemów z rozruchem w systemie Linux

Zanim zaczniesz eksperymentować na chybił trafił, warto poznać najczęstsze przyczyny, dla których Linux może się nie uruchamiać lub uruchamiać nieprawidłowo . Zrozumienie przyczyny problemu zaoszczędzi Ci godzin szukania rozwiązań i próbowania rozwiązań, które nie prowadzą donikąd.

Pierwszy zestaw problemów wynika z menedżera rozruchu i konfiguracji BIOS/UEFI : nieprawidłowo wygenerowane wpisy GRUB, nadpisany rekord MBR po zainstalowaniu systemu Windows w konfiguracji z podwójnym rozruchem , funkcja Secure Boot niekompatybilna z dystrybucją lub BIOS próbujący uruchomić system z niewłaściwego dysku. W takich przypadkach często nie widać nawet menu GRUB, a po wybraniu dystrybucji Linuksa system zawiesza się lub powraca do oprogramowania sprzętowego.

Inny ważny blok ma związek z dysk i system plikówUszkodzone partycje, uszkodzone sektory, uszkodzenie EXT4 lub XFS, pełne dyski systemowe lub błędy LVM. Zwykle objawia się to komunikatami podczas rozruchu, takimi jak „Nie udało się zamontować /…","Błąd EXT4-fs","XFS: Odmontuj i uruchom xfs_repair„lub nawet znaleźć się w trybie awaryjnym, prosząc Cię o wykonanie journalctl -xb.

Problemy są również bardzo częste po aktualizacji jądra lub źle zastosowanej poprawce . Niekompletne pobieranie, rozładowane moduły, sterowniki, które nie są już kompatybilne ze sprzętem lub zmiany w initramfs mogą spowodować zawieszenie się systemu w trakcie rozruchu lub wywołać panikę jądra podczas uruchamiania.

Nie możemy zapomnieć o sekcji poświęconej konfiguracji samego systemu : zbyt rygorystycznych regułach bezpiecznego rozruchu (na przykład auditd skonfigurowany z opcją HALT, gdy /var/log/audit jest pełny), krytycznych usługach, które ulegają awarii z powodu braku miejsca lub zmianach w plikach konfiguracyjnych, które uniemożliwiają uruchomienie niezbędnych demonów (sieci, systemd, cloud-init w chmurach takich jak Azure itd.).

Wreszcie mamy warstwę sprzętową: dyski z czerwonymi flagami SMART, pamięć RAM z błędami ECC, karty sieciowe tracące pakiety lub przegrzewające się dyski SSD . Często kluczem do rozwiązania problemu są komunikaty jądra (dmesg) lub liczniki SMART i EDAC, więc pokażemy, jak je uważnie odczytywać.

Jak zidentyfikować przyczynę awarii rozruchu

Kluczem do uniknięcia ślepych startów jest włączenie trybu „verbose boot” i przeglądanie logów . Domyślnie wiele dystrybucji wyświetla ładny ekran powitalny, który ukrywa komunikaty. Wygląda to dobrze, ale nie pomaga, gdy coś pójdzie nie tak.

W systemach z GRUB-em można wyłączyć tryb cichy, edytując plik /etc/default/grub . Poszukaj wiersza:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

i zastąp je:

GRUB_CMDLINE_LINUX_DEFAULT=""

Następnie uruchom polecenie `update-grub` (lub równoważne polecenie w swojej dystrybucji), aby zregenerować konfigurację. Przy następnym uruchomieniu systemu zobaczysz wszystkie komunikaty jądra i systemd, co pozwoli Ci dokładnie zlokalizować błąd powodujący awarię systemu.

Jeżeli system uruchomi się częściowo lub możesz uzyskać do niego dostęp z poziomu środowiska Live, w pliku /var/log znajdziesz kilka kluczowych logów :

• /var/log/boot.log: rejestruje wszystko, co dzieje się w fazie rozruchu; jeśli usterka występuje na tym etapie, to właśnie tam należy szukać w pierwszej kolejności.
• / var / log / messages o / var / log / syslog (w zależności od dystrybucji): ogólne zdarzenia systemowe, bardzo przydatne do przeglądania błędów w usługach, demonach itp.
• dmesg: wyświetla komunikaty jądra, w tym dotyczące awarii sprzętu, problemów z modułami, błędów magistrali, błędów PCI itp.
• journalctlW systemach wykorzystujących systemd jest to podstawowe narzędzie do przeglądania całego rejestru; journalctl -xb Widzisz ostateczny start w całej jego okazałości.

Jeśli system nie uruchomi się na pulpicie, ale przejdzie w tryb TTY lub tryb odzyskiwania, możesz uruchomić polecenie `journalctl -xb` bezpośrednio z tego miejsca. Jeśli to nie zadziała, będziesz musiał uruchomić system z Live USB , zamontować dysk systemowy i odczytać te pliki ze środowiska Live.

Sprawdź, czy problem dotyczy sprzętu czy oprogramowania

Zanim zaczniesz łamać sobie głowę nad edycją konfiguracji, warto sprawdzić, czy problem nie leży bezpośrednio w sprzęcie: dysku, pamięci, procesorze, płycie głównej lub zasilaczu . Wiele instalacji, które ulegają uszkodzeniu „losowo”, w rzeczywistości ujawnia awarię dysku SSD lub pamięci RAM.

Pierwszym krokiem, jeśli komputer w ogóle nie rozpoznaje dysku, jest wejście do BIOS-u/UEFI i sprawdzenie, czy dysk jest na liście. Jeśli dysk w ogóle się nie pojawia lub pojawia się sporadycznie, sprawdź połączenia, kable SATA i zasilacz, albo załóż, że dysk może wymagać recyklingu.

Jeśli dojdziesz do GRUB lub Live Boot, możesz uruchomić MemTest86+ z menu GRUB, aby sprawdzić pamięć RAM. Pozwól mu działać przez co najmniej osiem przebiegów; jeśli zobaczysz czerwone linie, pamięć jest uszkodzona i moduły wymagają wymiany. Wadliwa pamięć RAM to siedlisko uszkodzenia danych.

Aby sprawdzić stan dysków w systemie Linux, użyj narzędzia smartmontools . Po zainstalowaniu włącz SMART i sprawdź najważniejsze atrybuty:

• Przeniesiony_Sektor_Ct: liczba ponownie przypisanych sektorów; jeśli jest większa od 0, na dysku zaczęły już pojawiać się uszkodzone sektory.
• Aktualny_Oczekujący_Sektor_Ct: sektory oczekujące na ponowne przypisanie; każda wartość większa od 0 oznacza wysokie ryzyko rychłej awarii.
• Godziny_włączenia_zasilania:łączna liczba godzin użytkowania; im wyższa liczba, tym większe prawdopodobieństwo awarii dysku.

Używając polecenia `smartctl -H /dev/sdX`, możesz szybko sprawdzić, czy dysk przeszedł test kondycji. Jeśli wynik jest negatywny, należy jak najszybciej wykonać kopię zapasową danych i rozważyć jej wymianę.

Jeśli podejrzewasz wysokie temperatury, zamontuj czujniki lm i biegnij sensors (o watch -n 2 sensors (aby wyświetlić w czasie rzeczywistym). W przypadku dysków SSD i dysków SATA, temperatura dysku twardego Pokazuje aktualną temperaturę, dzięki czemu można wykryć urządzenia, których temperatura gwałtownie wzrasta, nawet gdy nie są używane. Jest to przydatne do... optymalizacja serwera.

Specjalistyczna diagnostyka sprzętu w systemie Linux

Oprócz procesora, pamięci RAM i dysku, Linux oferuje specjalistyczne narzędzia do oceny pamięci ECC, kart sieciowych, procesorów graficznych i innych komponentów . Poświęcenie kilku minut na sprawdzenie tych punktów może zaoszczędzić wiele godzin debugowania.

Jeśli Twój serwer lub stacja robocza ma pamięć ECC , jądro zazwyczaj rejestruje poprawione i nieskorygowane błędy za pomocą EDAC. Prosta procedura:

dmesg | grep EDAC

Pozwala sprawdzić, czy występują błędy CE (skorygowane) lub UE (nieskorygowane) . Błędy CE wskazują, że pamięć RAM miała błędy, ale sprzęt był w stanie je naprawić; zaleca się monitorowanie tych modułów, ponieważ zazwyczaj jest tylko kwestią czasu, zanim staną się one nienaprawialnymi błędami. Błędy UE często kończą się błędem Kernel Panic, aby zapobiec poważnemu uszkodzeniu danych .

Aby sprawdzić strukturę i pojemność pamięci, polecenie `dmidecode -t memory` wyświetla typ modułów (DDR3, DDR4, DDR5), pojemności, zajęte banki i inne informacje. Polecenie `dmidecode -t 16` pozwala sprawdzić maksymalną pojemność pamięci RAM obsługiwaną przez płytę główną, co jest przydatne, jeśli rozważasz rozbudowę.

W zakresie monitorowania temperatury i obrazu można wspierać dane z czujników i dysków twardych za pomocą narzędzi graficznych, takich jak psensor lub xsensors , które przedstawiają wykresy temperatury w czasie, umożliwiając wykrywanie nietypowych skoków temperatury lub urządzeń stale pracujących na granicy dopuszczalnej temperatury.

Do diagnostyki dysków i napędów USB , oprócz poleceń lsblk i fdisk -l służących do wyświetlania listy urządzeń, bardzo przydatne jest połączenie:

• df -h y df-i: procent wykorzystania przestrzeni i inodów. Możesz mieć wolne gigabajty, ale zajęte 100% inodów, a system i tak będzie informował o braku przestrzeni.
• fsck /dev/sdXN -y: wyszukuje i naprawia błędy logiczne w systemach plików (m.in. EXT2/3/4).
• badblocks /dev/my_disk: skanuje uszkodzone sektory i oznacza je, aby system z nich nie korzystał (przed wykonaniem tej czynności zdecydowanie zaleca się wykonanie kopii zapasowej).

W przypadku karty sieciowej , typowe objawy obejmują rozłączenia, opóźnienia lub niewyjaśnioną utratę pakietów. Możesz użyć narzędzia ethtool do przeglądania statystyk oraz narzędzia netstat do sprawdzenia wskaźników utraty pakietów (RX-DRP i TX-DRP). Jeśli odsetek utraty pakietów przekracza około 0,2% , wydajność sieci jest wyraźnie obniżona, a karta sieciowa może być uszkodzona lub słabo obsługiwana przez sterownik.

Pełny dysk i błędy związane z brakiem miejsca: klasyczne „Brak miejsca na urządzeniu”

Na wielu maszynach (zwłaszcza serwerach i maszynach wirtualnych ) jednym z najczęstszych problemów jest całkowite zapełnienie dysku systemowego. W takim przypadku usługi, logi, procesy rozruchowe, a nawet samo jądro zaczynają zgłaszać błędy wejścia/wyjścia.

W środowiskach takich jak Azure często można zobaczyć tego typu komunikaty w konsoli lub w diagnostyce uruchamiania:

• Brak miejsca w urządzeniu w cloud-init, co może uniemożliwić dokończenie rozruchu maszyny wirtualnej.
• Powtarzające się wiadomości od „Na urządzeniu nie ma już miejsca” które wpływają na kluczowe usługi, w tym agenta w chmurze.
• Błędy w dziennikach systemowych wskazujące na brak możliwości zapisu w dziennikach audytu lub sieci.

Aby szybko zlokalizować obiekt zajmujący daną przestrzeń, możesz użyć poleceń takich jak:

• du -ks /* | sort -n: wyświetla listę katalogów głównych posortowanych według rozmiaru; powtarza operację w obrębie największych katalogów, aż do znalezienia faktycznego winowajcy.
• ls -altSr /var/log: wyświetla pliki dziennika posortowane według rozmiaru, od najmniejszego do największego. Często można zobaczyć duże, stare dzienniki, które można obracać lub usuwać.
• znajdź / -rozmiar +500M -exec ls -alFh {} \;:szukaj dużych pojedynczych plików; dostosuj 500M w razie potrzeby.

Oprócz typowego zapełniania /var/log lub /tmp istnieją konfiguracje zabezpieczeń, takie jak audytowany co może spowodować wyłączenie się maszyny lub jej nieuruchomienie, zabrakło miejsca w /var/log/audit. Jeśli w /etc/audit/auditd.conf ty masz:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

System może wyłączyć się w sposób kontrolowany lub odmówić uruchomienia, jeśli nie może zapisać danych do dzienników audytu. Tymczasowym rozwiązaniem jest zmiana tych wartości na SUSPEND, IGNORE lub inne prawidłowe opcje (nigdy SINGLE w tym kontekście), aby umożliwić uruchomienie systemu i zwolnienie miejsca . Po rozwiązaniu problemu należy powrócić do pierwotnej polityki, jeśli wymagana jest zgodność.

Gdy nie ma możliwości usunięcia elementów, ponieważ system po prostu nie chce się uruchomić, można skorzystać z trybów ratunkowych : automatycznych poleceń naprawy w chmurze (np. az vm repair w Azure), wirtualnych maszyn odzyskiwania lub trybu pojedynczego użytkownika w celu zamontowania dysku i usunięcia niepotrzebnych plików, aż do momentu, gdy w systemie plików, w którym znajduje się /var/log i pozostałe krytyczne katalogi, pozostanie co najmniej 10% wolnego miejsca .

Uszkodzone systemy plików EXT4 i XFS: Jak naprawić uszkodzone systemy plików

Jeśli podczas uruchamiania widzisz komunikaty takie jak „Błąd EXT4-fs (urządzenie sda1)” , „błędny rozmiar_dodatku” , „nie znaleziono dziennika” lub komunikaty XFS takie jak „Wykryto błąd CRC metadanych… Odmontuj i uruchom xfs_repair” , nie masz do czynienia z jednorazowym problemem: system plików jest uszkodzony i dopóki go nie naprawisz, komputer nie uruchomi się normalnie.

Pierwszym krokiem jest zidentyfikowanie urządzenia, którego dotyczy problem . W dziennikach rozruchu zwróć uwagę na tekst w nawiasach w komunikatach jądra: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname itd. Dzięki temu dowiesz się, czy masz do czynienia z partycją bezpośrednią (sdXN), czy z woluminem logicznym LVM (dm-N, /dev/vgname/lvname).

Po uzyskaniu dostępu do powłoki (tryb awaryjny, pojedynczy użytkownik lub maszyna ratunkowa), uruchom polecenie `lsblk -f`, aby zobaczyć pełną strukturę: dyski, partycje, LVM i typy systemów plików. Bardzo ważne jest, aby potwierdzić, czy dana partycja to faktycznie ext4, xfs, vfat, LVM2_member itp., i nie polegać wyłącznie na wynikach pliku `/etc/fstab`, jeśli podejrzewasz, że jest ona błędnie skonfigurowana.

Do naprawy systemów plików EXT4 używa się fsck . Zasadniczo:

• Upewnij się, że system plików jest nieoprawny (jeśli jest to dysk z danymi) lub że pracujesz w środowisku ratunkowym, w którym nie jest on używany.
• Włócznia fsck /dev/sdXN o fsck /dev/vgname/lvnameZapyta Cię, czy chcesz poprawić nieścisłości, utworzyć ponownie inod, zmienić rozmiar, dostosować liczniki bloków itd.
• Jeżeli pojawi się wiele pytań, przerwij je za pomocą CTRL+C i uruchom ponownie za pomocą fsck -y aby automatycznie odpowiedzieć „tak”; w ten sposób niczego nie przeoczysz.
• Jeśli przeniesiesz pliki do zgubione+znalezioneBędziesz musiał je później sprawdzić i odłożyć na swoje miejsce.
• Uruchom ponownie fsck, aż wynik wskaże, że system plików jest kleń.

W przypadku XFS narzędziem tym jest xfs_repair . Typowy przepływ pracy wygląda następująco:

• Najpierw sucha kontrola: xfs_repair -n /dev/vgname/homelv aby zobaczyć jakie są uszkodzenia bez konieczności dokonywania jakichkolwiek zmian.
• Jeżeli analiza jest uzasadniona, powtórz ją bez parametru -n, aby można było podjąć próbę jej poprawienia: xfs_repair /dev/vgname/homelv.
• Jeśli polecenie zgłasza, że ​​system plików zawiera „cenne zmiany metadanych w dzienniku, które wymagają odtworzenia”, spróbuj go zamontować: w systemach XFS wiele oczekujących zmian jest stosowanych dokładnie w momencie montowania. Jeśli korzystasz z maszyny wirtualnej Rescue, możesz to zrobić w momencie, np. /recovery.
• Jeżeli nie ma innego sposobu i błędy dziennika nie zostaną naprawione, ostatecznością jest użycie xfs_repair -L Aby usunąć dziennik i wymusić montaż tak, jakby wszystkie zmiany zostały zastosowane. Może to spowodować utratę ostatnich danych, więc rób to tylko w ostateczności.

W każdym przypadku należy pamiętać, że fsck i xfs_repair nie są magiczne : naprawiają strukturę systemu plików, ale nie zawsze pozwalają odzyskać wszystkie dane. Dlatego tak ważne jest posiadanie wcześniejszych kopii zapasowych, a jeśli pracujesz w chmurze lub na maszynie wirtualnej, korzystanie z migawki dysku lub kopii dołączonej do maszyny ratunkowej.

GRUB, UEFI, Secure Boot i inne klasyczne programy rozruchowe

Gdy włączasz komputer i nie widzisz menu GRUB lub BIOS/UEFI wyświetla błędy typu „Nie udało się otworzyć \EFI\ubuntu\grubx64.efi - Nie znaleziono” i system wchodzi w pętlę, próbując uruchomić system z tego wpisu, problem prawdopodobnie leży w menedżerze rozruchu lub konfiguracji oprogramowania sprzętowego.

Te błędy mogą wystąpić po zainstalowaniu systemu Windows w konfiguracji dual-boot (która często przejmuje MBR lub nadpisuje wpisy UEFI), po przypadkowym usunięciu partycji EFI lub po zmianie kolejności rozruchu w BIOS-ie. W nowoczesnych laptopach nierzadko zdarza się, że komputer restartuje się w pętli, jeśli wpis UEFI „ubuntu” wskazuje na plik, który już nie istnieje, próbując go załadować.

Najprostszym sposobem naprawy uszkodzonego bootloadera GRUB jest uruchomienie systemu z dystrybucji Live (na przykład Ubuntu) i użycie narzędzia Boot-Repair . Typowa procedura wygląda następująco:

• Zacznij od USB na żywo i otwórz terminal.
• Dodaj repozytorium i zaktualizuj: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• Zainstaluj narzędzie: sudo apt install -y boot-repair.
• Uruchom to z boot-repair i wybierz opcję „zalecana naprawa”.

Boot-Repair analizuje partycje, lokalizuje zainstalowane systemy, rekonfiguruje GRUB, regeneruje plik konfiguracyjny i, jeśli to konieczne, dostosowuje wpisy UEFI tak, aby komputer mógł zostać uruchomiony z odpowiedniego menedżera rozruchu.

W systemach z włączonymi funkcjami UEFI, Secure Boot i Fast Boot istnieje kilka niezgodności, o których warto wiedzieć. Nie wszystkie dystrybucje obsługują Secure Boot poprawnie, a niektóre przeznaczone dla starszego sprzętu nie współpracują nawet dobrze z UEFI. Jeśli dystrybucja jest niepodpisana lub podkładka rozruchowa jest niekompatybilna, UEFI może odmówić załadowania jądra.

W takich przypadkach rozwiązaniem zazwyczaj jest dostęp do ustawień UEFI, włączenie trybu Legacy/CSM , aby umożliwić klasyczny rozruch w stylu BIOS-u, oraz wyłączenie funkcji Secure Boot . Jeśli jednak na tym komputerze używasz również systemu Windows 11 lub chcesz migrować z systemu Windows do Linuksa , wyłączenie funkcji Secure Boot może zakłócić wymagania rozruchowe systemu Windows, dlatego warto rozważyć, który system ma priorytet lub poszukać dystrybucji Linuksa kompatybilnej z funkcją Secure Boot, aby uniknąć konieczności każdorazowego dostępu do BIOS-u.

Funkcja szybkiego rozruchu systemu Windows również powoduje problemy w scenariuszach podwójnego rozruchu. Podczas zamykania systemu z włączoną funkcją szybkiego rozruchu, system Windows nie wyłącza się całkowicie: pozostawia część jądra w stanie hibernacji na dysku, blokując pełny dostęp do systemu plików NTFS. Gdy Linux próbuje zamontować te partycje, mogą wystąpić błędy, a nawet system może się zawiesić. Zaleca się wyłączenie funkcji szybkiego rozruchu zarówno w opcjach zasilania systemu Windows , jak i, jeśli UEFI na to pozwala, w samym systemie BIOS.

Korzystanie z trybów odzyskiwania i wbudowanych narzędzi naprawczych

Jeśli GRUB jest widoczny, ale system Linux nie uruchamia się, podejrzewasz, że jakiś pakiet został niedokończony lub że system uległ uszkodzeniu po aktualizacji, możesz skorzystać z zaawansowanych opcji GRUB-a i trybów odzyskiwania dostępnych w większości dystrybucji.

W menu GRUB-a zazwyczaj znajduje się wpis o nazwie „ Opcje zaawansowane ” lub podobny. Zazwyczaj zobaczysz tam wszystkie dostępne wersje jądra i dla każdej z nich tryb odzyskiwania . Wybierz tryb odzyskiwania dla najnowszej wersji (a jeśli to nie zadziała, wypróbuj poprzedni).

W trybie odzyskiwania wyświetlane jest menu z bardzo przydatnymi narzędziami:

• fsck:Sprawdź i napraw system plików (podobnie jak chkdsk w systemie Windows).
• kleń:zwolnij miejsce usuwając pliki tymczasowe i inne pozostałe pliki.
• dpkg: napraw uszkodzone pakiety, niespełnione zależności lub zablokowane instalacje.
• grub:regeneruj konfigurację menedżera rozruchu.

Uruchomienie tych opcji w odpowiedniej kolejności zazwyczaj rozwiązuje wiele problemów spowodowanych przerwami w dostawie prądu podczas aktualizacji, uszkodzonymi pakietami lub zapełnieniem dysków . Następnie system zazwyczaj zaproponuje ponowne uruchomienie w celu sprawdzenia, czy proces rozruchu wrócił do normy.

W chmurach takich jak Azure , oprócz trybu awaryjnego i pojedynczego użytkownika, masz do dyspozycji konkretne narzędzia, takie jak Azure Linux Automatic Repair (ALAR) i polecenie az vm repair , które automatyzują część procesu: montują dysk systemowy na ratunkowej maszynie wirtualnej, uruchamiają akcje, takie jak „auditd”, aby naprawić typowe konfiguracje i umożliwiają łatwe przywrócenie ustawień fabrycznych, jeśli coś pójdzie nie tak.

Strategie ponownej instalacji Linuksa bez utraty danych

Są sytuacje, w których, bez względu na to, jak dokładnie to zbadasz, system jest tak uszkodzony lub sprzęt jest tak nietypowy (jak HP N150 czy nowoczesne laptopy z nietypowymi kontrolerami), że najrozsądniej jest ponownie zainstalować dystrybucję . Nie oznacza to jednak utraty wszystkich danych.

Wiele dystrybucji, takich jak Ubuntu i jego pochodne, oferuje podczas instalacji opcję „ponowna instalacja systemu operacyjnego z zachowaniem dokumentów i ustawień ”. Powoduje to ponowną instalację systemu bazowego, ale próbuje zachować katalog /home, a czasami nawet niektóre zainstalowane aplikacje. To wygodne, choć nie niezawodne rozwiązanie, dlatego zaleca się ręczne utworzenie kopii zapasowej wszystkiego, czego nie chcesz utracić.

Najbardziej skuteczną metodą zabezpieczenia się przed przyszłymi ponownymi instalacjami jest podzielenie dysku na kilka oddzielnych partycji :

• Jeden za / (źródło):system bazowy.
• Jeszcze jeden dla /bagażnik (oraz /boot/efi w UEFI), jeśli chcesz mieć większą kontrolę nad uruchamianiem.
• Ekskluzywna sekcja dla / Home lub dla danych.

W ten sposób, jeśli Twój system Linux stanie się bezużyteczny, możesz sformatować tylko partycje systemowe i rozruchowe, pozostawiając partycję danych nietkniętą . Nawet jeśli masz tylko jedną partycję na wszystko, możesz uruchomić system ze środowiska Live, zamontować dysk, skopiować dokumenty na dysk zewnętrzny lub do chmury, a następnie, gdy wszystko będzie bezpieczne, przeprowadzić czystą instalację.

W maszynach wirtualnych, niezależnie od tego, czy pochodzą one z VirtualBox, VMware, czy chmury, dobrym pomysłem jest również oddzielenie dysków danych od dysku systemowego . Na przykład w Azure zaleca się, aby woluminy danych LVM nie znajdowały się w tej samej grupie woluminów co dysk systemowy, aby zapobiec awariom systemu operacyjnego, które mogłyby wpłynąć na dane.

Najlepsze praktyki zapobiegające ponownemu wystąpieniu problemów

Gdy już uporasz się z problemem uszkodzonego rozruchu i odzyskasz system (lub przynajmniej dane), rozsądnie będzie podjąć kroki, aby następnym razem strach był mniej dotkliwy lub całkowicie mu zapobiec.

Po pierwsze, należy aktualizować system i oprogramowanie , ale z rozwagą. W dystrybucjach z ciągłym wydawaniem, takich jak Arch, częste aktualizacje są niezbędne; w bardziej konserwatywnych (Debian Stable, Ubuntu LTS) można je wprowadzać w nieco dłuższych odstępach czasu, ale nie zaleca się pozostawiania ich bez zmian przez lata. Przed wprowadzeniem większych zmian jądra lub wersji zawsze należy wykonać porządną kopię zapasową.

Innym bardzo zdrowym nawykiem jest udokumentować wszelkie istotne zmiany konfiguracji: którego pliku dotykałeś, który wiersz zmieniłeś i jak to wyglądało wcześniej. Prostym trikiem jest zawsze zapisywanie kopii oryginalnego pliku z sufiksem. .bak (na przykład sshd_config.bak) dzięki czemu możesz je łatwo przywrócić, jeśli coś zepsujesz.

Jeśli chodzi o dane, regularne tworzenie kopii zapasowych jest niezbędne . Możesz użyć rsync do tworzenia kopii przyrostowych, tar do tworzenia całych katalogów lub rozwiązań chmurowych i NAS. Co więcej, jeśli Twoje dane znajdują się na innej partycji niż partycja systemowa, możesz bez problemu przeprowadzić ponowną instalację, nawet jeśli dysk nie uruchamia się.

Na koniec, warto regularnie monitorować stan systemu: co miesiąc sprawdzaj SMART, monitoruj inody i wolne miejsce na partycjach krytycznych (/, /var, /home), sprawdzaj logi pod kątem powtarzających się komunikatów oraz dbaj o niską temperaturę i poziom zapylenia sprzętu. Prosta procedura konserwacyjna pozwala zaoszczędzić wielu porannych napraw komputerów, które „nagle” przestały się uruchamiać.

Dzięki temu arsenałowi technik, poleceń i najlepszych praktyk diagnozowanie i naprawianie problemów z rozruchem i błędów sprzętowych w systemie Linux przestaje być aktem wiary, a staje się całkiem rozsądnym procesem: najpierw określasz, czy przyczyną awarii jest dysk, system plików, GRUB, jądro, konfiguracja czy sprzęt; następnie stosujesz odpowiednie narzędzie (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, recovery modes itp.); a w najgorszym przypadku masz dobrze zorganizowany plan B z oddzielnymi partycjami i kopiami zapasowymi, które umożliwiają ponowną instalację bez końca.