Da vecchio Chromebook a server Linux con Docker

1) Un computer quasi inutilizzabile può avere una seconda vita.

Avevo un vecchio Chromebook che ormai non funzionava più tanto bene. ChromeOS si bloccava, l’esperienza d’uso era diventata poco affidabile e lo schermo aveva alcuni evidenti difetti. Come portatile da usare tutti i giorni aveva sostanzialmente concluso la propria carriera.

La fotografia seguente mostra il mio Acer ancora nella schermata di benvenuto di ChromeOS. Si vedono il computer, la tastiera e soprattutto le alterazioni nella parte inferiore del pannello: fastidiose per lavorare davanti allo schermo, quasi irrilevanti per una macchina destinata a restare chiusa e a essere amministrata dalla rete.

Invece di buttarlo o lasciarlo in un cassetto, ho deciso di convertirlo in un piccolo server Linux. Ho installato postmarketOS, una distribuzione basata direttamente su Alpine Linux, e ho trasformato quel portatile malandato in una macchina capace di eseguire veri servizi dentro Docker.

Non si tratta soltanto di un esercizio da smanettoni. Alla fine il Chromebook ha preso in carico quattro applicazioni che prima gravavano sul mio Mac mini, permettendomi di spegnere Docker Desktop sul Mac e recuperare memoria e risorse. Il vecchio computer è così passato dall’essere un oggetto quasi inutile a un componente stabile della mia infrastruttura domestica e professionale.

2) Il modello esatto cambia completamente il progetto.

Il computer è un Acer Chromebook Spin 311 CP311-3H, identificato anche come N19Q10. Il nome della scheda è JUNIPER, appartenente alla famiglia KUKUI. Non è un normale portatile Intel: usa un processore MediaTek MT8183 con architettura ARM64, composto da quattro core Cortex-A53 e quattro Cortex-A72, per un totale di otto core. Ha 4 GB di RAM e, nel mio esemplare, 64 GB di memoria eMMC interna.

Questo dettaglio è decisivo. Sui Chromebook Intel o AMD si può spesso sostituire il firmware e installare Debian o Ubuntu con procedure abbastanza simili a quelle di un normale PC. Sul mio Acer ARM64, invece, il noto firmware UEFI di MrChromebox non era una strada disponibile. Nemmeno bastava preparare una comune chiavetta Ubuntu ARM e tentare l’avvio.

Prima lezione, quindi: «Chromebook» non identifica una piattaforma unica. Prima di scaricare qualsiasi immagine devi individuare modello, processore, nome della scheda e stato del supporto Linux. Nel mio caso la scheda ufficiale dell’Acer Chromebook Spin 311 su postmarketOS confermava esplicitamente il supporto per google-juniper attraverso il port generico google-kukui.

La stessa scheda indica come funzionanti schermo, touchscreen, tastiera, touchpad, accelerazione grafica, audio, fotocamera, Wi-Fi, Bluetooth, batteria e USB. L’unico difetto segnalato riguarda la rotazione automatica, funzione del tutto irrilevante per un server.

3) Perché proprio postmarketOS.

PostmarketOS nasce soprattutto per prolungare la vita di telefoni, tablet e altri dispositivi che i produttori hanno abbandonato. È però Linux vero, non una versione cosmetica di Android, e supporta anche numerosi Chromebook ARM che con le distribuzioni tradizionali sarebbero molto più difficili da recuperare.

È basato direttamente su Alpine Linux. Alpine è una distribuzione piccola, essenziale e molto diffusa nel mondo dei server e dei container. Il suo gestore dei pacchetti si chiama apk; postmarketOS aggiunge il lavoro necessario per far funzionare kernel, avvio, periferiche e particolarità dei dispositivi mobili o dei Chromebook.

La leggerezza era ideale per una macchina con 4 GB di RAM e una eMMC da 64 GB. Ho scelto l’immagine console, senza ambiente grafico: non avevo bisogno di finestre, animazioni o applicazioni desktop, ma soltanto di rete, SSH, Tailscale, Docker e servizi di sistema. La versione installata è postmarketOS v26.06, basata su Alpine Linux 3.24 e configurata con systemd.

