MeranoCosa è andato storto?Primi passi e gestione

La scheda SD è fuori — un giorno speso dalla parte sbagliata

Statistiche di lungo periodo cancellate due volte, quattro file di database corrotti. Il passaggio a una NVMe è costato un giorno e due teorie sbagliate.

La scheda SD del mio Raspberry Pi a Merano è fuori. Home Assistant gira su un SSD NVMe, 234 GB, di cui 210 liberi.

Per arrivarci: un giorno di lavoro dalla parte sbagliata, due errori di software altrui e due mie teorie rivelatesi sbagliate. Entrambe stanno in questo testo, perché sono quelle che sono costate tempo.

Perché, in generale

Le statistiche di lungo periodo mi sono state cancellate due volte. Entrambe le volte mancavano tutte le serie a partire dallo stesso momento — potenza totale, temperatura esterna, ogni sensore di valvola — ed entrambe le volte alla stessa ora esatta: le due di notte UTC, quando gira la pulizia notturna del registratore.

La seconda volta non era dimostrabilmente un aggiornamento. La versione era invariata. Era quindi qualcosa di ricorrente, all’incirca mensile, e conservava solo circa otto giorni di statistiche.

A questo si aggiungevano quattro file di database corrotti per complessivi 4 GB. Il sospetto cadeva su una scheda SD stanca.

La lezione è arrivata prima dell’hardware

Otto giorni di conservazione significano: salvare ogni settimana è obbligatorio, non facoltativo.

Il mio salvataggio nel repository funzionava — aveva salvato tutto fino all’ultima esecuzione. Solo che l’ultima esecuzione risaliva a sedici giorni prima. Le 180 ore intermedie sono perse definitivamente; nessun secondo posto le conserva.

Tra queste, gli unici dati con un ospite che arieggia diversamente da noi. Esattamente il tipo di serie che non si può ripetere.

Primo: il cavo piatto era montato al contrario

Dopo il montaggio il kernel non vedeva proprio nulla. Nessun nvme, nessun sda, solo la scheda SD.

Qui sono stato troppo frettoloso. Nell’elenco PCI comparivano due dispositivi e ne ho preso uno per il disco. Era il chip di I/O del Pi 5 stesso. Quello che mancava era la seconda porta PCIe — quella esterna non compariva affatto nel registro.

La soluzione era meccanica: girare il cavo piatto. Dopodiché:

nvme nvme0: pci function 0001:01:00.0
nvme0n1    250059096 blocchi  (256,06 GB)

L’indicazione di configurazione che avevo preso in via precauzionale da un wiki non serviva. Meno male che il cavo è venuto per primo.

Secondo: una dimensione del disco negativa

Il disco funzionava. La migrazione no:

Cannot use ... as data disk as it is smaller than
the current one (new: -1065472, current: 125064691200)

Una dimensione negativa. Il kernel misura correttamente, il sistema elenca il disco regolarmente — solo il livello di gestione riporta dimensione zero e poi calcola con uno zero.

Ed ecco l’osservazione che decide tutto: non è un problema di questo disco. Tre giorni prima lo stesso errore era stato segnalato con esattamente lo stesso numero — altro hardware, altra dimensione, lo stesso -1065472.

Una costante che non cambia con la dimensione del disco non viene dal disco.

È un criterio di verifica che mi sono tenuto. Se un messaggio di errore cita un numero e lo stesso numero compare su hardware altrui, quel valore non è misurato ma calcolato — a partire da qualcosa che manca.

La mia seconda teoria, e perché era sbagliata

Confrontando le proprietà dei dispositivi emergeva esattamente una differenza: la scheda SD aveva una tabella delle partizioni, il disco nuovo di fabbrica no.

L’ipotesi era ovvia: il livello di gestione ricava la dimensione dalla tabella delle partizioni, e su un disco nuovo di fabbrica non c’è nulla da cui ricavarla.

Era sbagliata. Dopo aver scritto un GPT la tabella c’era — e la dimensione è rimasta zero. Anche dopo un ricaricamento. Anche dopo un riavvio completo dell’host, con i servizi competenti che ripartono da zero e vedono il disco con la tabella fin dall’inizio.

La tabella mancante era un sintomo del disco nuovo di fabbrica, non la causa.

Quattro vicoli ciechi solo per arrivare al disco

Ognuno fa risparmiare tempo la prossima volta:

1. Il terminale ufficiale non ce la fa. L’accesso in scrittura risponde «Operation not permitted». Il motivo: non richiede alcun privilegio speciale. Per questo lì non c’è nemmeno un interruttore per la modalità protetta — non c’è nulla da sbloccare.

