Bsd on Melabit

Ventoy, il boot manager per i geek curiosi - Introduzione

Tue, 08 Nov 2022 06:00:00 +0000

Ventoy è senza dubbio un software di nicchia, buono soprattutto per i tecnici e i geek curiosi di esplorare il funzionamento dei sistemi operativi. Non serve a tanti, ma se serve diventa subito indispensabile.

Cos’è Ventoy?

Ventoy è un software open source con cui si può creare una chiavetta USB da cui eseguire gli installatori dei principali sistemi operativi a partire dalle loro immagini in formato iso (ma anche da quelle in formati meno comuni, come wim, img o vhd). Sono supportate tutte le versioni di Windows dalla 7 in poi, così come un gran numero di distribuzioni di Linux e di derivati di BSD Unix, ChromeOS e perfino i principali virtualizzatori bare-metal.¹

In pratica, se vogliamo installare un sistema operativo su un PC, invece di trasferirne l’immagine iso su una chiavetta dedicata, usando strumenti come balenaEtcher o UNetbootin (entrambi multipiattaforma) o eventualmente Rufus (solo per Windows), possiamo copiare direttamente l’immagine iso sulla chiavetta USB dove abbiamo installato Ventoy (i dettagli li troverete la prossima volta), avviare il computer da questa chiavetta e lanciare l’installatore direttamente da lì.

Cosa cambia? Niente se lo facciamo una sola volta, parecchio se dobbiamo lavorare su più macchine, se vogliamo provare le nuove distribuzioni di Linux o di BSD o, in generale, se ci piace giocare con queste cose.

Perché, a differenza del metodo tradizionale, una chiavetta abbastanza grande può contenere anche decine di file iso diversi, da lanciare a seconda della necessità o dell’estro del momento. Inutile dire che al posto di una chiavetta potremmo anche usare un disco SSD esterno, anche da soli 128 GB, guadagnando parecchio nella velocità di avvio delle varie iso.

Sia che usiate una chiavetta o un disco SSD esterno, è sempre conveniente astenersi dai modelli di marche sconosciute o poco affidabili. È vero che per questo uso specifico l'affidabilità non è fondamentale, però è altrettanto vero che, se si guasta la chiavetta, bisogna ripetere da zero tutto il processo di installazione/configurazione di Ventoy e, soprattutto, la copia delle iso. È una bella perdita di tempo, per cui è meglio non rischiare solo per risparmiare qualche euro.[^2]

Immagini dell’installatore di Windows 10, eseguito da una chiavetta USB con installato Ventoy.

Ventoy può naturalmente essere usato per installare Windows, ma diventa ancora più utile con le distribuzioni di Linux o di BSD, i cui installatori ormai eseguono quasi sempre una versione Live del sistema operativo, con la quale è possibile provare le funzioni della distribuzione senza rischiare di far danni, sicuri che tutte le modifiche saranno cancellate al riavvio.

In questo caso, il vantaggio principale di Ventoy risiede nel fatto che si può usare una sola chiavetta per eseguire tutte le distribuzioni Live che vogliamo, senza dover riavviare ogni volta il sistema operativo principale solo per creare una chiavetta USB ad hoc con la nuova distribuzione da provare. Una volta trovato ciò che ci aggrada, si può anche decidere di installarlo permanentemente sul computer sempre utilizzando Ventoy.

Esempi di distribuzioni Live di Linux eseguite tramite Ventoy.

Non c’è bisogno di dire che Ventoy è uno strumento fondamentale per chi fa assistenza tecnica e si trova a dover installare (o reinstallare) di continuo le varie versioni di Windows sui computer dei clienti, o che deve recuperare i dati da un computer che non si avvia più o che è infestato da virus e malware vario. Con una sola chiavetta può avere a disposizione tutte le iso di cui ha bisogno, scegliendo di volta in volta lo strumento migliore da utilizzare in quel caso specifico.

Boot manager

Chi ha qualche capello bianco avrà riconosciuto in Ventoy il meccanismo di funzionamento di un boot manager.

