Diagnostisering av Linux-oppstartsproblemer og maskinvarefeil

Informatec Digital » Ressurser » Diagnostisering av Linux-oppstartsproblemer og maskinvarefeil

Når et Linux-system ikke starter opp eller begynner å oppføre seg uregelmessig, er den naturlige reaksjonen å tro at «Linux er ødelagt». I praksis er imidlertid de underliggende problemene oftest konfigurasjonsfeil, fulle disker, korrupsjon i filsystemet eller maskinvareproblemer som kan finnes med litt metodikk. Formålet med denne artikkelen er nettopp det: å demonstrere en tydelig prosedyre, støttet av spesifikke kommandoer, for å diagnostisere og reparere de vanligste oppstarts- og maskinvareproblemene i Linux, både på fysiske og virtuelle maskiner.

Hvis du støter på meldinger som «root file system not found», «No less space on device», «EXT4-fs error», «XFS: Metadata CRC error» eller en fryktet Kernel Panic , lærer du her hvordan du tolker dem, hvilke kommandoer du skal bruke og i hvilken rekkefølge du skal handle. Vi skal også se hvordan du kan avgjøre om problemet virkelig er programvarerelatert, eller om maskinvaren (RAM, SSD/HDD, nettverkskort osv.) er på vei mot slutten, og hvordan du minimerer risikoen for datatap under feilsøking.

Typiske årsaker til oppstartsproblemer i Linux

Før du begynner å tukle med ting på måfå, er det lurt å forstå de vanligste årsakene til at Linux kanskje ikke starter eller starter feil . Å forstå den underliggende årsaken vil spare deg for timer med feilsøking og å prøve løsninger som ikke fører noen vei.

Det første settet med problemer stammer fra oppstartsbehandleren og BIOS/UEFI-konfigurasjonen : feil genererte GRUB-oppføringer, en overskrevet MBR etter installasjon av Windows i et dobbeltoppstartsoppsett , sikker oppstart som ikke er kompatibel med distribusjonen din, eller BIOS som prøver å starte opp fra feil disk. I disse tilfellene vil du ofte ikke engang se GRUB-menyen, eller når du velger Linux-distribusjonen din, vil den fryse eller gå tilbake til fastvaren.

En annen viktig blokk har å gjøre med disk og filsystemSkadede partisjoner, dårlige sektorer, EXT4- eller XFS-korrupsjon, fulle systemdisker eller LVM-feil. Dette manifesterer seg vanligvis som meldinger under oppstart, for eksempel «Kunne ikke montere /…","EXT4-fs-feil","XFS: Avmonter og kjør xfs_repaireller til og med ende opp i nødmodus og be deg om å henrette journalctl -xb.

Problemer er også svært vanlige etter en kjerneoppdatering eller en dårlig installert oppdatering . Ufullstendige nedlastinger, utladede moduler, drivere som ikke lenger er kompatible med maskinvaren din, eller endringer i initramfs kan føre til at systemet fryser midt i oppstart eller utløse en kjernepanikk ved oppstart.

Vi må ikke glemme delen om konfigurasjonen av selve systemet : altfor strenge regler for sikker oppstart (for eksempel auditd konfigurert med HALT når /var/log/audit er full), kritiske tjenester som feiler på grunn av mangel på plass, eller endringer i konfigurasjonsfiler som forhindrer at viktige daemoner starter (network, systemd, cloud-init i skyer som Azure, osv.).

Til slutt har vi maskinvarelaget: disker med røde SMART-flagg, RAM med ECC-feil, nettverkskort som mister pakker, eller SSD-er som overopphetes . Ofte ligger ledetråden i kjernemeldinger (dmesg) eller i SMART- og EDAC-tellerne, så vi skal se hvordan vi leser dem nøye.

Hvordan identifisere kilden til startfeilen

Nøkkelen til å unngå blindstart er å aktivere detaljert oppstartsmodus og se gjennom loggene . Som standard viser mange distribusjoner en pen velkomstskjerm som skjuler meldingene, noe som ser bra ut, men som ikke er til noen hjelp når noe går galt.

På systemer som bruker GRUB, kan du deaktivere stillemodus ved å redigere /etc/default/grub . Se etter linjen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

og erstatte det med:

GRUB_CMDLINE_LINUX_DEFAULT=""

Kjør deretter `update-grub` (eller tilsvarende kommando i distribusjonen din) for å regenerere konfigurasjonen. Ved neste oppstart vil du se alle kjerne- og systemd-meldingene, slik at du kan finne den nøyaktige feilen som forårsaker systemkrasjet.

