Fins ara srv-tramontana sempre ha arrencat. Has instal·lat, configurat, enfortit i defensat un sistema partint de la premissa que, en encendre'l, apareix un indicador d'ordres. Aquesta lliçó trenca aquella premissa, i ho fa en els dos sentits: primer entendràs què passa exactament entre prémer el botó i veure l'indicador, i després aprendràs a intervenir quan aquella cadena es trenca.

És l'habilitat que separa qui reinstal·la de qui arregla. Un fstab amb un UUID equivocat, un initramfs que no inclou el mòdul de LUKS, un GRUB sobreescrit per un altre sistema operatiu, una contrasenya de root perduda: tots són problemes de cinc minuts si saps on intervenir, i una reinstal·lació de vuit hores si no ho saps. I com que el Mòdul 5 et va ensenyar a modificar fstab i el 6 a xifrar un volum amb LUKS, ja tens a la màquina exactament els ingredients que provoquen aquestes fallades.

Nota sobre el laboratori. Diversos dels procediments d'aquesta lliçó necessiten la consola de la VM, no una sessió SSH: quan el sistema no arrenca, no hi ha xarxa. Tingues clar com obrir la consola de VirtualBox abans de començar, i fes una instantània nova (06-abans-d-arrencada) — trencaràs l'arrencada a propòsit.

1. La cadena d'arrencada completa
2. El microprogramari: UEFI i BIOS
3. GRUB 2: el gestor d'arrencada
4. L'initramfs: el sistema mínim intermedi
5. El nucli i el pas de control a PID 1
6. systemd i els targets
7. Paràmetres de la línia d'ordres del nucli
8. Recuperació: intervenir en l'arrencada
9. Recuperar un sistema que no arrenca
10. Reinstal·lar GRUB des d'un mitjà de rescat

Arrencar un sistema és una successió de programes, cadascun amb més capacitat que l'anterior, en què cada baula carrega i cedeix el control a la següent. Se'n diu bootstrapping precisament per això.

Les cinc baules i la seva responsabilitat, que convé tenir al cap perquè el diagnòstic consisteix a identificar en quina es va trencar:

Aquella taula és l'eina de diagnòstic més útil de la lliçó: quan algú et digui «el servidor no arrenca», la primera pregunta és fins on va arribar.

El microprogramari (firmware) viu a la placa base, s'executa abans que qualsevol cosa que hi hagi al disc, i la seva feina és deixar el maquinari en un estat utilitzable i localitzar alguna cosa per arrencar. Hi ha dues generacions, i srv-tramontana fa servir la moderna:

La diferència clau és la tercera fila. A BIOS, el carregador havia de cabre en 446 bytes, cosa que obligava a un salt en dues fases i a col·locar codi a l'espai entre l'MBR i la primera partició. A UEFI, el microprogramari sap llegir FAT32, així que el carregador és un fitxer normal en una partició normal.

Aquella partició és l'ESP (partició del sistema EFI):

Tres fitxers que convé distingir, perquè l'ordre en què es criden importa quan alguna cosa falla:

• shimx64.efi és la primera baula quan Secure Boot està actiu: està signat per Microsoft (la clau del qual ve de fàbrica a les plaques), i la seva única funció és verificar i carregar el següent. És el pont entre la cadena de confiança del fabricant i la de la distribució.
• grubx64.efi és GRUB pròpiament dit, signat per Canonical.
• mmx64.efi (MokManager) gestiona les claus pròpies, i és el que permet signar un mòdul del nucli propi (rellevant amb DKMS, que veuràs a 07-03).

Les entrades d'arrencada no són al disc, sinó a la NVRAM de la placa, i es gestionen amb efibootmgr:

BootOrder és l'ordre en què el microprogramari prova les entrades. Poder reordenar-lo o crear una entrada nova des del sistema en marxa és el que salva la situació quan un altre sistema operatiu, o una actualització de microprogramari, ha deixat la teva entrada al final o l'ha esborrada:

Un advertiment real: efibootmgr escriu a la NVRAM de la placa, i en alguns equips —sobretot portàtils de consum— un ús incorrecte ha arribat a deixar la placa inservible. En una VM és completament inofensiu, i és allà on has de practicar.

GRUB (GRand Unified Bootloader) resol un problema que el microprogramari no pot: saber llegir sistemes de fitxers de Linux, entendre LVM i RAID, presentar un menú, i carregar un nucli amb els paràmetres adequats.

L'avís és literal i cal prendre-se'l així: grub.cfg es genera, i qualsevol canvi manual desapareix en la següent actualització del nucli, que executa update-grub com a part del seu script de mantenidor. Les dues fonts reals són:

• /etc/default/grub: els ajustos en format clau-valor.
• /etc/grub.d/: els scripts que generen cada secció del menú.

Les directives que de debò es toquen en un servidor:

I la regla operativa, amb la convenció del curs:

Fixa't que en troba dos, de nuclis. Això no és casual i és una xarxa de seguretat important: si una actualització del nucli trenca alguna cosa —un controlador que desapareix, un mòdul de tercers incompatible—, el menú de GRUB t'ofereix l'anterior. La configuració que ho garanteix:

Ubuntu conserva per defecte els nuclis necessaris i apt autoremove neteja els antics. L'error a evitar és esborrar-los a mà per alliberar espai a /boot quan s'omple: si et quedes amb un de sol i aquell falla, no hi ha on tornar. La solució correcta quan /boot s'omple és sudo apt autoremove --purge, que respecta el nucli en ús i l'anterior.

Els scripts s'executen en ordre numèric i cadascun aporta la seva part al grub.cfg. 10_linux genera les entrades dels nuclis instal·lats, 30_os-prober detecta altres sistemes operatius, i 40_custom és on es posen les entrades pròpies — perquè és l'únic que no es regenera.

Per consultar el menú actual sense reiniciar:

Aquesta és la baula que menys s'entén i la que més problemes causa. El problema que resol és un cercle viciós:

Per muntar el sistema de fitxers arrel, el nucli necessita el controlador del controlador de disc, el mòdul del sistema de fitxers, i —a srv-tramontana— els mòduls d'LVM i de LUKS, més les utilitats lvm i cryptsetup. Però tot això és dins del sistema de fitxers arrel que encara no pot muntar.

L'initramfs trenca el cercle: és un arxiu comprimit amb un sistema de fitxers mínim que GRUB carrega a memòria juntament amb el nucli. El nucli el munta com a arrel temporal, executa el seu script d'arrencada, que carrega els mòduls, desbloqueja LUKS, activa els volums LVM i munta l'arrel real; i aleshores fa switch_root per canviar-hi i executar el systemd de debò.

Que cryptsetup i lvm hi siguin no és automàtic: els scripts d'initramfs-tools els inclouen perquè llegeixen /etc/crypttab i /etc/fstab en el moment de generar l'initramfs. I d'aquí en surt la regla operativa més important d'aquest apartat:

Després de tocar /etc/crypttab, la configuració d'LVM o l'esquema de discos d'arrencada, cal regenerar l'initramfs. Si no, el sistema arrencarà amb un initramfs que no sap res del canvi i es quedarà a l'indicador (initramfs).

El -k all és el que salva: si només regeneres l'actual i després necessites arrencar amb l'anterior, et trobes la mateixa fallada des de l'altre nucli.

La configuració viu a /etc/initramfs-tools/:

MODULES=most inclou una selecció àmplia de controladors; MODULES=dep inclou només els que la màquina actual necessita, i produeix un initramfs molt més petit — a canvi que deixi d'arrencar si mous el disc a un altre maquinari. En un servidor virtual estable pot tenir sentit; com a valor per defecte, most és l'elecció prudent.

Quan GRUB carrega vmlinuz, aquest es descomprimeix i pren el control del maquinari de debò: detecta CPU i memòria, inicialitza el planificador, munta /proc i /sys, carrega els controladors integrats i executa l'initramfs.

Els paràmetres amb què es va arrencar queden registrats i es poden consultar:

Aquell fitxer és la primera cosa que cal mirar quan l'arrencada es comporta de forma inesperada: diu amb què es va arrencar realment, no amb què et penses que es va arrencar. Un single, un nomodeset o un init= oblidat a GRUB_CMDLINE_LINUX hi apareixen.

I dmesg és el diari del nucli durant l'arrencada:

Poder consultar l'arrencada anterior és exactament la raó per la qual a 05-06 vas fer persistent el journal. Sense /var/log/journal, -b -1 no existeix i el diagnòstic d'una arrencada fallida es perd en reiniciar.

Al final de la seva inicialització, el nucli executa el procés init —avui /sbin/init, que és un enllaç a systemd— i li lliura el control com a PID 1. Des d'aquell moment el nucli només atén crides al sistema; l'arrencada la dirigeix l'espai d'usuari.

Ja coneixes systemd des de 05-05: unitats, dependències, temporitzadors. El que hi afegeix aquesta lliçó és el seu paper com a director de l'arrencada.

systemd activa default.target i, cap enrere, tot el que aquest necessita:

Els targets que cal conèixer, perquè són els que es fan servir en recuperació:

I les dues eines d'anàlisi de l'arrencada:

La diferència entre les dues és conceptual i decideix on optimitzar: blame ordena per temps que va trigar cada unitat, i critical-chain mostra la cadena de dependències que determina el temps total. snapd.service triga 2 segons, però no és a la cadena crítica: arrenca en paral·lel i no endarrereix res. En canvi systemd-networkd-wait-online sí, i allà sí que val la pena investigar.

Els paràmetres que GRUB passa al nucli són la palanca d'intervenció en l'arrencada. Els que cal conèixer:

El primer consell pràctic de recuperació és el més simple: treure quiet splash. La pantalla d'arrencada bonica amaga precisament els missatges que et dirien on es va trencar.

Al menú de GRUB, amb l'entrada seleccionada, la tecla e obre l'editor. És un editor efímer: els canvis afecten només aquesta arrencada i no toquen res del disc. És la propietat que el fa segur per experimentar.

El procediment:

1. Encén la VM i, si el menú no apareix, mantén premuda Shift (BIOS) o prem Esc repetidament (UEFI).
2. Selecciona l'entrada d'Ubuntu i prem e.
3. Localitza la línia que comença per linux /vmlinuz-....
4. Modifica el que necessitis al final d'aquella línia.
5. Ctrl+X o F10 per arrencar amb aquells paràmetres.

La línia original i les tres variants més útils:

rescue és el que es fa servir el 90 % de les vegades: tens els sistemes de fitxers muntats i les eines disponibles. emergency és per quan el problema és al muntatge mateix —un fstab trencat és el cas típic—, i allà el primer és fer escrivible l'arrel:

init=/bin/bash és el recurs més potent: substitueix PID 1 per una shell, així que systemd no arriba a executar-se. Serveix quan el problema és a systemd o a l'autenticació mateixa.

I té dues peculiaritats que desconcerten la primera vegada:

El PATH no està configurat, perquè no ha corregut cap script d'inici. S'arregla a mà:

I l'arrel està en només lectura, perquè el paràmetre ro continua vigent i ningú no l'ha remuntada:

En acabar, i això és important: no reiniciïs amb reboot, perquè no hi ha systemd per atendre la petició i les dades poden quedar sense sincronitzar. La seqüència correcta:

Un escenari clàssic, i una demostració incòmoda de per què l'accés físic —o a la consola de l'hipervisor— equival al control del sistema:

La lliçó de seguretat que cal extreure'n: qualsevol amb accés a la consola de la màquina pot fer això en dos minuts. Les contramesures —contrasenya a GRUB amb grub-mkpasswd-pbkdf2, xifratge complet del disc amb LUKS incloent-hi /boot, Secure Boot, i control d'accés físic— són precisament les que al model d'amenaces de 06-06 van quedar fora d'abast. Ara entens per què aquella decisió havia de ser explícita.