I boot manager hanno avuto il loro periodo di massima popolarità fra la fine degli anni '90 e i primi anni 2000, quando era diventato normale per tanti utenti installare sul proprio PC una distribuzione di Linux (e spesso più di una) in parallelo all'onnipresente Windows. Le versioni di Windows di quegli anni non permettevano di avviare altri sistemi operativi oltre a sé stessi, per cui era necessario usare dei boot manager di terze parti per riuscire ad usare indifferentemente Linux o Windows sulla stessa macchina. Io, ad esempio, usavo GAG, che era molto flessibile e avviava praticamente tutto.
Oggi la situazione è cambiata: la riduzione del costo dei computer associata alla disponibilità di processori potenti e di memorie di massa a stato solido velocissime ha reso molto più pratico dedicare ogni PC ad un solo scopo, oppure virtualizzare più sistemi operativi su una singola macchina, evitando così i noiosissimi riavvii da un sistema operativo all'altro.
Ma questo non significa che i boot manager di terze parti oggi siano caduti in disuso, anzi. Fra questi, il più noto è di sicuro GNU GRUB, usato praticamente da tutte le distribuzioni di Linux (ma GRUB è anche in grado di avviare qualunque altro sistema operativo installato sul computer). Poi ci sono Clover e OpenCore, ampiamente utilizzati nel mondo Hackintosh per avviare macOS installato su un semplice PC. Chi usa Windows e vuole una maggiore flessibilità può utilizzare EasyBCD al posto dello strumento di avvio nativo, che definire limitato è poco.

E non si sbaglia, Ventoy si dimostra utilissimo anche in questo campo, perché la stessa chiavetta dove è installato Ventoy permette di avviare un computer su cui Windows (o Linux) si rifiuta di partire, eseguendo una ricerca a basso livello dei sistemi operativi installati sul disco, come si può vedere nell’immagine qui sotto. Con Linux succede di rado (e comunque GRUB riesce quasi sempre a metterci una pezza), ma per chi usa Windows è una manna dal cielo.²

Ventoy può anche essere usato per avviare un sistema operativo che si rifiuta di partire.

Alternative a Ventoy?

L’unica alternativa a Ventoy che io conosca è questo disco SSD esterno, con aggiunto un piccolo schermo e una tastiera con cui scegliere l’iso da avviare. Un bell’oggettino, non c’è che dire, che proprio per la sua stessa esistenza dimostra quanto sia sentita l’esigenza di avviare con facilità le iso di svariati sistemi operativi. Purtroppo il prezzo non proprio popolare (almeno rispetto a quello che fa e alla capacità del disco) lo rende adatto solo a chi si occupa professionalmente di assistenza tecnica.

Per usare Ventoy, invece, non è necessario essere dei professionisti o avere il budget di un professionista. Se volete provare facilmente più di una distribuzione di Linux o se siete l’amico che tutti chiamano quando hanno un guaio al computer, Ventoy diventa subito uno strumento praticamente indispensabile.

Come introduzione a Ventoy può bastare. Nella seconda parte i dettagli dell’installazione e dell’uso di questo strumento. A presto!

Argomento molto interessante di per sé, che spero di riuscire a trattare qui prima o poi. ↩︎
C’è gente che si convince che il computer sia da buttare solo perché Windows non si avvia. E non esagero affatto. ↩︎

Automatizzare il Mac dal Terminale - Ancora Launchd

Tue, 28 Apr 2015 06:00:00 +0000

A volte bisogna saper ammettere i propri errori. Questa è una di quelle volte.

Nel mio post su launchd di qualche mese fa non avevo nascosto il mio scetticismo per una soluzione molto lontana dai canoni di Unix e troppo complicata per essere usata al posto di cron, il programma che nei sistemi operativi derivati da Unix è incaricato di eseguire periodicamente dei comandi o degli interi script in modo automatico.

Leggendo però questo post su MacStories, mi sono reso conto dell’esistenza di una ulteriore opzione di launchd, QueueDirectories, che permette di di tenere sotto controllo una (o più) directory del Mac e di eseguire automaticamente un comando ogni qualvolta si aggiunge un file alla directory osservata.¹ Oltre a questa esiste una opzione più generale, WatchPaths, che permette di tenere sotto controllo uno o più file (o directory) ed eseguire un comando quando uno di questi file (o directory) viene modificato.

