Raspberry Pi Imager usa io_uring, Ventoy apre alle recovery SteamOS

🐧 Novità principali

• Raspberry Pi Imager 2.0.12 modifica la pipeline di scrittura Linux con I/O sequenziale e gestione asincrona delle completion io_uring.
• La release corregge download troncati, cancellazioni incomplete, provisioning Wi-Fi WPA3 e diversi problemi del network installer Raspberry Pi.
• Ventoy 1.1.18 introduce il supporto sperimentale alle immagini di recovery SteamOS e migliora mount, persistence e compatibilità delle ISO Linux.

Preparare un supporto di installazione Linux sembra un’operazione elementare, ma sotto l’interfaccia grafica convivono scrittura raw, decompressione, caching, partizioni, Secure Boot e immagini costruite con strutture molto diverse. Raspberry Pi Imager 2.0.12 e Ventoy 1.1.18 intervengono proprio su questo livello. Il primo rafforza l’affidabilità del flashing e modifica la gestione dell’I/O asincrono su Linux; il secondo estende il proprio bootloader multimmagine alle recovery di SteamOS, finora problematiche da avviare direttamente. Due aggiornamenti diversi che confermano quanto anche la fase apparentemente banale del boot USB sia diventata una componente tecnica sempre più sofisticata dell’ecosistema Linux.

Raspberry Pi Imager riscrive parte della pipeline I/O su Linux

Nelle note ufficiali di Raspberry Pi Imager 2.0.12 il progetto interviene profondamente sul percorso di scrittura Linux: i dati vengono ora scritti sequenzialmente rispetto al cursore logico, mentre le completion di io_uring vengono raccolte anche durante l’attesa della disponibilità di uno slot nel ring buffer. Vengono inoltre riciclati correttamente gli slot in base alla loro identità e migliorato il fallback quando la riapertura tramite direct I/O non riesce. Sono modifiche meno visibili dell’interfaccia, ma incidono sul componente più delicato di Imager, quello che deve trasferire immagini compresse verso SD, USB o eMMC senza produrre supporti apparentemente completati ma inutilizzabili. Il lavoro prosegue quello di Raspberry Pi Imager 2.0.11, che aveva già rafforzato scrittura e gestione delle immagini Zstd.

Leggi anche: Raspberry Pi OS introduce HiDPI e Imager 2.0 rinnova l’installazione

Download incompleti e scritture cancellate non possono più risultare riusciti

La versione 2.0.12 chiude anche diversi casi nei quali il risultato mostrato all’utente poteva non corrispondere allo stato reale del supporto. Una scrittura annullata durante la personalizzazione non viene più indicata come completata, mentre Imager rifiuta download più corti del previsto e immagini .img.xz troncate invece di scriverne comunque una parte. Viene controllato anche l’errore dell’ultimo flush, migliorata la gestione delle operazioni abbandonate o in timeout e corretto il montaggio successivo alla formattazione attendendo la comparsa effettiva del nodo della partizione. Raspberry Pi interviene inoltre sulla configurazione Wi-Fi: viene conservata la passphrase originale invece della chiave PBKDF2 derivata, che poteva impedire la negoziazione WPA3/SAE. È una maturazione importante per uno strumento ormai parte integrante del provisioning della piattaforma, insieme alla continua evoluzione di Raspberry Pi OS e del suo stack ARM.

Il network installer ora aspetta DHCP, clock valido e connessioni lente

Un secondo gruppo di correzioni riguarda la modalità embedded utilizzata dal network installer Raspberry Pi. Imager non considera più sufficiente che il link Ethernet risulti semplicemente attivo, ma aspetta un indirizzo realmente utilizzabile, evitando di interpretare come connettività valida un indirizzo link-local 169.254.x.x ottenuto prima della conclusione del DHCP. La release gestisce inoltre PHY che negoziano lentamente, come quello presente su determinate revisioni di Raspberry Pi 5, ritenta il download della lista dei sistemi dopo trenta secondi e corregge il problema dei dispositivi senza RTC configurato che partono con l’orologio nel 1970, rendendo non ancora validi i certificati TLS. Si aggiungono autenticazione Raspberry Pi Connect tramite QR code e device code e importazione delle chiavi SSH attraverso un username GitHub. Il provisioning diventa quindi meno dipendente dall’intervento manuale proprio mentre Raspberry Pi OS continua a spostarsi verso uno stack desktop e di sistema più moderno.

Ventoy 1.1.18 prova finalmente ad avviare le recovery SteamOS

La seconda release cambia invece il rapporto tra Ventoy e l’ecosistema Valve. Il changelog ufficiale di Ventoy 1.1.18 introduce supporto sperimentale alle immagini di recovery SteamOS, una compatibilità richiesta da tempo perché le recovery distribuite da Valve non seguono il comportamento delle normali ISO Linux gestite da Ventoy. Il termine sperimentale è importante: la release non garantisce ancora che ogni immagine o dispositivo SteamOS possa essere recuperato attraverso questo percorso. L’intervento arriva però in una fase nella quale SteamOS sta rapidamente uscendo dal solo perimetro Steam Deck, con porting ARM e sperimentazioni su handheld Android che ampliano il numero di configurazioni sulle quali installazione e recovery diventano problemi concreti.

Ventoy migliora anche mount Linux, persistence e compatibilità delle ISO

SteamOS è soltanto la modifica più visibile. Ventoy 1.1.18 migliora la funzione di remount su Linux affinché la partizione contenente le immagini sia montabile direttamente sulle principali distribuzioni desktop, introduce il nome stabile /dev/mapper/VentoyPart e rende la partizione accessibile anche da Clonezilla. La release corregge inoltre il boot della beta di Fedora 45, un problema nel controllo della versione Secure Boot per Windows e WinPE, fallimenti intermittenti della persistence con Ubuntu Desktop e l’avvio di Grml 2026.09. Arriva infine il supporto alle ISO personalizzate basate su Syslinux. Ventoy rimane quindi qualcosa di diverso da un semplice programma di flashing: mantiene più immagini sullo stesso dispositivo e costruisce dinamicamente il percorso necessario ad avviarle, caratteristica particolarmente utile nell’ecosistema Valve che continua a rafforzare Steam Deck, controller e supporto Linux.

Continua con:

Raspberry Pi OS aggiorna kernel e stack software per ARM

Valve spinge SteamOS con Steam Machine, Steam Frame e Proton 10

Installare un sistema operativo significa ormai gestire una catena complessa

Le due release mostrano perché gli strumenti di boot e provisioning non possano più essere considerati utility marginali. Raspberry Pi Imager deve gestire download compressi, I/O asincrono, eMMC, rete, Wi-Fi, Secure Boot, fastboot e personalizzazione dell’immagine; Ventoy deve adattare immagini nate per bootloader e layout differenti senza riscrivere continuamente la chiavetta. L’evoluzione verso io_uring da una parte e il supporto sperimentale alle recovery SteamOS dall’altra segue quindi la stessa direzione: rendere più affidabile il passaggio tra immagine distribuita dal progetto e sistema realmente avviabile sull’hardware. È una fase breve nell’esperienza dell’utente, ma un errore in questo punto può rendere irrilevante tutto ciò che viene dopo.