El provocaràs a propòsit, perquè és la fallada més comuna després d'un canvi de discos i perquè a 06-05 vas modificar fstab per al volum LUKS.

En arrencar, en lloc de l'indicador d'inici de sessió apareix:

Això és exactament el que mount -a hauria evitat. El diagnòstic i la reparació:

I les dues lliçons, que cal anotar al manual d'operació (runbook):

1. mount -a abans de reiniciar, sempre. És una comprovació de dos segons que evita aquesta situació.
2. nofail en tot muntatge que no sigui imprescindible per arrencar. Amb nofail, un dispositiu absent produeix un avís al journal i el sistema arrenca. És exactament per això que la línia del volum de còpies el porta:

Una fallada diferent i més profunda: l'initramfs no ha aconseguit muntar l'arrel.

Les causes, amb la seva comprovació:

Si el pas 4 funciona, saps que el disc i el sistema de fitxers estan bé i que el que falta és a l'initramfs o al crypttab. S'arrenca amb el nucli anterior des del menú de GRUB —l'initramfs del qual és el d'abans del canvi— i es regenera:

És la raó per la qual conservar dos nuclis és una mesura de recuperació, no un malbaratament d'espai.

L'escenari més greu: GRUB no apareix en absolut. El microprogramari no troba res per arrencar, o arrenca directament un altre sistema. Passa després d'instal·lar un altre sistema operatiu, després de clonar un disc, o després d'una actualització de microprogramari que va esborrar l'entrada de la NVRAM.

Es resol arrencant des d'un mitjà extern (l'ISO d'Ubuntu en mode Try Ubuntu), muntant el sistema instal·lat i entrant-hi amb chroot — que és l'operació conceptualment interessant d'aquesta lliçó, perquè és la mateixa primitiva sobre la qual es construeixen els contenidors de 07-05.

Aquell quart muntatge és el que fa fracassar la meitat dels intents de reparació de GRUB a UEFI: sense efivars accessible en escriptura, grub-install no pot crear l'entrada d'arrencada i avorta amb un error que no explica la causa.

L'ordre invers en desmuntar no és una formalitat: desmuntar /mnt abans de /mnt/dev falla amb target is busy, i forçar-ho pot deixar el sistema de fitxers marcat com a brut.

Per a un sistema amb BIOS/MBR en lloc d'UEFI, el pas 5 canvia i els muntatges d'efivars no s'apliquen:

• Editar /boot/grub/grub.cfg a mà. El fitxer ho diu a la tercera línia. Els canvis desapareixen en la següent actualització del nucli. S'edita /etc/default/grub i s'executa update-grub.
• Oblidar update-grub o update-initramfs després d'un canvi. Editar /etc/default/grub sense update-grub no fa res. Tocar crypttab o LVM sense update-initramfs -u -k all produeix l'indicador (initramfs) en la següent arrencada.
• Regenerar l'initramfs només del nucli actual. Si després necessites arrencar amb l'anterior, et trobes la mateixa fallada. Sempre -k all.
• Esborrar nuclis antics a mà per alliberar /boot. Quedar-te amb un de sol elimina la teva xarxa de seguretat. Fes servir apt autoremove --purge, que respecta el nucli en ús i l'anterior.
• Muntatges sense nofail a fstab. Un dispositiu absent impedeix arrencar. Només l'arrel i /boot han de poder bloquejar l'arrencada.
• No executar mount -a abans de reiniciar. És la comprovació de dos segons que separa un avís d'una sessió en mode emergència amb la consola de l'hipervisor.
• GRUB_TIMEOUT_STYLE=hidden en un servidor. Un menú ocult no es pot fer servir per intervenir. I GRUB_TIMEOUT=0 és pitjor: elimina la possibilitat de recuperació per menú.
• Deixar quiet splash en diagnosticar. Treu-los: els missatges que amaguen són exactament els que diuen on falla.
• Oblidar --bind /sys/firmware/efi/efivars al chroot. grub-install falla a UEFI amb un error poc descriptiu. És la causa més comuna de reparacions fallides.
• Reiniciar amb reboot des d'init=/bin/bash. No hi ha systemd que atengui la petició. sync, remuntar en només lectura, i exec /sbin/init o echo b > /proc/sysrq-trigger.
• Consell de mètode. Practica els tres procediments —fstab trencat, contrasenya de root, reinstal·lar GRUB— al laboratori i amb instantània prèvia, avui, amb calma. La primera vegada que els necessitis serà a les 3 de la matinada amb un servei caigut, i aquell no és moment d'aprendre.