Con queste due nuove (almeno per me!) opzioni si può estendere notevolmente il campo di applicazione di launchd, facendogli eseguire un comando o uno script non solo in modo periodico (in sostituzione di cron), ma anche al verificarsi di un evento come l’aggiunta di un file ad una directory o la modifica di un determinato file.

Launchd, l’osservatore

Riprendiamo quindi il file plist di configurazione del post precedente e vediamo cosa possiamo fare se aggiungiamo l’opzione QueueDirectories.

Il punto di partenza è sempre lo stesso: vogliamo eseguire automaticamente lo script ~/bin/makeblog e rigenerare automaticamente il blog “Pazzi per la mela”.

Questa volta però vogliamo rigenerare il blog non ad un’ora ben definita ed immutabile, ma solo quando inseriamo un nuovo post nella directory ~/Dropbox/blog/.

In questo caso usare Dropbox (o un qualunque servizio analogo, Box, Copy, Google Drive, o perfino OneDrive di Microsoft) è particolarmente utile, perché permette di aggiungere il post anche lontano dal Mac, magari dopo averlo preparato sull’iPad o sull’iPhone.

Il file plist di configurazione del post precedente diventa

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>it.pazziperlamela.makeblog</string>
	
	<key>Program</key>
	<string>/Users/utente/bin/makeblog</string>
	
	<key>QueueDirectories</key>
	<array>
    	<string>/Users/utente/Dropbox/blog/</string>
	</array>
	
	<key>StandardOutPath</key>
	<string>/Users/utente/Documenti/makeblog.log</string>
	
	<key>StandardErrorPath</key>
	<string>/Users/utente/Documenti/makeblog.err</string>

	<key>RunAtLoad</key>
	<false/>
</dict>
</plist>

Per attivarlo, come abbiamo già visto, basta salvarlo nella directory ~/Library/LaunchAgents/ del proprio account (dove il simbolo ~ indica la cartella Inizio o home dell’utente che sta usando il Mac) con il nome it.pazziperlamela.makeblog.plist (il nome del file deve essere uguale a quello senza estensione utilizzato alla riga 6 del file plist), ed eseguirlo una prima volta dal Terminale con il comando

$ launchctl load it.pazziperlamela.makeblog.plist

Ai successivi riavvii sarà il sistema operativo ad eseguire periodicamente lo script.

Conclusioni

Devo ammettere che le opzioni QueueDirectories e WatchPaths rendono launchd molto più interessante di quanto mi sia mai reso conto, permettendo di eseguire dei comandi di sistema o degli interi script in modo asincrono, al verificarsi di eventi particolari come la scrittura o la modifica di un file in una directory.

Intendiamoci, le mie riserve sulla complessità di launchd rimangono intatte. Inoltre continua a non piacermi il fatto che sia uno strumento confinato al solo OS X, con poche prospettive di diffusione al di fuori del mondo Apple fra i sistemi operativi derivati da Unix, come Linux e BSD.

Però pragmaticamente mi rendo conto che in certe circostanze launchd può rivelarsi uno strumento utilissimo e senza eguali. Basta solo usarlo con moderazione.

Qualcosa di simile alle cosiddette “Folder Actions”, introdotte già da parecchi anni in OS X senza troppo successo, che istruivano il sistema operativo a tenere sotto controllo una directory e ad eseguire dei comandi AppleScript o Automator ogni volta che un file veniva aggiunto o rimosso da quella directory, oppure quando quest’ultima veniva aperta, chiusa o spostata. ↩︎

Automatizzare il Mac dal Terminale - Una soluzione targata Apple

Thu, 11 Dec 2014 06:00:00 +0000

Dopo i programmi di derivazione Unix, at e cron, è la volta di parlare di launchd, una soluzione sviluppata dalla Apple per OS X.

Launchd

Launchd è il programma che, a partire dalla versione 10.4 (Tiger) di OS X, esegue tutti i processi di avvio del sistema operativo e che, come se non bastasse, può anche svolgere i compiti eseguiti da cron.

Launchd è stato sviluppato dalla Apple e, dopo qualche incomprensione, è stato rilasciato sotto la licenza open source Apache, con l’intento di promuoverne l’adozione anche sotto Linux e BSD. Finora però l’accoglienza al di fuori di OS X è stata tiepida, se non peggio, e quindi al momento launchd rimane confinato al solo Mac.