Hvis systemet klarer å starte delvis opp, eller du har tilgang til det fra et Live-miljø, vil du ha flere nøkkellogger tilgjengelig i /var/log :

• /var/log/boot.log: registrerer alt som skjer i oppstartsfasen; hvis feilen er i denne fasen, er det det første stedet å se etter.
• / var / log / meldinger o / var / log / syslog (avhengig av distroen): generelle systemhendelser, veldig nyttig for å vise feil i tjenester, daemoner osv.
• dmesgviser kjernemeldinger, inkludert maskinvarefeil, modulproblemer, bussfeil, PCI-feil osv.
• journalctlI systemer som bruker systemd, er det det primære verktøyet for å gjennomgå hele registeret; journalctl -xb Du ser den endelige starten i all sin prakt.

Hvis systemet ikke når skrivebordet, men når en TTY- eller gjenopprettingsmodus, kan du kjøre `journalctl -xb` direkte derfra. Hvis det ikke fungerer, må du starte opp fra en Live USB , montere systemdisken og lese disse filene fra live-miljøet.

Sjekk om problemet er maskinvare- eller programvarerelatert

Før du begynner å redigere konfigurasjonene dine, er det verdt å sjekke om problemet ikke ligger direkte i maskinvaren: disk, minne, CPU, hovedkort eller strømforsyning . Mange installasjoner som blir ødelagt "tilfeldig", avslører faktisk en SSD-disk eller RAM-disk som ikke fungerer.

Det første trinnet, hvis datamaskinen ikke engang gjenkjenner stasjonen, er å gå inn i BIOS/UEFI og bekrefte at stasjonen er oppført. Hvis stasjonen ikke vises i det hele tatt, eller vises av og til, sjekk tilkoblingene, SATA-kablene og strømforsyningen, eller anta at stasjonen kanskje må resirkuleres.

Hvis du kommer til GRUB eller en Live-oppstart, kan du starte MemTest86+ fra GRUB-menyen for å sjekke RAM-en din. La den kjøre i minst åtte omganger. Hvis du ser røde linjer, er minnet defekt , og modulene må byttes ut. Defekt RAM er grobunn for datakorrupsjon.

For å sjekke statusen til disker i Linux, bruk smartmontools . Etter at du har installert det, aktiver SMART og se gjennom de viktigste attributtene:

• Flyttet_sektor_Ct: antall omtilordnede sektorer; hvis den er større enn 0, har disken allerede begynt å ha dårlige sektorer.
• Gjeldende_ventende_sektor_Ctsektorer som venter på omtildeling; enhver verdi større enn 0 indikerer høy risiko for nært forestående feil.
• Strøm_på_timerakkumulerte brukstimer; jo høyere tall, desto større er sannsynligheten for at disken svikter.

Ved å bruke `smartctl -H /dev/sdX` kan du raskt se om disken består eller ikke består helsetesten. Hvis resultatet ikke er BESTÅTT, må du sikkerhetskopiere dataene dine så snart som mulig og begynne å tenke på å erstatte dem.