2. Nemmeno il terminale SSH avanzato ce la fa. Dichiara le capacità necessarie, ma il suo elenco di dispositivi non contiene il disco. Una capacità non serve contro un elenco in cui il dispositivo manca. Anche con la modalità protetta disattivata: stesso messaggio.

3. La porta è l’accesso al servizio container dell’host. Un container privilegiato di breve durata, con la directory dei dispositivi passata, vede il disco per intero.

4. Tre ostacoli lungo la strada:

  • Chiave host cambiata. Due componenti aggiuntivi sono due servizi SSH con chiavi proprie. L’avviso era autentico e spiegabile; la vecchia voce andava rimossa.
  • «Corrupted MAC on input». Il registro indicava l’offerta: solo varianti ETM. La forma senza -etm lì non esisteva.
  • Via SSH non si è root, mentre nel terminale web dello stesso componente sì. Da cui «Permission denied» sia sul disco sia sul servizio container.

L’errore di ragionamento che ha ribaltato il piano

Avevo intenzione di aspettare una correzione dell’errore sulla dimensione. Era il piano sbagliato, per un motivo che ho visto solo rifacendo i conti:

La funzione di migrazione incorporata sposta soltanto i dati. L’avvio del sistema sarebbe comunque partito dalla scheda SD.

Quindi anche una migrazione funzionante non avrebbe reso superflua la scheda — ed era proprio quella la domanda: cosa bisogna fare per poter togliere del tutto la scheda SD?

Aspettare mesi una correzione che non avrebbe risolto il problema: è l’errore più costoso dell’intera giornata, ed era puro ragionamento, non tecnica.

La strada che ha funzionato

Il Pi 5 può presentarsi come lettore di schede. Una piccola utility di avvio carica nel Pi un kernel minimale che passa le unità collegate — SD, eMMC, NVMe, USB — al computer collegato come normale memoria di massa USB.

La NVMe compare sul PC Windows come un’unità del tutto normale. Da lì:

  1. scrivere direttamente sopra Home Assistant OS
  2. avviare il Pi normalmente
  3. ripristinare il backup
  4. togliere la scheda SD

Quattro passi. Dopo che mezza giornata se n’era andata nel tentativo di farlo dall’interno.

Due inciampi

Il driver di Windows. Il dispositivo segnalava un’installazione driver fallita e richiedeva un’assegnazione manuale con privilegi elevati — eseguita quindi a mano, non dallo script.

Un tranello di PowerShell. Una variabile chiamata $gadget entrava in conflitto con il parametro -Gadget: PowerShell non distingue maiuscole e minuscole nei nomi di variabile. L’interruzione diceva «Cannot convert … to type SwitchParameter» e sulla causa non dice esattamente nulla. Da allora la variabile ha un altro nome.

Cosa ne è venuto fuori di passaggio

L’aggiornamento del sistema operativo che via rete non arrivava da settimane era semplicemente contenuto nell’immagine appena scritta.

La causa è curiosa: il servizio da cui si preleva l’aggiornamento invia da qualche settimana una policy di sicurezza di oltre 9 KB nelle intestazioni. La libreria di rete usata accetta al massimo 8190 byte e interrompe.

La deviazione non ha risolto il problema, lo ha aggirato. È una distinzione su cui vale la pena essere onesti quando si mette per iscritto — può tornare.

Stato successivo

Sistema operativo 18.3, scritto da zero
Disco 234 GB totali, 210 GB liberi
Scheda SD fuori
Quattro file di database corrotti risolti insieme — erano sulla scheda

A Kapfenberg lo stesso impianto gira su NVMe da tempo. La differenza non è mai stata una decisione ma una sequenza: lì il disco c’era fin dall’inizio, qui l’impianto è cresciuto su una scheda finché la scheda non ne ha avuto abbastanza.

E quindi?

Per te, se sei ancora su una scheda SD:

  1. Salva le statistiche di lungo periodo prima di averne bisogno. Otto giorni di conservazione sono otto giorni. Ciò che è perso è perso: non c’è una seconda copia.
  2. Pianifica la migrazione prima che la scheda si stanchi. I file di database corrotti sono il primo segnale, non l’ultimo.
  3. La funzione di migrazione incorporata non rende superflua la scheda. Sposta i dati, non l’avvio. Se l’obiettivo è «scheda fuori», la strada attraverso il computer è più breve.
  4. Controlla prima il cavo piatto. Si può montare al contrario e sembrare giusto lo stesso.

E una regola che va oltre questa giornata: se un messaggio di errore cita lo stesso numero su hardware altrui, non è il tuo hardware. Ho passato mezza giornata a cercare in un disco che non è mai stato il problema.