slacky.eu

Quante volte avete fatto ricorso a prodotti come virtualbox, vmware per provare più distribuzioni sul vostro pc senza dover partizionare?

Magari per lo sviluppo avete piuttosto installato una slackware in chroot, ma non è la stessa cosa, visto che non ci potete fare il boot.
Certo, è l'ideale se dovete compilare pacchetti, ma non ci potete fare il boot; magari lo si può emulare facendogli caricare qualcuno degli script rc, ma non è la stessa cosa che fare un boot.

Io ho trovato la soluzione per effettuare il boot da una macchina chrootata.
La procedura è testata con slackware ma si dovrebbe poter applicare senza troppi problemi anche a tutte le altre distribuzioni.
Il test per la precisione è stato effettuato lanciando una slackware 32bit installata in una sottodirectory nella partizione di una slackware 64bit ma è possibile anche installarla in una sottodirectory di una partizione in cui non c'è nessuna distribuzione installata (è leggermente più difficile per il fatto che non si ha una distribuzione da cui lavorare, ma con una live il gioco è fatto).
Può anche essere utile effettuare l'installazione in una sottodirectory di un dispositivo usb o in un file immagine ( -o loop ... ) e chi più ha fantasia più ne aggiunga.

La procedura è semplice.
Intanto installiamo la nostra slackware in una directory per esempio /slack1 e che si trovi nella partizione /dev/hda1
poi dovrete utilizzare il kernel huge.

ricordate di creare /slack1/etc/fstab prima del reboot:
/dev/sda2 / ext3 defaults 1 1
/dev/sda1 swap swap defaults 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0

Riferimenti utili: http://www.slacky.eu/wikislack/index.ph ... ennina_USB

Il funzionamento:
In pratica viene prodotto un initrd in quanto al kernel non gli si può dire di montare una directory come root filesystem ma solo una partizione.
Dopo aver montato la partizione però posso fare un mount virtuale (con --bind) di una singola directory (la nostra /slack1) su un altro mountpoint e poi smontare quello principale; poi possiamo fare il chroot

Con la stessa tecnica è possibile sharare directory tra le varie chroot, per esempio la /home ci potrebbe essere utile lasciarla in comune. In tal caso modificare l'init: e aggiungere nella fstab In verità la procedura standard per creare un initrd prevede l'utilizzo di switch_root o pivot_root che sono fatti apposta, ma sembrerebbe che non ne vogliano sapere di assegnare come root una sottodirectory di una partizione.

In caso di usb si aggiungono alcuni fattori complicanti che riguardano il ritardo con cui il kernel riconosce tali dispositivi e il problema di non sapere a priori quale sia il nome del device, soprattutto nel caso in cui si configura l'initrd su una macchina con dischi ide e poi si usa tale initrd su macchine con dischi sata (il che implica una traslazione dei nomi dei device.
Nel link segnalato si ovvia al problema facendo uso delle label sul filesystem al posto dei device.


Ciao
01

Se non ho capito male devi comunque fare un boot, quindi perdi il maggior vantaggio delle scelte chroot o virtual machine, cioè poter usare contemporaneamente più distribuzioni o, nel caso di chroot, varie versioni della stessa, anche se, come giustamente tu, in modo limitato.
Questo ti evita solamente di dedicare una partizione alla distribuzione, o sbaglio?

conraid ha scritto:Se non ho capito male devi comunque fare un boot, quindi perdi il maggior vantaggio delle scelte chroot o virtual machine, cioè poter usare contemporaneamente più distribuzioni o, nel caso di chroot, varie versioni della stessa, anche se, come giustamente tu, in modo limitato.
Questo ti evita solamente di dedicare una partizione alla distribuzione, o sbaglio?

Chiaro, a ognuno i suoi vantaggi e i suoi svantaggi; lo dicevo all'inizio.
Se hai bisogno di usare il chroot per la compilazione dei pacchetti è chiaro che è 100 volte meglio il chroot classico.

