Quan un equip amb Linux es nega a arrencar, l'ensurt és important, però la veritat és que la majoria de problemes d'arrencada a Linux tenen solució sense necessitat de formatar ni perdre dades. A diferència d'altres sistemes, gairebé sempre podem entrar en modes de rescat, TTYs bàsics o fer servir distros Live per ficar mà al sistema.
A més, parlem d'un ecosistema molt estable: Linux és un sistema de codi obert reconegut per la seva fiabilitat , àmpliament usat en servidors pel seu enorme temps d'activitat i baixa taxa d'errors. Això no vol dir que sigui infal·lible; moltes avaries vénen de configuracions arriscades, kernels experimentals o toqueigs a particions i gestors d'arrencada. La bona notícia és que hi ha passos força clars per diagnosticar i arreglar gairebé qualsevol escenari.
Per què podeu deixar d'arrencar un sistema Linux
Abans de posar-nos a llançar ordres a la bogeria convé entendre que les fallades d'arrencada a Linux solen concentrar-se en unes poques causes típiques , ja sigui per programari o per maquinari. Tenir-les clares ajuda a no perdre temps fent cops de banda.
Una de les raons més freqüents és un problema amb la partició d'arrencada o amb el sistema de fitxers . Si la partició on viu el sistema (o el /boot) es corromp, canvia d'identificador o deixa de ser accessible, el kernel no podrà muntar-la i el procés es quedarà penjat o llençarà errors tipus kernel panic.
També és habitual que l'embolic vingui d'una actualització de nucli mal instal·lada, incompatible oa mig aplicar . Si el nou nucli no està bé amb el vostre maquinari o està incomplet, el sistema es pot congelar durant el boot, mentre que la versió anterior del nucli continuaria funcionant sense problemes si la tries des del GRUB.
Un altre clàssic és aplicar pegats o actualitzacions de paquets crítics que es queden a mitges (per exemple per un tall de llum o de xarxa). En aquest cas, systemd pot no ser capaç d'aixecar tots els serveis essencials i acabareu amb un sistema que no arriba a l'escriptori o es queda en consola amb missatges d'error.
Cal no oblidar els controladors problemàtics : encara que gran part dels drivers s'integra al mateix nucli, de vegades instal·lem manualment controladors privatius (sobretot de gràfica o WiFi) que poden deixar el sistema en negre o bloquejar l'arrencada després d'una actualització.
Si teniu arrencada dual amb Windows, entreu en joc un altre factor: Windows pot sobreescriure l'MBR o l'entrada d'arrencada a UEFI , col·locant el vostre propi carregador com a prioritari i deixant fora GRUB. També el Fast Boot / Fast Startup del Windows pot bloquejar l'accés a particions NTFS o generar bloquejos quan intenteu arrencar Linux.
Finalment, hi ha els problemes de configuració: una BIOS/UEFI que arrenca des del disc equivocat, un Secure Boot incompatible o una entrada EFI eliminada poden fer que el sistema sembli mort quan en realitat el disc i la instal·lació segueixen intactes.
Com diferenciar un problema de maquinari d'un programari
Abans de començar a reparar cegues, convé descartar que el problema sigui purament físic. Un sistema amb errors de memòria, una font inestable o un SSD moribund pot fer que qualsevol intent de reparació per programari sigui inútil.
El primer pas és entrar a la BIOS/UEFI i revisar si la placa detecta el disc on està instal·lat Linux . Si la unitat ni tan sols apareix a la llista de dispositius oa l'apartat d'ordre d'arrencada, toca comprovar cables, ports i, en el pitjor cas, assumir que la unitat ha dit prou.
Si el disc és present, toca mirar la resta de components. Des de GRUB o des d'una distro Live pots llançar MemTest86+ per comprovar RAM i CPU. L'ideal és deixar-lo funcionar almenys 8 passades; si apareixen línies vermelles és senyal derrors de memòria i hauríeu de canviar els mòduls afectats.
Quant a l'emmagatzematge, des d'un Live pots fer servir smartmontools i consultar la sortida de smartctl per revisar els atributs SMART del disc . Si veus valors per sobre de zero a Reallocated_Sector_Ct o Current_Pending_Sector_Ct, estàs davant d'un disc amb sectors reassignats o pendents i la fallada seriós és qüestió de temps.
Identificar què falla en l'arrencada
Quan el maquinari sembla sa, arriba el moment d' esbrinar en quin punt exacte s'encalla el procés d'arrencada de Linux . Això marca la diferència entre un problema del GRUB, del nucli, del sistema de fitxers o de serveis.
En moltes distros, l'arrencada mostra un logotip o una animació que amaga els missatges reals del sistema. Si voleu veure què passa a cada moment, podeu desactivar el mode silenciós editant el fitxer /etc/default/grub . Canvia la línia on apareix quiet splash perquè quedi buida i després executa update-grub. A la següent arrencada veuràs tots els missatges en mode «verbose».
A més de l'arrencada en si, Linux manté registres molt detallats en diversos fitxers de log . Si el sistema ja no s'inicia, podeu arrencar des d'una distro Live, muntar la partició arrel i revisar aquests fitxers:
- /var/log/boot.log: conté els missatges generats durant el boot.
- / Var / log / messages o el seu equivalent segons la distro: registre general d'esdeveniments del sistema.
- dmesg: llistat de missatges del kernel, molt útil per veure fallades de drivers o de discos.
- diarictl: accés al registre de systemd, amb filtres per data, unitat, etc.
Amb aquesta informació podreu localitzar si la fallada es produeix en muntar una partició, en carregar un mòdul del kernel o en iniciar un servei concret.
Comproveu la BIOS/UEFI i l'ordre d'arrencada
Quan l'equip ni tan sols arriba a mostrar el GRUB, un dels sospitosos habituals és la configuració de la placa. És fonamental verificar que la BIOS/UEFI està apuntant a la unitat i partició correctes i que el microprogramari reconeix el disc.
Segons el fabricant de la placa hauràs de prémer Supr, Esc, F2, F10 o una altra tecla durant l'encesa per entrar a la configuració. Un cop dins, revisa el menú Boot o Arrencada i confirma que el teu SSD o disc dur amb Linux apareix i està col·locat com a dispositiu d'arrencada principal o que la vostra entrada EFI està en primer lloc.
Si no veieu la unitat, potser haureu d' activar compatibilitat amb maquinari antic (CSM/Legacy) , com passa en alguns equips on el disc deixa de detectar-se en mode UEFI pur. Si tot i així no apareix, probablement el SSD s'ha avariat físicament.
També aquí entren en joc paràmetres com a Secure Boot i Fast Boot; si utilitzeu una distro que no està signada per a Secure Boot o si comparteixes equip amb Windows 11, una configuració agressiva d'arrencada segura pot bloquejar Linux fins que desactivis o ajustis aquesta opció.
Secure Boot, UEFI, Fast Boot i problemes amb arrencada dual
Els equips moderns arrenquen gairebé sempre en mode UEFI i, si vénen amb Windows preinstal·lat, solen portar Secure Boot i Fast Boot activats . Aquestes mesures estan pensades per millorar seguretat i temps de càrrega, però poden xocar amb algunes distribucions Linux.
La majoria de distros populars ja inclouen firmes vàlides per a Secure Boot i arrenquen sense embolics, però altres més exòtiques o pensades per a maquinari antic no les porten. En aquests casos hauràs d'entrar a UEFI, passar el microprogramari a mode Legacy/CSM o desactivar Secure Boot per poder carregar el nucli de Linux.
Si teniu un sistema d'arrencada dual, el Fast Boot de Windows i el Fast Boot de la mateixa UEFI afegeixen una altra capa de problemes. Quan Windows utilitza inici ràpid manté part del nucli hibernat en disc, cosa que provoca que la partició NTFS quedi bloquejada i la BIOS limiti l'accés des d'altres sistemes . El resultat: errors en intentar muntar les particions des de Linux.
La solució passa per desactivar Fast Startup a Windows (Opcions d'energia) i, si cal, el Fast Boot a UEFI. D'aquesta manera, tots dos sistemes arrencaran sempre des de zero i no es deixaran estats intermedis que causin corrupcions o bloquejos.
Eines clau per recuperar un Linux que no arrenca
Un cop localitzat l'origen del problema o almenys acotada la zona conflictiva, arriba el torn de les eines. Linux ofereix un bon arsenal d'utilitats de recuperació tant des del propi sistema com des de distros Live.
Entre les més típiques trobem mount per muntar particions, fsck per revisar i reparar sistemes de fitxers, i comandes com telinit o init (en sistemes més clàssics) per canviar runlevels i entrar en modes d'usuari únic pensats per a reparació.
En sistemes amb systemd la navalla suïssa és systemctl , que permet arrencar en modes especials com rescue.target o emergency.target. Aquests targets són entorns mínims on s'aixequen només els serveis imprescindibles i s'ofereix una shell com a root per fer canvis sense interferències.
Si el problema està al mateix carregador d'arrencada, entra en joc GRUB i el seu intèrpret d'ordres interactiva . Des del menú podeu editar entrades al vol, arrencar kernels alternatius o accedir a un CLI de GRUB (grub> o grub rescue>) quan s'ha perdut la configuració.
Usar GRUB per entrar en modes de recuperació
Quan GRUB apareix però el sistema es penja després, teniu diverses opcions per utilitzar el propi menú d'arrencada com a porta d'entrada a tasques de reparació.
Si manteniu premuda la tecla Shift (en moltes distros) o premeu Esc durant l'inici, hauríeu de veure el llistat de kernels disponibles. Amb les tecles de direcció pots triar l'entrada principal o entrar a les opcions avançades , on trobaràs diferents versions del nucli i modes especials d'arrencada.
El més interessant aquí és el Recovery Mode o mode de rescat . Cada nucli instal·lat sol tenir la seva variant de recuperació, que inicia el sistema en un entorn limitat i mostra un menú amb diverses accions útils: fsck per comprovar i reparar el sistema de fitxers, clean per alliberar espai en disc, dpkg per arreglar paquets trencats, grub per actualitzar el carregador d'arrencada, network per activar la xarxa i root.
Si el vostre problema ve d'una actualització del nucli recent, podeu provar d'arrencar amb una versió anterior des del mateix menú avançat . Si el sistema funciona amb el nucli vell, sabràs que el conflicte està al nou nucli o en algun mòdul associat.
Una altra jugada possible és editar temporalment la línia d'arrencada. Amb l'opció E podreu modificar els paràmetres abans de llançar el nucli i afegir, per exemple, systemd.unit=emergency.target per forçar l'arrencada en mode d'emergència, o systemd.unit=rescue.target per anar al target de rescat sense necessitat que hi hagi una entrada específica al menú.
Tingueu en compte que GRUB anomena els discs i les particions de manera diferent de Linux : el que a Linux és /dev/sda, /dev/sdb, etc., a GRUB es representa com a hd0, hd1, i les particions com a hd0,0; hd0,1, etc. Això és important en manipular rutes de kernel i initrd des de l'intèrpret d'ordres de GRUB.
Reparar GRUB amb una distro Live (Boot-Repair i companyia)
Si el que falla és GRUB en si, ja sigui per una actualització mal feta, una arrencada dual amb Windows que ho ha trepitjat o un esborrat accidental, el més pràctic sol ser estirar un sistema Live i reinstal·lar o reparar el carregador.
Arranca el teu equip des d'un USB Live del teu distro (per exemple Ubuntu o qualsevol derivada de Debian) i tria l'opció de provar sense instal·lar. Un cop a l'escriptori, obre un terminal i munta la partició arrel del teu Linux si ho necessites per trastejar manualment, o instal·la eines específiques.
Una utilitat molt còmoda per a usuaris menys experimentats és Boot-Repair . En sistemes basats en Ubuntu pots afegir el seu PPA, refrescar repositoris i instal·lar-la amb un parell d'ordres. Després d'executar-la, l'eina analitza les unitats, detecta els sistemes operatius presents i ofereix una «reparació recomanada» que reinstal·la GRUB i actualitza les entrades.
Quan s'acaba, només cal reiniciar l'equip sense l'USB i comprovar si el menú de GRUB torna a aparèixer amb totes les entrades (Linux, Windows, eines com MemTest86+, etc.). En molts casos aquesta simple operació torna el sistema a la vida.
Utilitzar modes d'emergència i rescue de systemd
En distros modernes basades en systemd, a més de la manera de recuperació que exposa GRUB, pots aprofitar els targets especials emergency i rescue per solucionar conflictes de serveis, dependències i muntatges.
El target emergency munta el sistema de fitxers arrel en mode lectura/escriptura i et deixa en una shell mínima de root sense llançar gairebé serveis. És ideal quan sospites que un dimoni, un servei o un muntatge addicional està provocant el bloqueig . Des d'aquí pots modificar fitxers de configuració, desactivar serveis amb systemctl disable o revisar unitats a /etc/fstab.
El target rescue és una mica menys agressiu: aixeca més serveis que emergency, però continua sent un entorn reduït, pensat per reparar sense necessitat de l'entorn gràfic. També es pot assolir des del GRUB passant el paràmetre systemd.unit=rescue.target o canviant de target una vegada dins amb systemctl isolate rescue.target.
Revisar i reparar particions amb fdisk i fsck
Quan la sospita apunta a l'emmagatzematge, les eines de baix nivell són essencials. Des d'un Live o des d'un mode de rescat, fdisk -l et llista totes les unitats i les particions , de manera que puguis localitzar on està instal·lat el sistema (per exemple /dev/sda1, /dev/nvme0n1p2, etc.).
Un cop identificada la partició afectada, podeu recórrer a fsck per comprovar i reparar el sistema de fitxers . La comanda típica seria com sudo fsck /dev/sda1, adaptant el dispositiu al teu. Aquesta eina recorre l'estructura, detecta inconsistències i, en molts casos, les corregeix automàticament.
És important recordar que fsck i fdisk poden causar pèrdua de dades si es fan servir sense cura . Sempre és recomanable tenir còpia de seguretat abans de posar mà a la taula de particions oa la reparació profunda de sistemes de fitxers. Tot i així, moltes vegades són la diferència entre rescatar el sistema o veure's obligat a reinstal·lar.
Recuperar sistemes Linux a màquines virtuals
Quan Linux està instal·lat en una màquina virtual, l'escenari canvia lleugerament: el sistema convidat depèn que els vostres fitxers d'imatge segueixin presents al host . Si ets a VirtualBox o VMware, convé assegurar-se primer que la VM no ha estat esborrada en alliberar espai.
Per defecte, VirtualBox desa les màquines en una carpeta tipus VirtualBox VMs dins del directori de l'usuari, mentre que VMware utilitza rutes similars sota la carpeta vmware. Si aquests directoris desapareixen o els VDI/VMDK han estat esborrats, recuperar la màquina virtual completa serà gairebé impossible sense còpies de seguretat.
Per minimitzar riscos, és bona idea instal·lar eines d'integració com Guest Additions a VirtualBox o VMware Tools . Gràcies a elles pots compartir carpetes entre el host i el convidat i treballar amb els teus fitxers des del sistema principal. Així, si la VM mor, els teus documents importants seguiran fora de perill al host o fins i tot al núvol.
Reinstal·lar Linux sense perdre (o perdent el mínim) les teves dades
Quan després de tots els intents el sistema segueix sense arrencar, arriba un punt on reinstal·lar la distribució és l'opció més ràpida i neta . Però això no vol dir necessàriament formatar tot i començar de zero.
Moltes distros, especialment les basades en Ubuntu, permeten reinstal·lar el sistema mantenint la carpeta personal i, en alguns casos, les aplicacions . L'instal·lador detecta que ja hi ha una instal·lació prèvia i ofereix una opció per substituir només els components del sistema sense tocar les dades de l'usuari.
La jugada ideal, però, és haver planificat això des del principi. Si durant la primera instal·lació crees tres particions separades: boot, arrel (/), i /home per a les dades , el dia que el sistema es trenqui podràs reinstal·lar la distro esborrant només les particions d'arrencada i de sistema, respectant intacta la que guarda els teus documents.
Si no us heu pres aquesta molèstia i tot està en una única partició, encara podeu arrencar des d'un Live i copiar els vostres fitxers a un disc extern abans de formatar. Mentre el disc estigui llegible, podreu muntar la partició i extreure documents, fotos, projectes, etc., sense dependre d'eines de recuperació forense.
Metodologia de recuperació en distros Debian i derivades
Per als que vénen de Windows, pot ajudar molt tenir un “full mental” de passos a seguir quan un Debian, Ubuntu, Zorin o similar no arrenca , a l'estil del que es fa amb la manera segura i la restauració del sistema.
Un esquema raonable pot ser:
- Primer, intentar entrar al mode de recuperació des de GRUB i utilitzar eines com fsck, dpkg o l'intèrpret d'ordres per corregir problemes evidents.
- Si no és possible, arrencar amb un USB Live de la distro (o fins i tot amb distros de rescat tipus SystemRescue o Rescatux) per muntar el disc, revisar logs, executar fsck i, si cal, chrootejar a la instal·lació per actualitzar paquets i GRUB.
- Si el sistema segueix sense arrencar, valoreu l'opció de reparar o reinstal·lar GRUB amb eines com Boot-Repair o manualment.
- Com a últim esglaó, reinstal·lar la distribució mantenint o salvant dades i després aplicar les bones pràctiques de particionament i còpies de seguretat per al futur.
No hi ha una «màquina del temps» integrada tan vistosa com la de macOS, però amb eines com rsync, snapshots de Btrfs o solucions de còpia incremental pots aconseguir una cosa molt similar, sempre que te'n recordis de configurar abans del desastre.
Distros Linux de rescat: la teva navalla multiusos quan res arrenca
Més enllà de les eines incloses en cada distribució generalista, hi ha distribucions de rescat pensades específicament per arreglar equips que no arrenquen . Són sistemes arrencables des d'USB o CD que ho carreguen gairebé tot en RAM i porten de sèrie un bon arsenal d'utilitats.
Aquestes distros de rescat solen incloure eines de gestió de disc i sistemes de fitxers, utilitats per reparar gestors d'arrencada, diagnòstic de maquinari i recuperació de dades . La idea és poder analitzar i reparar sense necessitat de tocar immediatament la instal·lació danyada.
Entre les més conegudes estan SystemRescue, amb suport per a sistemes de fitxers moderns (ext4, XFS, Btrfs, NTFS, ZFS) i eines com GParted, fsck, testdisk o ddrescue; Rescatux, amb una interfície gràfica molt enfocada a tasques comunes de reparació (GRUB, EFI, contrasenyes de Windows i Linux) i Finnix, molt més lleugera i orientada a usuaris acostumats a la línia d'ordres ia l'administració remota.
Per a un administrador de sistemes o qualsevol usuari que vulgui anar preparat, portar sempre un USB amb una distro de rescat actualitzada és gairebé obligatori . Fa la diferència entre estar bloquejat hores i resoldre el problema en pocs minuts.
Bones pràctiques per evitar que el sistema torne a fallar
Un cop has sobreviscut a un ensurt d'aquest tipus, el més lògic és intentar reduir les probabilitats de reviure la mateixa pel·lícula . No es pot blindar un sistema al 100%, però sí que es poden minimitzar riscos.
El primer és ser prudent amb les actualitzacions de kernel i de paquets crítics . És recomanable llegir breument les notes de canvi quan es tracta de kernels nous o de drivers sensibles (gràfica, RAID, etc.) i mantenir al dia la resta del sistema per beneficiar-se de correccions d'errors i pegats de seguretat.
També és molt útil adoptar el costum de fer còpies dels fitxers de configuració abans d'editar-los . Desar un fitxer original amb extensió .bak permet revertir fàcilment un canvi mal fet des d'un Live o una manera de rescat sense necessitat de recordar exactament què vas modificar.
Quant a les dades, la recomanació estrella és separar la partició del sistema de la dels fitxers personals i mantenir còpies de seguretat periòdiques en una altra unitat o al núvol. Així, el dia que el disc principal falli físicament, perdràs com a molt el que no s'hagi sincronitzat a la teva última còpia.
Finalment, cuidar una mica el maquinari també ajuda: fer servir SSD en lloc de HDD mecànics, ampliar la RAM quan l'equip va just, evitar apagar «allò brut» i vigilar temperatures i alimentació perllonga la vida útil del sistema i redueix les errades estranyes en l'arrencada.
Amb tot això al cap, un Linux que avui sembla completament mort sol esdevenir un sistema recuperable amb paciència, bon diagnòstic i les eines adequades, i un cop après el procés, afrontaràs la següent fallada amb molta més tranquil·litat i control.