La cosa non mi stupisce.

Al di là degli aspetti tecnici relativi al porting su altre piattaforme e focalizzando l’attenzione solo sull’utilizzo di launchd al posto di cron, sono perfettamente d’accordo con quanto è stato scritto tempo fa su Low End Mac, con il titolo significativo Apple’s launchd Is Anti-Unix (Launchd di Apple è anti-Unix).

One of the great things about Unix-like systems is that most of your skills, programs, dot files, and highly polished shell scripts are portable. I brought them with me to OS X after dragging them through a dozen or so Linux distributions…
Consequently, I was distressed when launchd emerged from the dark side of One Infinite Loop…
Merging periodically run jobs into the main system process doesn’t make sense. Replacing a simple /etc/crontab text file with multiple, awkwardly named XML plist files scattered among no less than four different directories is taking two big steps toward complexity.

Credo sia abbastanza chiaro anche così, ma lo traduco qui sotto perché ne condivido ogni parola.

Una delle cose migliori dei sistemi Unix è che la maggior parte delle competenze, dei programmi sviluppati, dei file di configurazione [detti “dot file” perché il nome di questi file inizia in genere con un punto] e degli script di shell sono portatili [su piattaforme differenti]. Io me li sono portati dietro su OS X dopo averli fatti transitare per una dozzina di distribuzioni diverse di Linux…
Di conseguenza mi preoccupa vedere launchd emergere dalla faccia oscura di One Infinite Loop [l’indirizzo della Apple]…
Non ha senso mescolare processi eseguiti periodicamente con il processo principale [di inizializzazione] del sistema operativo. Sostituire un semplice file di testo /etc/crontab con una serie di file plist in formato XML con nomi assurdi e distribuiti su almeno quattro directory diverse è un bel passo avanti [sarebbero due, ma in italiano non viene bene] verso la complessità…

Launchd contro cron

Se consideriamo il semplice obiettivo di rendere automatiche certe attività ripetitive sul Mac, la chiave del discorso sta proprio nell’ultima frase citata: “Sostituire un semplice file di testo /etc/crontab con una serie di file plist in formato XML con nomi assurdi, distribuiti su almeno quattro directory diverse è un bel passo avanti verso la complessità”.

Launchd è molto più complicato di cron, inutilmente più complicato. Basta usarlo un po’ per accorgersene.

Proviamo a sostituire launchd a cron per eseguire lo script ~/bin/makeblog e rigenerare automaticamente il blog “Pazzi per la mela” alle 2:00 di ogni notte.

Con cron basta solo aggiungere al file crontab la riga seguente

00	02	*	*	*	~/bin/makeblog

Se invece si vuole utilizzare launchd, bisogna creare un file plist di configurazione in linguaggio XML più o meno come questo,

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>Label</key>
	<string>it.pazziperlamela.makeblog</string>
	
	<key>ProgramArguments</key>
	<array>
		<string>/Users/utente/bin/makeblog</string>
	</array>
	
	<key>StartCalendarInterval</key>
	<dict>
		<key>Hour</key>
		<integer>02</integer>
		<key>Minute</key>
		<integer>00</integer>
	</dict>
	
	<key>StandardOutPath</key>
	<string>/Users/utente/Documenti/makeblog.log</string>
	
	<key>StandardErrorPath</key>
	<string>/Users/utente/Documenti/makeblog.err</string>

	<key>RunAtLoad</key>
	<false/>
</dict>
</plist>

salvarlo nella directory ~/Library/LaunchAgents/ del proprio account (la ~ indica la cartella Inizio o home dell’utente che sta usando il Mac) usando obbligatoriamente il nome it.pazziperlamela.makeblog.plist (il nome del file deve essere uguale a quello senza estensione utilizzato alla riga 6 del file plist), e infine eseguirlo una prima volta dal Terminale con il comando

$ launchctl load it.pazziperlamela.makeblog.plist

Per fortuna ai successivi riavvii ci pensa il sistema operativo ad eseguire periodicamente lo script.

Un brevissimo tutorial