Provoca deliberadament l'indicador (initramfs) al teu laboratori i recupera'l. Parteix del fet que /srv/tramontana/backups està xifrat amb LUKS i la seva clau es declara a /etc/crypttab. Descriu el canvi que provoca la fallada, per què el sistema no arrenca, com el diagnostiques des de l'indicador de BusyBox, i les dues maneres de recuperar-lo.

L'arrencada de srv-tramontana triga 47 segons, quan abans en trigava 12. Descriu el procediment de diagnòstic fent servir les eines de systemd, explicant quina informació aporta cadascuna i com distingeixes una unitat lenta que no importa d'una que sí.

La Marta et demana un procediment escrit de recuperació de l'arrencada per al manual d'operació, que pugui seguir algú que no siguis tu. Redacta'l com un arbre de decisió: què observar, què preguntar-se i què fer a cada branca, cobrint els quatre escenaris que has vist a la lliçó.

Solució 1

Provocar la fallada. L'escenari realista és un canvi a crypttab sense regenerar l'initramfs. Com que el volum xifrat és el de còpies i porta nofail, perquè la fallada sigui d'arrencada cal tocar alguna cosa que sí que la bloquegi. La manera neta de reproduir-ho és eliminar els mòduls de LUKS i LVM de l'initramfs:

Per què no arrenca. L'initramfs és l'únic entorn que existeix abans de muntar l'arrel, i el seu script d'arrencada necessita cryptsetup per desbloquejar el volum LUKS i lvm per activar els volums lògics. En no estar-hi inclosos —perquè crypttab estava buit quan es va generar—, l'script no troba el dispositiu arrel, espera el temps màxim i cau a la shell de BusyBox. És el cercle viciós de l'apartat de l'initramfs en la seva forma més pura: les eines per muntar l'arrel són dins de l'arrel que no es pot muntar.

Diagnòstic des de BusyBox. Descartant de fora cap a dins:

El disc i les seves tres particions hi són. Descartat el controlador.

Sense sortida: aquí està la causa. Cap de les dues no és a l'initramfs.

El sistema està intacte. El problema és exclusivament de l'initramfs, que és la conclusió que orienta la reparació.

Les dues maneres de recuperar-lo.

Manera A — arrencar amb el nucli anterior (la ràpida). L'initramfs del nucli 6.8.0-39 es va generar abans del canvi, així que continua complet... llevat que hagis fet servir -k all, que és exactament el que vam fer. Si l'update-initramfs hagués estat només de l'actual, aquesta seria la sortida en trenta segons: menú de GRUB → Advanced options → nucli 6.8.0-39 → arrenca → regenerar. La lliçó és doble: -k all és el correcte per no deixar un nucli trencat, però significa que un error de configuració afecta tots els nuclis alhora. Per això la comprovació (lsinitramfs | grep cryptsetup) va abans del reinici, no després.

Manera B — chroot des d'un mitjà de rescat (la que sempre funciona).

I les dues conclusions que van al manual d'operació: les còpies .bak-$(date +%F) de la convenció del curs són el que va fer trivial la reparació —sense elles caldria reconstruir la configuració de memòria—, i la verificació amb lsinitramfs va abans del reinici, no després. El patró és idèntic al mount -a de fstab: comprovar al sistema en marxa el que només es manifestaria en arrencar.

Solució 2

El procediment comença per separar l'arrencada del nucli de l'arrencada de l'espai d'usuari, perquè són problemes diferents:

El nucli triga el mateix de sempre (3,4 s); els 35 segons extra són a l'espai d'usuari. Això descarta maquinari, controladors i initramfs, i centra la cerca en les unitats de systemd.

blame dona el sospitós, però no n'hi ha prou, i aquí està el contingut de l'exercici: una unitat lenta només importa si és a la cadena crítica. Cal comprovar-ho:

Confirmat. systemd-networkd-wait-online és a la cadena, triga 35 s, i arrossega tot el que depèn de la xarxa: PostgreSQL espera network-online.target, i tramontana.service espera PostgreSQL. Els 35 s es propaguen íntegres al total.

El contrast que demana l'enunciat el dona snapd.service: triga 2 segons i no apareix a la cadena crítica, perquè arrenca en paral·lel i res no l'espera. Optimitzar-lo no estalviaria ni una dècima del temps total. Aquesta és la diferència entre les dues eines:

La causa arrel, amb el journal:

Aquí està: virbr0, el pont de libvirt, està configured però sense enllaç, perquè no hi ha cap màquina virtual arrencada connectada a ell. systemd-networkd-wait-online espera per defecte que totes les interfícies gestionades estiguin en línia, i aquella no ho estarà mai. Els 35 segons són el seu temps d'espera màxim esgotant-se.

La correcció és dir-li quina interfície importa de debò:

L'ExecStart= buit abans del nou és obligatori: sense ell, systemd afegeix una segona ordre en lloc de substituir la primera, i la unitat falla. És el mateix mecanisme de reinicialització de llista que vas veure amb SystemCallFilter a 06-06.

I la verificació, amb la disciplina de mesurar abans i després:

De 47 s a 12,5 s, i el servei verificat. I una reflexió de mètode: el símptoma («l'arrencada triga més») va aparèixer després d'instal·lar libvirt, i ningú no va relacionar les dues coses. Anotar al manual d'operació el temps d'arrencada com a part de la línia base de 05-07 és el que converteix «em sembla que va més lent» en una dada amb data.

Solució 3

MANUAL D'OPERACIÓ — Recuperació de l'arrencada de srv-tramontana Versió 1.0 · 18 d'agost de 2026 · Autor: Operacions de sistemes Aquest document es guarda FORA del servidor. Còpia al portàtil d'administració i al gestor de contrasenyes de l'equip.

Requisits previs. Accés a la consola de la màquina a VirtualBox (no val SSH: si no arrenca, no hi ha xarxa). Contrasenya de root, disponible a pass tramontana/produccio/root. ISO d'Ubuntu Server 24.04 accessible per al cas 4.

---

PAS 0 — L'única pregunta que importa: fins on va arribar?

Encén la màquina i observa. No toquis res encara. Anota l'hora i el que veus a la pantalla.

El que veus	Es va trencar a	Ves al cas
Pantalla negra, sense logotip, sense menú	Microprogramari o GRUB	Cas 4
Menú de GRUB, però no passa d'aquí	GRUB o nucli	Cas 4
Indicador (initramfs)	initramfs	Cas 3
Missatges d'arrencada i després emergency mode	Muntatge de sistemes de fitxers	Cas 1
Arrenca però no pots entrar	Autenticació	Cas 2
Arrenca, però molt lent	Cap; és una unitat lenta	Cas 5

---

CAS 1 — «You are in emergency mode» (el més freqüent)

Gairebé sempre és /etc/fstab, després d'un canvi de discos.

1. Prem Enter i introdueix la contrasenya de root.
2. Identifica què va fallar: systemctl --failed
3. Llegeix la causa: journalctl -xb | tail -30
4. Fes escrivible l'arrel: mount -o remount,rw /
5. Corregeix /etc/fstab amb nano. Si dubtes, comenta la línia sospitosa anteposant-hi #: és reversible i et torna el servei.
6. Verifica sense reiniciar: systemctl daemon-reload && mount -a
   • Sense errors → pas 7.
   • Amb errors → torna al pas 5. No reiniciïs amb mount -a fallant.
7. Continua l'arrencada: systemctl default
8. Comprova el servei: /home/operador/scripts/revisio_salut.sh (ha de retornar 0).

Nota: si la línia problemàtica és de /srv/tramontana/backups, hauria de portar nofail i no bloquejar l'arrencada. Si la va bloquejar, afegeix-hi nofail com a part de la correcció.

---

CAS 2 — Arrenca però no es pot iniciar sessió

1. Reinicia. Al menú de GRUB, amb l'entrada d'Ubuntu seleccionada, prem e. (Si el menú no apareix: mantén Shift o prem Esc repetidament en encendre.)
2. A la línia que comença per linux /vmlinuz-, canvia ro per rw i afegeix al final: init=/bin/bash
3. Ctrl+X per arrencar.
4. A l'indicador bash-5.2#:

   export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
   mount -o remount,rw /
   passwd root                  # o: passwd operador
   

5. Si la causa va ser un canvi a PAM (/etc/pam.d/), restaura la còpia: cp /etc/pam.d/common-auth.bak-<data> /etc/pam.d/common-auth
6. Sortida neta — no facis servir reboot, no hi ha systemd:

   sync
   exec /sbin/init
   

---

CAS 3 — Indicador (initramfs)

Sol venir d'un canvi a crypttab, LVM o discos sense regenerar l'initramfs.

1. Comprova si el nucli veu el disc: cat /proc/partitions
   • No apareix el disc → problema de maquinari o de controlador. Escala; comprova la configuració d'emmagatzematge de la VM.
   • Apareix → continua.
2. Comprova si hi són les eines: which cryptsetup lvm
   • Sense sortida → falta a l'initramfs. Ves al pas 4.
3. Intenta muntar a mà per confirmar que les dades estan bé:

   lvm vgchange -ay
   mkdir /arrel && mount -o ro /dev/mapper/<volum> /arrel && ls /arrel
   

4. Recuperació ràpida: reinicia, i al menú de GRUB entra a Advanced options for Ubuntu i tria el nucli anterior. Si arrenca:

   sudo update-initramfs -u -k all
   sudo lsinitramfs /boot/initrd.img-$(uname -r) | grep -c sbin/cryptsetup   # ha de donar 1
   

5. Si el nucli anterior tampoc no arrenca: ves al Cas 4 (chroot) i executa-hi les ordres del pas 4.

---

CAS 4 — No hi ha GRUB, o res del que hi ha abans no funciona: chroot de rescat

Procediment universal. Requereix l'ISO d'Ubuntu 24.04 muntat a la VM i arrencar en mode Try Ubuntu.

1. Identifica les particions: lsblk -f Referència de srv-tramontana: sda1 = ESP (FAT32), sda2 = /boot, sda3 = arrel.
2. Munta, en aquest ordre:

   sudo mount /dev/sda3 /mnt
   sudo mount /dev/sda2 /mnt/boot
   sudo mount /dev/sda1 /mnt/boot/efi
   for d in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do
       sudo mount --bind "$d" "/mnt$d"
   done
   

   ⚠️ efivars no és opcional. Sense ell, grub-install falla a UEFI amb un error poc clar.
3. Entra: sudo chroot /mnt /bin/bash
4. Repara el que correspongui:

   grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu --recheck
   update-grub
   update-initramfs -u -k all
   efibootmgr -v | grep -i ubuntu      # ha d aparèixer l entrada
   

5. Sortida neta, desmuntant en ordre invers:

   exit
   for d in /run /sys/firmware/efi/efivars /sys /proc /dev/pts /dev; do
       sudo umount "/mnt$d"
   done
   sudo umount /mnt/boot/efi /mnt/boot /mnt
   sudo reboot
   

---

CAS 5 — Arrenca, però triga molt més del normal

No és una emergència. Referència normal: ~12 segons.

1. systemd-analyze → separa nucli d'espai d'usuari.
2. systemd-analyze critical-chain → aquesta és la que importa, no blame: una unitat lenta que arrenca en paral·lel no endarrereix el total.
3. journalctl -b -u <unitat> → la causa concreta.
4. Corregeix amb un drop-in a /etc/systemd/system/<unitat>.d/override.conf, mai editant la unitat original. Si substitueixes un ExecStart, recorda la línia ExecStart= buida abans.
5. Reinicia i torna a mesurar. Anota el nou temps a la línia base.

---

REGLES QUE EVITEN ELS QUATRE PRIMERS CASOS

Abans de…	Fes sempre
Reiniciar després de tocar fstab	mount -a i comprovar que no dona error
Reiniciar després de tocar crypttab, LVM o discos	update-initramfs -u -k all i verificar amb lsinitramfs | grep cryptsetup
Tocar PAM o sshd_config	Segona sessió oberta; validar amb sshd -t; reload, no restart
Qualsevol canvi de configuració	Còpia .bak-$(date +%F) i diff -u després
Qualsevol mòdul delicat	Instantània de la VM, numerada

Mai: GRUB_TIMEOUT=0, GRUB_TIMEOUT_STYLE=hidden, esborrar nuclis a mà, ni muntatges sense nofail llevat de l'arrel i /boot.

Si res no funciona. No improvisis més de 30 minuts. Reconstrueix: l'RTO acordat és de 8 hores, el manual de reconstrucció és en aquest mateix document, i les dades són a restic amb restauració provada. Avisa Operacions abans de començar.

Ja no arrenques un servidor: saps què passa quan ho fas. Coneixes la cadena completa —microprogramari UEFI, l'ESP i efibootmgr, GRUB amb les seves fonts reals de configuració, l'initramfs i el cercle viciós que resol, el nucli i el seu pas de control a PID 1, i systemd activant default.target— i, sobretot, saps fer servir aquella cadena com a eina de diagnòstic: la primera pregunta davant d'un servidor que no arrenca és sempre fins on va arribar. Has intervingut al menú de GRUB, has distingit rescue d'emergency, has arrencat amb una shell com a PID 1 i has entès per què l'arrel està en només lectura. Has reparat un fstab trencat —l'escenari que 05-04 va deixar anunciat—, has recuperat una contrasenya de root en dos minuts (i amb això has vist per què l'accés físic quedava fora del model d'amenaces de 06-06), i has reinstal·lat GRUB des d'un mitjà de rescat amb el chroot complet, inclòs el --bind d'efivars que fa fracassar la meitat dels intents. El manual d'operació té ara un arbre de decisió que pot seguir algú que no siguis tu, que és la definició d'un procediment útil.

I pel camí has fet servir chroot per entrar en un sistema de fitxers aliè i executar-hi programes com si fos l'arrel. Recorda-ho: és la primitiva sobre la qual es construeix tot el que veuràs a 07-05, quan descobreixis que un contenidor no és una màquina petita.

Saps mirar l'arrencada, però encara no saps mirar dins d'un procés en marxa. Al Mòdul 5 vas aprendre a mesurar amb el mètode USE: vmstat, iostat, free, sar et diuen que la CPU està al 80 %, que el disc té latència alta o que la memòria s'esgota. Això respon a quant, però no a què. Quan revisio_salut.sh comenci a retornar 1 perquè l'aplicació triga 400 ms a respondre en lloc de 40, i els comptadors diguin que la CPU està ociosa, el disc tranquil i la memòria de sobres, necessitaràs una altra classe d'eines. A la lliçó 07-02: Diagnòstic Avançat aprendràs a preguntar al sistema què està fent exactament un procés: strace per veure les seves crides al sistema una per una —tancant el cercle amb les capes del Mòdul 1—, perf per perfilar on consumeix cicles de debò i llegir un gràfic de flama, i eBPF amb bpftrace i les eines de bpfcc-tools per instrumentar el nucli en producció sense el cost prohibitiu d'strace. I et trobaràs de cara amb una conseqüència de la teva pròpia feina: el kernel.yama.ptrace_scope = 1 que vas aplicar a 06-06 t'impedirà adjuntar-te als teus propis processos, i entendre per què això està bé és part de la lliçó.