Il progetto postmarketOS spiega apertamente che il sistema è rivolto ancora soprattutto agli appassionati e non offre sempre la rifinitura di Android o iOS. Per un piccolo server, però, l’essenzialità è un vantaggio. La filosofia del progetto — tenere in vita l’hardware finché funziona davvero — coincide perfettamente con quello che volevo ottenere. Nelle domande frequenti di postmarketOS trovi anche una spiegazione delle ragioni per cui è stato scelto Alpine Linux come base.

4) Prima di installare: modalità sviluppatore e cancellazione dei dati.

Per avviare un sistema alternativo è stato necessario portare il Chromebook in modalità sviluppatore. La procedura è specifica dei Chromebook e non va iniziata senza aver salvato i propri dati: l’attivazione cancella i dati locali e riduce alcune protezioni previste dal sistema originale.

La prima schermata utile è stata quella di ripristino, raggiunta con la combinazione dei comandi hardware prevista dal modello. Nella foto il computer chiede di inserire una scheda SD o una chiavetta USB di ripristino: è il punto dal quale si accede alla sequenza necessaria per abilitare la modalità sviluppatore.

Il passaggio successivo mostra un avviso molto chiaro: il sistema sta entrando in modalità sviluppatore, i dati locali vengono cancellati e le modifiche non sono supportate da Google. Non è un messaggio ornamentale. Prima di procedere devi essere certo che sul Chromebook non sia rimasto niente di importante.

Sul mio Spin 311 il pulsante di accensione è sul bordo laterale, mentre il tasto con il lucchetto presente sulla tastiera non è il pulsante Power. È un particolare banale soltanto dopo averlo capito; durante una procedura nella quale ogni combinazione di tasti ha un significato preciso, può facilmente portarti sulla strada sbagliata.

5) Le funzioni di debug e l’avvio da USB.

Dopo l’ingresso in modalità sviluppatore ho attivato le funzioni di debug necessarie. La schermata fotografata mostra i campi per definire la password di root usata in questa fase e avverte che verrà abilitato l’avvio da unità USB.

La schermata successiva, con il segno di spunta verde, conferma che le funzioni di debug sono state attivate. Questo è il momento in cui il Chromebook è finalmente pronto a tentare l’avvio del sistema alternativo dalla chiavetta.

Abbiamo anche abilitato l’avvio USB tramite le impostazioni di ChromeOS. All’accensione, dalla schermata che avvisa che la verifica del sistema operativo è disattivata, Ctrl+U avviava il sistema presente sulla chiavetta. Dopo l’installazione nella memoria interna, invece, postmarketOS parte automaticamente alla fine del conto alla rovescia; Ctrl+D serve soltanto a saltare l’attesa.

Non ho modificato ulteriormente il firmware per ridurre l’avviso iniziale a pochi secondi. Sarebbe stato possibile soltanto con interventi più invasivi sulla protezione di scrittura. Per un server che si riavvia raramente, attendere qualche secondo in più è una scelta molto più ragionevole.

6) La chiavetta: immagine ufficiale e verifica dell’integrità.

Per il primo avvio ho usato una chiavetta da 123 GB. Prima di scriverla abbiamo identificato con precisione il disco sul Mac, distinguendolo da due unità esterne da 8 e 16 TB che non dovevano assolutamente essere toccate. Questo controllo è essenziale: un comando dd rivolto al disco sbagliato cancella dati senza chiedere scusa.

Ho scaricato l’immagine ufficiale postmarketOS-v26.06-console-google-kukui.img.xz e ne ho verificato l’hash SHA-256 prima della scrittura. Sul Mac l’immagine compressa è stata decompressa con xz e scritta sul dispositivo grezzo della chiavetta mediante dd, quindi il disco è stato sincronizzato ed espulso correttamente.

Il primo avvio è riuscito: sullo schermo è comparso il login google-kukui. Questo ha consentito di provare compatibilità hardware, Wi-Fi e sistema prima di cancellare la memoria interna del Chromebook. Soltanto dopo il collaudo abbiamo deciso di procedere con l’installazione definitiva.

7) Da sistema di prova a installazione interna.

Una volta avviato postmarketOS dalla chiavetta, il sistema distingueva chiaramente i due dispositivi:

• /dev/sda, la chiavetta esterna da 123 GB;

• /dev/mmcblk0, la memoria eMMC interna da 64 GB.

Abbiamo installato pmbootstrap, lo strumento ufficiale usato da postmarketOS per preparare e installare il sistema. La configurazione scelta era molto precisa:

• ramo stabile v26.06;

• dispositivo google-kukui;

• architettura ARM64;

• interfaccia console, senza desktop grafico;

• systemd come sistema di inizializzazione;

• lingua e tastiera italiane;

• fuso orario Europe/Rome;

• nome macchina chromebook-server;

• server SSH incluso;

• nessuna cifratura completa del disco, perché avrebbe richiesto una password fisica dopo ogni riavvio e impedito il funzionamento veramente autonomo.

La memoria interna è stata partizionata e formattata, poi postmarketOS è stato installato sulla partizione /dev/mmcblk0p3. Prima del primo riavvio abbiamo già trasferito nel nuovo sistema la configurazione Wi-Fi, impostato il fuso orario, abilitato NetworkManager e predisposto SSH.

Al riavvio ho rimosso la chiavetta e il Chromebook ha caricato Linux dalla eMMC interna. Da quel momento la trasformazione era reale: ChromeOS non era più il sistema operativo usato dalla macchina.

8) Le piccole difficoltà che fanno perdere più tempo.

La parte più istruttiva non è stata il comando principale, ma la successione di problemi minori. L’immagine minimale, per esempio, usava inizialmente una tastiera americana e non conteneva il comando setup-keymap. Abbiamo prima applicato direttamente una mappa disponibile nel sistema, poi installato i componenti necessari con apk.

Sembrava tutto risolto, ma alla schermata di login la tastiera tornava americana. Il motivo era sottile: durante l’avvio systemd-vconsole-setup tentava di applicare la mappa italiana troppo presto, quando l’unica console virtuale del Chromebook risultava già occupata. La soluzione è stata creare un piccolo servizio eseguito dopo la comparsa del login, incaricato di applicare la keymap italiana nel momento giusto.

Anche SSH ha riservato una sorpresa. Il comando rc-service, normale nelle installazioni Alpine basate su OpenRC, non esisteva perché questa versione di postmarketOS usava systemd. Il servizio corretto andava quindi avviato tramite systemctl. È un buon esempio del motivo per cui copiare comandi da una guida qualsiasi non basta: distribuzione, versione e sistema di inizializzazione contano.

Un altro inconveniente è arrivato più tardi dalla rete. Il Wi-Fi risultava connesso, ma il sistema aveva perso la rotta predefinita verso il router: i servizi locali continuavano a funzionare, mentre Internet e Tailscale erano scomparsi. Riavviare soltanto la connessione wireless ha ricreato il lease; in seguito ho assegnato al server l’indirizzo statico locale 192.168.1.30, dopo aver verificato che non fosse già occupato.

9) Trasformarlo in un server significa metterlo in sicurezza.

Dopo il primo avvio dalla memoria interna non mi sono limitato a installare Docker. Prima ho configurato il Chromebook come una macchina destinata a rimanere sempre accesa e raggiungibile.

L’accesso SSH usa una chiave Ed25519 già presente sul Mac. Dopo averla verificata, abbiamo disabilitato sia l’autenticazione remota mediante password sia il login SSH diretto dell’utente root. La password locale rimane disponibile davanti alla tastiera, ma non può essere tentata dalla rete.

Il firewall nftables blocca le connessioni non richieste e consente soltanto i servizi previsti. Sono state aggiunte regole specifiche per mDNS, per i bridge creati da Docker e per l’accesso ai servizi pubblicati attraverso l’interfaccia Tailscale. Il nome chromebook-server.local consente di raggiungere la macchina nella rete domestica anche senza ricordare l’indirizzo IP.

Ho installato Tailscale dal pacchetto disponibile per Alpine/postmarketOS. Il servizio tailscaled parte automaticamente e attribuisce al Chromebook un indirizzo stabile della rete privata Tailscale e un nome MagicDNS. Posso quindi amministrarlo tramite SSH anche fuori casa, senza aprire sul router una porta pubblica verso Internet.

Se vuoi approfondire queste due idee, avevo già raccontato come Codex renda più accessibile la costruzione di servizi propri e come usare Tailscale per raggiungere in sicurezza i computer dello studio.

10) Coperchio chiuso, avvio automatico e controlli hardware.

Un portatile usato come server deve rimanere operativo anche quando chiudi il coperchio. Abbiamo quindi mascherato i target di sospensione, ibernazione e sospensione ibrida di systemd. Il test pratico ha confermato che, a coperchio chiuso, SSH, Tailscale e i container continuano a rispondere.