Hvis du mistenker høye temperaturer, installer lm-sensorer og løp sensors (o watch -n 2 sensors (for å se den i sanntid). For SSD-er og SATA-disker, hddtemp Den viser deg gjeldende temperatur, slik at du kan oppdage enheter som øker temperaturen selv når de er inaktive, noe som er nyttig for... serveroptimalisering.

Spesialisert maskinvarediagnostikk i Linux

I tillegg til CPU, RAM og disk har Linux spesifikke verktøy for å evaluere ECC-minne, nettverkskort, GPU-er og andre komponenter . Å bruke noen minutter på å sjekke disse punktene kan spare deg for mange timer med feilsøking.

Hvis serveren eller arbeidsstasjonen din har ECC-minne , logger kjernen vanligvis korrigerte og ukorrigerte feil ved hjelp av EDAC. En enkel:

dmesg | grep EDAC

Den lar deg se om det finnes CE (Corrected Errors) eller UE (Uncorrected Errors) . CE-er indikerer at RAM-en har hatt feil, men at maskinvaren har klart å rette dem. Det anbefales å overvåke disse modulene, fordi det vanligvis bare er et spørsmål om tid før de blir til feil som ikke kan rettes opp. UE-er avsluttes ofte med Kernel Panic for å forhindre alvorlig datakorrupsjon.

For å sjekke minnestrukturen og kapasiteten, viser `dmidecode -t memory` deg typen moduler (DDR3, DDR4, DDR5), kapasiteter, okkuperte banker og mer. Og med `dmidecode -t 16` kan du se den maksimale RAM-kapasiteten som støttes av hovedkortet, noe som er nyttig hvis du vurderer å oppgradere.

Innen temperatur- og visuell overvåking kan du støtte sensor- og HDD-temperaturdata med grafiske verktøy som psensor eller xsensors , som plotter temperaturen over tid for å oppdage uvanlige temperaturtopper eller utstyr som konstant er på varmegrensen.

For å diagnostisere disker og USB-stasjoner , i tillegg til lsblk og fdisk -l for å liste opp enheter, er det veldig nyttig å kombinere:

• df -h y df -i: prosentandel av plass og inodebruk; du kan ha gigabyte ledig, men 100 % av inodene okkupert, og systemet vil fortsatt klage over "ingen plass".
• fsck /dev/sdXN -ysøker etter og reparerer logiske feil i filsystemer (blant annet EXT2/3/4).
• badblocks /dev/min_diskskanner etter defekte sektorer og markerer dem slik at systemet ikke bruker dem (det anbefales på det sterkeste å ta en sikkerhetskopi før du gjør dette).

Når det gjelder et nettverkskort , inkluderer typiske symptomer frakoblinger, forsinkelse eller uforklarlig pakketap. Du kan bruke ethtool til å gjennomgå statistikk og netstat til å sjekke pakketapsrater (RX-DRP og TX-DRP). Hvis prosentandelen pakketap overstiger omtrent 0,2 % , påvirkes nettverksytelsen tydelig, og nettverkskortet kan være defekt eller dårlig støttet av driveren.

Feilmeldinger om full disk og plass: den klassiske feilmeldingen «Ingen plass igjen på enheten»

På mange maskiner (spesielt servere og virtuelle maskiner ) er et av de vanligste problemene at systemdisken fylles helt opp. Når dette skjer, begynner tjenester, logger, oppstartsprosesser og til og med selve kjernen å gi I/O-feil.

I miljøer som Azure er det vanlig å se meldinger som dette i konsollen eller i oppstartsdiagnostikk:

• Ingen plass igjen på enheten i cloud-init, noe som kan forhindre at den virtuelle maskinen fullfører oppstarten.
• Gjentatte meldinger fra «Det er ikke mer plass på enheten» som påvirker kritiske tjenester, inkludert skyagenten.
• Feil i systemloggene som indikerer at revisjons- eller nettverkslogger ikke kan skrives.

For raskt å finne hva som opptar plassen, kan du bruke kommandoer som:

• du -ks /* | sorter -n: viser rotkatalogene sortert etter størrelse; gjentar dette innenfor de tyngste katalogene til den virkelige synderen er funnet.
• ls -altSr /var/logviser loggfiler sortert etter størrelse, fra minste til største; du vil ofte se store gamle logger som kan roteres eller slettes.
• finn / -størrelse +500M -exec ls -alFh {} \;: søk etter store individuelle filer; juster de 500 MB etter behov.

Foruten den typiske utfyllingen av /var/log eller /tmp, finnes det sikkerhetskonfigurasjoner som revidert som kan føre til at en maskin slår seg av eller ikke starter når går tom for plass i /var/log/audit. Hvis i /etc/audit/auditd.conf du har:

admin_space_left_action = HALT
disk_full_action = HALT
disk_error_action = HALT

Systemet kan slå seg av på en kontrollert måte eller nekte å starte opp hvis det ikke kan skrive til revisjonsloggene. En midlertidig løsning er å endre disse verdiene til SUSPEND, IGNORE eller andre gyldige alternativer (aldri SINGLE i denne konteksten) for å la systemet starte opp og frigjøre plass . Etter at du har løst problemet, bør du gå tilbake til den opprinnelige policyen hvis samsvar er nødvendig.

Når det ikke er noen måte å slette ting på fordi systemet bokstavelig talt ikke vil starte opp, kan du ty til redningsmoduser : automatiske skyreparasjonskommandoer (f.eks. az vm repair i Azure), gjenopprettingsmodus for virtuelle maskiner eller enkeltbrukermodus for å montere disken og slette unødvendige filer til du har minst 10 % ledig plass i filsystemet som er vert for /var/log og resten av de kritiske mappene.

Korrupte EXT4 og XFS: Slik reparerer du skadede filsystemer

Hvis du ved oppstart ser ting som «EXT4-fs-feil (enhet sda1)» , «dårlig extra_isize» , «ingen journal funnet» eller XFS-meldinger som «Metadata CRC-feil oppdaget ... Avmonter og kjør xfs_repair» , har du ikke å gjøre med et engangsproblem: filsystemet er skadet, og maskinen vil ikke starte opp normalt før du reparerer det.

Det første trinnet er å identifisere hvilken enhet som er berørt . Se på teksten som vises i parentes i kjernemeldingene i oppstartsloggene: sda1, sdc1, dm-0, dm-2, /dev/mapper/vgname/lvname osv. Dette vil fortelle deg om du har å gjøre med en direkte partisjon (sdXN) eller et logisk LVM-volum (dm-N, /dev/vgname/lvname).

Når du har tilgang til et skall (nødmodus, enkeltbrukermodus eller redningsmaskin), kjør `lsblk -f` for å se hele strukturen: disker, partisjoner, LVM og filsystemtyper. Det er veldig viktig å bekrefte her om partisjonen faktisk er ext4, xfs, vfat, LVM2_member osv., og ikke stol utelukkende på hva `/etc/fstab` sier hvis du mistenker at den kan være feilkonfigurert.

For å reparere EXT4 -filsystemer brukes fsck . Som en generell regel:

• Sørg for at filsystemet er avmontert (hvis det er en datadisk) eller at du jobber fra et redningsmiljø der den ikke er i bruk.
• Lanza fsck /dev/sdXN o fsck /dev/vgname/lvnameDen vil spørre deg om du vil korrigere inkonsekvenser, gjenskape størrelsen på inoden, justere blokktellere osv.
• Hvis mange spørsmål dukker opp, avbryt med CTRL+C og kjør på nytt med fsck-y slik at den automatisk svarer «ja»; på den måten går du ikke glipp av noe.
• Hvis du flytter filer til tapt + funnetDu må sjekke dem senere og legge dem tilbake der de hører hjemme.
• Kjør fsck igjen til utdataene indikerer at filsystemet er ren.

Når det gjelder XFS , er verktøyet xfs_repair . Den typiske arbeidsflyten her er:

• Først, en tørrsjekk: xfs_repair -n /dev/vgname/homelv for å se hvilke skader som er uten å endre noe.
• Hvis analysen er rimelig, gjenta uten -n slik at den kan forsøke å korrigere: xfs_repair /dev/vgname/homelv.
• Hvis kommandoen klager over at filsystemet har «verdifulle metadataendringer i en journal som må reproduseres», kan du prøve å montere den: på XFS-systemer blir mange ventende endringer brukt presist ved montering. Hvis du er på en virtuell redningsmaskin, kan du gjøre dette på et tidspunkt som /recovery.
• Hvis det ikke finnes noen annen måte, og journalfeilene ikke blir rettet, er siste utvei å bruke xfs_reparasjon -L Å forkaste journalen og tvinge frem samlingen som om alle endringene var blitt brukt. Dette kan føre til tap av nylige data, så gjør dette bare som en siste utvei.

I alle tilfeller er det viktig å forstå at fsck og xfs_repair ikke er magiske : de fikser filsystemstrukturen, men de kan ikke alltid gjenopprette alle dataene. Derfor er det så viktig å ha tidligere sikkerhetskopier, og hvis du er i skyen eller på en virtuell maskin, å jobbe fra et diskbilde eller en kopi koblet til en redningsmaskin.

GRUB, UEFI, Secure Boot og andre oppstartsklassikere

Når du slår på datamaskinen og ikke engang ser GRUB-menyen, eller BIOS/UEFI gir feilmeldinger som "Klarte ikke å åpne \EFI\ubuntu\grubx64.efi - Ikke funnet" og går inn i en løkke når du prøver å starte opp fra den oppføringen, ligger problemet nesten helt sikkert i oppstartsbehandleren eller fastvarekonfigurasjonen.

Disse feilene kan oppstå etter at du har installert Windows i en dobbeltoppstartskonfigurasjon (som ofte overskriver MBR eller UEFI-oppføringer), etter at du har slettet en EFI-partisjon ved et uhell, eller etter at du har tuklet med oppstartsrekkefølgen i BIOS. På moderne bærbare datamaskiner er det ikke uvanlig at maskinen starter på nytt i en løkke hvis UEFI-oppføringen «ubuntu» peker til en fil som ikke lenger finnes, og prøver å laste den inn.

Den enkleste måten å reparere en ødelagt GRUB-oppstartslaster på er å starte opp fra en Live-distribusjon (for eksempel Ubuntu) og bruke Boot-Repair- verktøyet . Den typiske prosedyren er:

• Start fra en USB Live og åpne en terminal.
• Legg til depotet og oppdater: sudo apt-add-repository ppa:yannubuntu/boot-repair && sudo apt update.
• Installer verktøyet: sudo apt install -y boot-repair.
• Kjør den med boot-repair og velg alternativet «anbefalt reparasjon».

Boot-Repair analyserer partisjoner, finner installerte systemer, konfigurerer GRUB på nytt, regenererer konfigurasjonsfilen og justerer om nødvendig UEFI-oppføringer slik at datamaskinen starter opp fra riktig oppstartsbehandler.

På systemer med UEFI, Secure Boot og Fast Boot aktivert, er det flere inkompatibiliteter som er verdt å være klar over. Ikke alle distribusjoner støtter Secure Boot riktig, og noen som er designet for eldre maskinvare fungerer ikke engang bra med UEFI. Hvis distribusjonen din er usignert eller oppstartsskiven er inkompatibel, kan UEFI nekte å laste inn kjernen.

I disse tilfellene innebærer løsningen vanligvis å få tilgang til UEFI-innstillingene, aktivere Legacy/CSM -modus for å tillate oppstart i klassisk BIOS-stil og deaktivere sikker oppstart . Men hvis du også bruker Windows 11 på den datamaskinen eller ønsker å migrere fra Windows til Linux , kan deaktivering av sikker oppstart bryte Windows' oppstartskrav, så du bør vurdere hvilket system som prioriteres eller se etter en Linux-distribusjon som er kompatibel med sikker oppstart for å unngå å måtte få tilgang til BIOS hver gang.

Windows Fast Boot forårsaker også problemer i dobbeltoppstartsscenarier. Når du slår av med Fast Boot aktivert, slår ikke Windows seg helt av: den lar deler av kjernen være i dvalemodus på disken, noe som blokkerer full tilgang til NTFS-filsystemet. Når Linux prøver å montere disse partisjonene, kan det oppstå feil, eller systemet kan til og med fryse. Det anbefales å deaktivere Fast Boot i både strømalternativene i Windows og, hvis UEFI tillater det, i selve BIOS.

Bruk av gjenopprettingsmoduser og innebygde reparasjonsverktøy

Hvis GRUB vises, men Linux-systemet ditt ikke starter opp, eller hvis du mistenker at en pakke er uferdig eller at systemet er ødelagt etter en oppdatering, kan du dra nytte av GRUBs avanserte alternativer og gjenopprettingsmodusene som er inkludert i de fleste distribusjoner.

GRUB-menyen har vanligvis en oppføring som heter « Avanserte alternativer » eller noe lignende. Inni ser du vanligvis alle tilgjengelige kjerneversjoner og for hver enkelt en gjenopprettingsmodus . Velg gjenopprettingsmodusen for den nyeste versjonen (og hvis det mislykkes, prøv den forrige).

Gjenopprettingsmodus viser deg en meny med svært nyttige verktøy for:

• fsckSjekk og reparer filsystemet (ligner på chkdsk i Windows).
• renfrigjør plass ved å slette midlertidige filer og andre gjenværende filer.
• dpkg: fikse ødelagte pakker, udekkede avhengigheter eller fastlåste installasjoner.
• grubRegenerer oppstartsbehandlerkonfigurasjonen.

Å kjøre disse alternativene i rekkefølge løser vanligvis mange problemer forårsaket av strømbrudd under oppdateringer, ødelagte pakker eller disker som var i ferd med å bli fulle . Etterpå vil systemet vanligvis tilby å starte på nytt for å sjekke om oppstartsprosessen har gått tilbake til normalen.

I skyer som Azure har du, i tillegg til nødmodus og enkeltbrukermodus, spesifikke verktøy som Azure Linux Automatic Repair (ALAR) og az vm repair- kommandoen , som automatiserer deler av prosessen: de monterer systemdisken i en rednings-VM, kjører handlinger som «auditd» for å fikse typiske konfigurasjoner, og lar deg enkelt gå tilbake hvis noe går galt.

Strategier for å installere Linux på nytt uten å miste data

Det finnes situasjoner der, uansett hvor mye du undersøker, systemet er så ødelagt eller maskinvaren din er så uvanlig (som HP N150 eller moderne bærbare datamaskiner med eksotiske kontrollere) at det mest fornuftige å gjøre er å installere distribusjonen på nytt . Dette betyr imidlertid ikke nødvendigvis at du mister alle dataene dine.

Mange distribusjoner, som Ubuntu og dets derivater, tilbyr et alternativ under installasjonen som heter "installer operativsystemet på nytt mens dokumenter og innstillinger beholdes ". Dette installerer basissystemet på nytt, men forsøker å bevare /home-katalogen din og noen ganger til og med noen installerte applikasjoner. Det er et praktisk alternativ, men ikke idiotsikkert, så det er lurt å manuelt sikkerhetskopiere alt du ikke vil miste.

Den mest robuste måten å beskytte mot fremtidige reinstallasjoner på er å organisere disken i flere separate partisjoner :

• En for / (rot): basissystem.
• En annen for /støvel (og /boot/efi i UEFI) hvis du vil ha mer kontroll over oppstart.
• En eksklusiv seksjon for / Hjem eller for data.

På denne måten, hvis Linux-systemet ditt blir ubrukelig, kan du bare formatere system- og oppstartspartisjonene, og la datapartisjonen være urørt . Selv om du bare har én partisjon for alt, kan du oppstarte fra et Live-miljø, montere disken, kopiere dokumenter til en ekstern disk eller skyen, og deretter, når alt er trygt, utføre en ren installasjon.

I virtuelle maskiner, enten det er fra VirtualBox, VMware eller skyen, er det lurt å også skille datadisker fra systemdisken . I Azure anbefales det for eksempel at LVM-datavolumer ikke blandes i samme volumgruppe som systemdisken for å forhindre at en OS-feil også påvirker dataene.

Beste fremgangsmåter for å forhindre at problemer gjentar seg

Når du har håndtert en ødelagt oppstart og gjenopprettet systemet ditt (eller i det minste dataene dine), er det smarteste å ta noen grep for å gjøre skremselen mindre alvorlig neste gang eller forhindre at den skjer helt.

Det første er å holde systemet og programvaren oppdatert , men gjør det med fornuftig hjelp. I rullerende utgivelser som Arch er hyppige oppdateringer avgjørende; i mer konservative distribusjoner (Debian Stable, Ubuntu LTS) kan du ha litt mellomrom mellom dem, men det er ikke tilrådelig å la dem være urørt i årevis. Før større endringer i kjernen eller versjonen, bør du alltid ta en skikkelig sikkerhetskopi.

En annen veldig sunn vane er dokumentere eventuelle større konfigurasjonsendringer: hvilken fil du berørte, hvilken linje du endret, og hvordan den var før. Et enkelt triks er å alltid lagre en kopi av den opprinnelige filen med suffikset. . bakover (for eksempel sshd_config.bak) slik at du enkelt kan gjenopprette den hvis du roter den til.

Når det gjelder data, er regelmessige sikkerhetskopier viktige . Du kan bruke rsync for inkrementelle sikkerhetskopier, tar for å pakke hele mapper, eller sky- og NAS-løsninger. Videre, hvis dataene dine er på en annen partisjon enn systempartisjonen, kan du installere på nytt uten store problemer, selv om disken ikke starter opp.

Til slutt er det alltid lurt å overvåke systemets helse regelmessig: sjekk SMART månedlig, overvåk inoder og ledig plass på kritiske partisjoner (/, /var, /home), se på logger for gjentakende meldinger, og hold temperatur og støvnivåer nede på fysisk utstyr. En enkel vedlikeholdsrutine sparer mange tidlige morgener for å fikse maskiner som "plutselig" har sluttet å starte opp.

Med dette arsenalet av teknikker, kommandoer og beste praksis, slutter diagnostisering og reparasjon av oppstartsproblemer og maskinvarefeil i Linux å være en handling av tro og blir en ganske rimelig prosess: først identifiserer du om feilen skyldes disken, filsystemet, GRUB, kjernen, konfigurasjonen eller maskinvaren; deretter bruker du riktig verktøy (fsck, xfs_repair, Boot-Repair, smartctl, MemTest, gjenopprettingsmoduser, osv.); og i verste fall har du en velorganisert plan B med separate partisjoner og sikkerhetskopier som lar deg installere på nytt uten at verden går under.