Boota o non boota, qvesto è il problema

Se avete acquistato di recente una memoria SSD PCIe NVMe, nel leggere documentazione e forum vari vi sarete sicuramente imbattuti nell’interrogativo categorico riguardo questi dispositivi: boota o non boota?

Fuori dall’eden del plug-and-play

Non più nel comodo orticello SATA, molti utenti enthusiast si sono accorti di come i nuovi dispositivi mal supportino, sulla maggior parte delle schede madri, l’avvio diretto del sistema operativo, rendendoli di fatto molto meno appetibili agli appassionati (e non) che non possiedono schede madri dell’ultima generazione e un SSD compatibile.

Ebbene, questo è un problema che riguarda solamente gli utenti Windows. Vi siete mai chiesti perché Linux consigli di utilizzare una partizione segregata per /boot? Un retaggio dei vecchi UNIX, che torna sempre comodo…

Quasi tutte le architetture non-intel difatti, NON supportano (o non supportavano) il boot del sistema operativo dai dispositivi di storage “di lavoro”; il software necessario ai primi stages d’avvio viene invece caricato in speciali partizioni hardware (a mo’ di firmware) e copiato in RAM direttamente dal BIOS o suoi sostituti. Una implementazione di questa idea si può ad esempio trovare nell’Initial Program Load (IPL) delle macchine POWER IBM.

La multiforme bootabilità del pinguino

Torniamo alle nostre macchine x86 con NVMe: partiamo dal presupposto che non appena venga bootato il kernel Linux, il resto del sistema possa stare su qualunque, e dico QUALUNQUE cosa venga riconosciuta dal kernel, fosse anche una cassettina a nastro collegata via rete da una località remota… attualmente, credo proprio che tutte le schede NVMe presenti sul mercato siano supportate dal kernel 3.10 in poi.

Come caricare il kernel (ricordiamolo, sta nella partizione /boot) in memoria allora? Manca solamente un dispositivo che venga riconosciuto come boot device standard e che sia

  • economico: abbiamo già speso i soldi per la nostra NVMe;
  • affidabile: niente riutilizzo di vecchi dischi meccanici!
  • non troppo grande: la partizione di /boot può benissimo essere <1Gb.

Una penna, una penna, il mio regno per una penna!

La soluzione ci giunge da una pratica comune a parecchi setup raid software: bootare da una penna USB! Più precisamente, all’installazione del sistema basterà scegliere di installare MBR e partizione /boot sul succitato pendrive. Pensate che la penna USB sia un SPOF? E allora fate un’immagine della USB e la copiate su un’altro dispositivo, che potreste ad esempio tenere offline.

La stessa immagine potete tenerla da qualche altra parte per poterne sempre fare copie addizionali; dovrete solamente ricordare di aggiornare le copie dopo un aggiornamento del kernel (la cosa avviene abbastanza di rado) per evitare ogni problema di incompatibilità, ma in generale il vostro sistema dovrebbe avviarsi ugualmente anche con una /boot outdated se non cambiate i dispositivi di storage, o se vi riferite ad essi tramite UUID.

Questo disaccoppiamento dello storage potrà sembrarvi curioso, ma è una best practice consolidata nel mondo della virtualizzazione: questa modalità di avvio è comunissima e consigliata con tutti gli hypervisor embedded come ESXi o XenServer (molti server hanno appositi slot USB o SD interni), e comincia ad affermarsi anche per il deployment di container-OS immutabili.

Il trucco sta proprio nella natura principalmente read-only della partizione /boot: viene letta solamente all’avvio e scritta molto sporadicamente (solo per gli aggiornamenti), ed è noto come la vita delle memorie flash sia legata a doppio filo al numero di scritture sul dispositivo, più che alle letture.

Una scelta industry-standard

Come indicazione generale, comprate una chiavetta di buona qualità: trovate buoni devices delle principali marche per una decina di euro. Esistono anche dispositivi certificati per i vari hypervisor, che sono testati ed hanno una endurance pazzesca se utilizzati in sola lettura, ma difficilmente arriverete mai a percepire benefici sull’affidabilità.

Non siete ancora convinti? Continua a sembrarvi un setup molto strano? Beh è lo stesso (molto affidabile) setup di tutti i NAS consumer: il firmware (di solito una distro Linux) è scritto su una memoria a stato solido, generalmente una SD (ecco perché il firmware è aggiornabile!). Non pensavate mica che un NAS da 100€ avesse avanzati sistemi di mirroring delle ROM o chissà quale altra trovata magica, giusto?

È affidabile? Abbastanza. Se facciamo le copie della /boot altrove? Parecchio. Parecchio più dei NAS consumer ai quali affidate i vostri dati ogni giorno.