La mia soluzione evita appunto di dedicare partizioni e al contempo di dedicare l'hardware (in primis scheda grafica, quello che non fa vmware&co) alla distribuzione.
Inoltre se la distribuzione principale è una slackware64 e quella chrootata è una slackware non c'è problema a dare un chroot, ma se è il contrario (per esempio per testare la slackware64) allora il chroot non lo dai in quanto il kernel non te lo supporta. E quindi sei costretto a usare vmware (ammesso che hai un processore che supporta la virtualizzazione a 64bit... io no! ) o dedicare una partizione... o usare la mia soluzione

A ognuno la sua.
L'avevo pensata anni fa ma allora avevo qualche lacuna di conoscenze tecniche necessarie.

Ho altre feature interessanti da implementare, ma non ora (devo pensarne la fattibilità, ma se funge è una svolta)

Ciao
01

ZeroUno ha scritto: Ho altre feature interessanti da implementare, ma non ora (devo pensarne la fattibilità, ma se funge è una svolta)

le attendo allora

perché non lo metti nel wiki?

conraid ha scritto:perché non lo metti nel wiki?

beh, prima volevo un feedback per magari fare migliorie, correggere bug ecc

ciao
01

Ciao...
Vedo che la tua procedura e l'argomento tocca aspetti in gran parte comuni ad un recente topic che avevo aperto e in cui "zoros" aveva gentilmente apportato un contributo importante.

viewtopic.php?f=1&t=28836&p=246835#p246835

Le finalità che mi ero posto erano differenti, nel mio caso volevo creare una copia del mio sistema in una directory dell'HD esterno usb, e spratttutto riuscire ad avviarla, magari bypassando l'HD interno (a questo fine nel mio caso pur supportando il bios l'avvio da usb, non riesco a far partire il sistema dall'HD perchè se quando accendo il device è attaccato, si blocca proprio l'accensione del notebook....probabilmente c'è qualche problema di corrente).
Il fine che mi ero posto era semplice:
- creare una copia di backup del sistema in uso facilmente sincronizzabile e usabile al volo (per esempio in caso di rottura HD interno...o lavori in corso sulla partizione dell'HD interno...tipo upgrade a versione successiva).

La possibilità di fare tutto in una directory del device esterno evitava la necessità di creare nuove partizioni ecc ecc.
Per ora sono giunto al risultato presente nell'ultimo post.
Linko anche la discussione dove zoros spiegava il suo metodo per l'avvio di sistemi su USB:
viewtopic.php?f=9&t=28066&start=0

Saluti

Ammetto che l'idea/voglia di continuare il progetto di un boot da chroot (perchè l'idea e l'inizio risale a uno o due anni fa, poi lasciato perdere per motivi di tempo) mi è rivenuta dal tuo topic (a cui avevo anche risposto; peccato che credo di non aver premuto il tasto Invia e quindi mi si è cancellata la risposta, ma di riscriverla non mi andava ).
Poi la mia procedura è venuta non perchè mi ci sono messo apposta ma perchè ne avevo giusto bisogno (le conoscenze le ho, quindi non ho avuto bisogno di cercare in giro) ed ho pensato di condividerla.
La procedura di zoros è leggermente più complessa (ma più completa; il mio ha solo 5 righe nell'init) e non mi sono messo a studiarla (anche perchè non mi andava di leggere 3 pagine di post).
Inoltre dando una occhiata rapida mi sembra che al momento nessuna delle due procedure fa boot da chroot (che, se ricordo bene, fosse l'intenzione iniziale ma poi abbandonata nel tuo topic).

Insomma, alla fine ho preso il miscuglio tra le idee che ho letto, quelle che avevo, lo Slackware su pennina USB, lo Slackware su NTFS (mia procedura, ma lasciata a metà, per installare slackware su un filesystem ntfs, o meglio, in un loop file), qualche googlata su switch_root e pivot_root (che sembrino non funzionare bene con le installazioni in chroot) e il man di mount, l'idea di separazione di spazio disco & protezione (come la virtualizzazione); ho messo tutto nel calderone e ne è uscito fuori quello che ho presentato.

Ciao
01

Ho aggiunto alla procedura la possibilità di sharare la /home con la distro main o un altro chroot (pratica comune quando si installano più distribuzioni in più partizioni)
e ho eliminato la storia del /../

Ciao
01