Può essere utile descrivere brevemente le informazioni essenziali da inserire nel file plist di configurazione, in modo che il processo automatico gestito da launchd funzioni correttamente. Per ulteriori informazioni, consiglio la lettura di quest’ottimo tutorial e delle specifiche dettagliate del formato del file plist usato da launchd.

Le prime tre righe del file specificano tipo e versione dei formati xml e plist utilizzati, e vanno copiate esattamente come sono scritte nell’esempio precedente.

Il file plist deve contenere tre chiavi obbligatorie. La prima, Label (riga 5), serve per specificare il nome del file plist stesso, senza estensione. Nel nostro caso il nome del file è it.pazziperlamela.makeblog (riga 6).¹

La chiave ProgramArguments (riga 8) serve invece per specificare il percorso e il nome dello script di shell da eseguire. Qui è /Users/utente/bin/makeblog, dove al posto di utente bisogna sostituire il nome breve del proprio account. Il modo più semplice per ottenere il proprio nome breve è eseguire da Terminale il comando whoami (oppure id -un).

L’ultima chiave obbligatoria, StartCalendarInterval (riga 13), definisce ora e minuto (oltre che eventualmente giorno della settimana, giorno e mese) in cui launchd deve eseguire lo script di shell. In alternativa si può usare la chiave StartInterval, che lancia invece lo script ogni certo numero di secondi, a partire dalla prima esecuzione del processo tramite launchctl.

Due ulteriori chiavi opzionali, StandardOutPath e StandardErrorPath (righe 21 e 24), definiscono rispettivamente il percorso dei file da usare per salvare l’output completo generato dal comando e gli eventuali messaggi di errore. Anche in questo caso bisogna sostituire nel percorso dei file il proprio nome breve al posto dell’utente generico.

Un’altra utile chiave opzionale è RunAtLoad (riga 27), che specifica se lo script di shell deve essere eseguito al momento del caricamento da parte di launchctl. Questa opzione è inutile se, come in questo caso, si definiscono esattamente gli orari di esecuzione del processo tramite la chiave StartCalendarInterval. Se invece si usa la chiave StartInterval, bisogna impostare RunAtLoad al valore true/, in modo da fissare il tempo iniziale da cui far partire il conteggio dei secondi.

Due comandi utili

Per elencare tutti i processi gestiti da launchd in un dato momento si esegue da Terminale il comando

$ launchctl list

Il Mac su cui sto scrivendo questo post elenca ben 294 processi, considerando sia i processi attivi che quelli ormai terminati.

Per smettere di eseguire automaticamente lo script it.pazziperlamela.makeblog.plist, si deve eseguire il comando

$ launchctl unload ~/Library/LaunchAgents/it.pazziperlamela.makeblog.plist

e poi cancellare (o spostare) il file it.pazziperlamela.makeblog.plist dalla directory ~/Library/LaunchAgents/. In caso contrario, lo script tornerà ad essere lanciato automaticamente al prossimo riavvio.

Conclusioni

È evidente che non mi piace l’idea di usare launchd al posto di cron. Troppo complicato e troppo proprietario. Una vera pugnalata ad uno dei principi cardini di Unix (e del software ben fatto): fare una cosa sola ma farla bene e in modo efficiente.

Intendiamoci, launchd va benissimo per gestire l’avvio del sistema e i servizi automatici (i demoni) gestiti dal sistema operativo e dalla sua introduzione in (Mac) OS X 10.4/Tiger ha reso molto più veloce il processo di avvio di OS X. Ma sostituire launchd a cron introduce un livello di complessità inutile ed insensato.

Nonostante tutto c’è qualcuno a cui launchd piace anche per questo scopo. Contento lui, io finché posso preferisco tenermi stretto il buon vecchio cron.

Il formato consigliato per il nome del file plist è il cosiddetto Uniform Type Identifier (UTI), una struttura simile a quella di un dominio web inverso. In questo caso è stato preso il nome dello script da eseguire makeblog, lo si è aggiunto all’indirizzo del (presunto) sito web del progetto pazziperlamela.it, e infine si è invertito l’ordine della stringa risultante, makeblog.pazziperlamela.it, ottenendo il nome del file plist. ↩︎