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.
Contenuto
- Perché, in generale
- La lezione è arrivata prima dell’hardware
- Primo: il cavo piatto era montato al contrario
- Secondo: una dimensione del disco negativa
- La mia seconda teoria, e perché era sbagliata
- Quattro vicoli ciechi solo per arrivare al disco
- L’errore di ragionamento che ha ribaltato il piano
- La strada che ha funzionato
- Due inciampi
- Cosa ne è venuto fuori di passaggio
- Stato successivo
- E quindi?
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
-etmlì 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ì:
- scrivere direttamente sopra Home Assistant OS
- avviare il Pi normalmente
- ripristinare il backup
- 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:
- 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.
- Pianifica la migrazione prima che la scheda si stanchi. I file di database corrotti sono il primo segnale, non l’ultimo.
- 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.
- 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.
Se vuoi seguire tutto questo: usa RSS
Niente newsletter. Non mi dai un indirizzo, non tengo liste e nessuno deve acconsentire a nulla per sapere che un articolo è pronto. RSS è la soluzione più vecchia e, per entrambe le parti, la più onesta.
Come si fa, e perché niente newsletter
- 1Procurati un lettore di feed. Senza account con un’app sul telefono o un’estensione del browser; chi preferisce usa un servizio con account.
- 2Inserisci lì l’indirizzo qui sopra.
- 3Fatto. I nuovi articoli compaiono da soli nel tuo lettore — ciò che non leggi resta non letto, e niente finisce tra fatture e pubblicità nella posta.
Perché è meglio: il tuo lettore scarica il file. Io non ricevo nessun indirizzo e non posso vedere chi legge né se qualcuno ha aperto. Disiscriversi vuol dire cancellare la voce — senza link, senza mail di conferma, senza di me.
