Open Source Experience
Negli ultimi tempi mi rendo conto di essere diventato un po’ più friendly nei confronti dell’Open Source; infatti sul mio Cray 1 ci gira Linux con un Pool ZFS nativo e gingillerie varie. Trovo tuttora tale configurazione estremamente economica per conservare i file più cari. Foto, ricordi, diapositive del tempo che passa.
Ritengo invece, in tutta la questione, che sia rimasta un’invariante, ovvero la necessità non tanto remota di doversi spesso e volentieri sporcarsi le mani con il codice scritto da altri che sempre molto più spesso ha il sapore del tabacco da masticare.
L’ultimo episodio si è verificato con l’upgrade di Ubuntu dalla versione 16.04 alla 18.04. Accedere al Pool ZFS causa un soft kernel panic. Ho cercato in giro qualcosa che somigliasse allo stack trace nel log di sistema ma niente.
Ho aperto un baco due mesi fa ma nessuno se l’è filato. Nel frattempo il mio sistema mi invita sempre più sovente a fare l’upgrade alla nuova fiammante 18.04.1 proponendomi un comando in grado di compiere l’operazione in un sol colpo. Sono quasi pronto per accettare l’offerta ma la paranoia ha il sopravvento. Colpo di fortuna scopro un altro sfigato affetto dallo stesso identico baco ma con ZFS debugging skill a livello di terzo dan in grado di fare un po’ di luce sulla questione.
Il baco è dovuto ad una ACL invalida ereditata dai tempi in cui il Pool girava su Solaris/OpenIndiana. Quale sia l’oggetto della questione è un mistero quasi facile da risolvere. Basta aggiungere cinque righe di debug per avere un objectid e la speranza di venirne a capo. Nel frattempo ho provato ad azzerare le ACL semplicemente spostando tutti i file, senza successo. La ACL maledetta, come già sospettavo, si annida a livello molto basso altrimenti non sarebbe in grado di mandare in crash il sistema durante l’operazione di import.
Seguo i suggerimenti di qualche developer che nel frattempo a fronte di informazioni estremamente più puntuali ha deciso di prendere a cuore la questione. A leggere le guide disponibili in giro, compilare un modulo di sistema sembrerebbe abbastanza indolore. E così scarico e modifico codice non scritto da me, per fortuna in un linguaggio familiare. Ma la patch non funziona e il codice compila anche se cancello il file per intero. Mi spiegano che su Ubuntu i moduli centrali di ZFS sono integrati nel kernel e quel codice di cui parte inutilizzata è serve solo a compilare i tool di alto livello; e che se voglio testare la patch tocca seguire una guida abbastanza complicata; oppure installare una distro che distribuisca ZFS in formato sorgente che sono quasi tutte: Debian - che però è una decina di release indietro - e poi Fedora, Red Hat, ecc. Oppure installare ZFS su Ubuntu usando DKMS anziché il repository di default. Cosa che però non funziona, per ovvi motivi, con una distro live o con i pacchetti installati sul mio server basato sulla 16.04 di default.
A questo punto non mi resta che provare nell’ordine a:
- installare Ubuntu 18.04 su una chiavetta USB e sperare di riuscire a metterci la pezza
- provare la pezza su una distro diversa
- in estrema ratio ricreare il pool ex-novo; operazione già da tempo nella mia to-do list per conformità alla “rules of three of backup”
Certo è che la pressione di sapere di non poter fare l’upgrade del sistema all’ultima versione si fa ogni giorno più pesante.
Open Source = you debug it
Se sia nello specifico sia stato un bene o un male è troppo presto per determinarlo. Auguratemi buona fortuna.
-quack
P.S. seguirà un post separato su come abbia perso i contenuti di un folder a causa di come sia stato implementato il comando mv in GNU Linux