All’accensione non occorre impartire comandi. Dopo l’avviso della modalità sviluppatore il Chromebook avvia postmarketOS dalla memoria interna; NetworkManager, SSH, Tailscale, Docker e i container partono automaticamente. Dopo un’interruzione di corrente il server torna quindi operativo da solo, purché il Chromebook si riaccenda.

Abbiamo controllato anche lo stato dell’hardware. La eMMC non era affatto arrivata alla fine della propria vita: gli indicatori interni mostravano un’usura stimata tra zero e dieci per cento e uno stato pre-fine-vita normale. La batteria aveva 107 cicli e conservava circa il 78 per cento della capacità originaria.

Il primo collaudo di CPU e memoria è terminato senza blocchi e senza servizi falliti. In una successiva prova dell’alimentatore abbiamo caricato tutti gli otto core per 45 secondi: la batteria è rimasta al 100 per cento, la temperatura ha raggiunto per breve tempo 79 gradi ed è poi tornata intorno ai 53. La macchina va comunque collocata in un punto ventilato, non soffocata dentro un mobile o appoggiata su tessuti.

11) Docker su ARM64: la parte che ha cambiato davvero le cose.

Docker e Docker Compose si sono installati e avviati correttamente. Il sistema espone otto core, 4 GB di RAM, cgroups v2 e un filesystem overlay nativo. Prima di trasferire applicazioni vere abbiamo eseguito un container ARM64 di prova e verificato che terminasse correttamente.

La compatibilità dell’architettura è fondamentale. Un container costruito soltanto per processori Intel amd64 non gira automaticamente su questo MediaTek arm64. Nel mio caso le applicazioni che volevo trasferire disponevano già di immagini compatibili ARM64 oppure, come AfterTouch, di un’immagine personale già pronta per quell’architettura.

Il Chromebook aveva circa 51 GB liberi dopo la configurazione. Sono sufficienti per sistema, immagini Docker, database e configurazioni, ma non per ospitare centinaia di gigabyte di fumetti e audiolibri. Per questo la migrazione è stata progettata distinguendo sempre il motore dell’applicazione dai suoi grandi archivi.

12) Il primo servizio migrato: AfterTouch.

AfterTouch è il mio sistema per controllare sei casse Bose SoundTouch e sincronizzarne i preset. È formato da un server principale e da un secondo container che si occupa della sincronizzazione. Espone l’interfaccia HTTP sulla porta 8000 e quella HTTPS sulla 8443.

La vecchia installazione sul Mac conteneva 8,4 GB di registrazioni diagnostiche delle interazioni HTTP. Quei dati non erano necessari al funzionamento e non aveva senso consumare la eMMC del Chromebook per conservarli. I dati realmente necessari — registrazione delle casse, account, preset e certificati — occupavano circa 125 KB; l’intera copia runtime pulita era di appena 380 KB.

Abbiamo trasferito l’immagine ARM64 senza ricompilarla, avviato inizialmente soltanto il servizio principale e verificato interfaccia web, API, HTTP e HTTPS. In seguito abbiamo spostato il sincronizzatore, corretto i permessi della cartella di stato e consentito il port forwarding SSH che serviva durante la fase di transizione.

Le sei casse sono state infine riconfigurate per parlare direttamente con 192.168.1.30:8000. I container aftertouch e aftertouch-preset-sync usano la politica restart: unless-stopped e ripartono automaticamente. Ogni giorno alle 4 il Mac preleva dal Chromebook un archivio verificato e lo salva sul disco esterno di backup, escludendo i log diagnostici.

In un altro post ho raccontato un caso ancora più curioso di amministrazione remota: la riparazione dell’autoradio Android del camper tramite Codex e Tailscale.

13) Home Assistant, Kavita e Audiobookshelf.

Dopo AfterTouch ho trasferito Home Assistant. La configurazione occupava circa 145 MB e non dipendeva da periferiche USB collegate al Mac. Abbiamo scaricato sul Chromebook l’immagine ARM64, arrestato ordinatamente il vecchio container, eseguito l’ultima sincronizzazione del database e avviato la nuova istanza sulla porta 8123. La copia del Mac è rimasta spenta ma intatta, pronta per un eventuale ripristino.

Kavita e Audiobookshelf erano più complessi. I loro container consumavano poche risorse, ma le biblioteche comprendevano circa 216 GB di fumetti, libri e audiolibri custoditi su un SSD esterno collegato al Mac. Copiarli sui 64 GB del Chromebook era impossibile e sarebbe stato anche inutile.

Ho quindi lasciato i contenuti sul disco esterno e condiviso dal Mac la cartella media tramite SMB in sola lettura. Su macOS è stato necessario concedere a Condivisione file l’accesso completo al disco. Il mount CIFS del kernel Linux non accettava correttamente la sessione ospite offerta da macOS; il client SMB in spazio utente di rclone, invece, riusciva a leggerla.

Un servizio systemd monta quindi la condivisione in sola lettura in /home/user/media prima dell’avvio di Docker. Se la condivisione ritorna disponibile dopo che Docker è già partito, il servizio riavvia Kavita e Audiobookshelf affinché vedano correttamente il mount. Kavita risponde sulla porta 5001 e Audiobookshelf sulla 13378, sia nella rete locale sia attraverso Tailscale.

Il compromesso è chiaro: i due programmi vengono eseguiti dal Chromebook, ma per consultare le biblioteche hanno ancora bisogno che il Mac e il disco esterno siano accesi. Home Assistant e AfterTouch, invece, sono ormai autonomi.

14) Il vero risparmio sul Mac mini.

Prima della migrazione il Mac mini aveva 8 GB di RAM, circa 7,5 GB utilizzati, 2,9 GB compressi e 6,5 GB di swap. Il peso maggiore non era costituito dai singoli container, che complessivamente usavano circa 1,1 GB, ma da Docker Desktop: per eseguire container Linux su macOS deve mantenere una macchina virtuale che nel mio caso riservava circa 3 GB.

Dopo aver verificato i quattro servizi sul Chromebook abbiamo fermato i container originali sul Mac, disabilitato il loro riavvio automatico e rimosso Docker dagli eventuali watchdog. Docker Desktop è stato spento e il suo avvio al login disattivato. Le vecchie copie non sono state cancellate: rimangono disponibili come rollback finché l’intero sistema non sarà stato collaudato abbastanza a lungo.

Ho lasciato Plex sul Mac. La transcodifica multimediale beneficia molto di più del processore M2 e i suoi file sono già collegati fisicamente a quella macchina. Recuperare vecchio hardware non significa trasferirgli qualsiasi cosa: significa assegnargli i carichi adatti alla sua architettura, alla memoria e allo spazio disponibile.

15) Che cosa mi ha insegnato questo recupero.

La parte sorprendente non è che Linux possa funzionare su un vecchio Chromebook. È la quantità di lavoro reale che una macchina considerata ormai difettosa riesce a svolgere quando le togli un sistema inadatto al nuovo scopo e le assegni compiti compatibili con le sue risorse.

Il portatile continua ad avere uno schermo rovinato, ma come server lo schermo quasi non serve. La batteria, pur usurata, funziona come un piccolo gruppo di continuità incorporato. La tastiera e il display restano disponibili per le emergenze. Il Wi-Fi, Tailscale e SSH consentono di amministrarlo da un altro computer; Docker separa le applicazioni e ne semplifica il trasferimento.

Naturalmente questa non è una procedura universale né priva di rischi. La modalità sviluppatore cancella i dati; la scrittura di un’immagine sul disco sbagliato può distruggere un archivio; il supporto hardware cambia da modello a modello; un server richiede aggiornamenti, backup, firewall e controlli periodici. Se contiene dati professionali o personali, devi valutare con attenzione sicurezza, riservatezza e continuità operativa.

Nel mio caso, però, il risultato è concreto: un Acer Chromebook Spin 311 che non usavo più è diventato un server Linux ARM64 sempre acceso, accessibile anche da remoto e capace di eseguire quattro servizi veri. Non male per un computer che sembrava destinato al cassetto.

Anche questo è un risparmio, su più profili: non servono abbonamenti, si riutilizzano macchine vecchie.

16) Passa all’azione.

Per il tuo appuntamento con me, chiama il numero 059 761926 e concorda il tuo primo incontro, anche a distanza.

Metti mi piace se ti è piaciuto questo post e iscriviti adesso al blog per essere avvisato quando escono contenuti come questo.