Due ambienti chroot

[boh]

Ciao a tutti!
Mi trovo in una situazione sdoppiata in quanto ho sul fisso una slackware a 64bit e sul netbook a 32bit, entrambe 13.37.
Per scopi universitari necessito di compilare nuovo software per il netbook, che purtroppo non vanta di una grande potenza di calcolo (non sarebbe un netbook, per l'appunto). Volevo quindi installarmi sul fisso una slack pulita a 32bit in chroot per tale scopo.
Inoltre mi era venuta l'idea di contribuire al repository di slacky anche per il 64bit e quindi volevo installarmi, sempre sul fisso, una slack pulita a 64bit, sempre in chroot (differente da quello a 32bit, ovviamente).

È possibile farlo?

Per il chroot ho trovato questo post di danix in cui spiega come installare il tutto.
Non mi è tuttavia chiaro il binding di proc e sys nè il comando

Codice: Seleziona tutto

sh /etc/profile

Inoltre per compilare nell'ambiente a 32bit, lo slackBuild dovrà riportare l'architettura del sistema in chroot, giusto?
E...per adesso è tutto!

P.S: so che c'è il chroot autobuilder, ma volevo imparare a creare (e gestire) l'mabiente da solo

[ZeroUno]

Più che sh /etc/profile in effetti dovrebbe essere

Codice: Seleziona tutto

source /etc/profile

Serve a caricare tutte le variabili di ambiente della distribuzione in chroot.

il binding serve per rendere visibile quei filesystem speciali anche all'ambiente chrootato. Andrebbe bindata anche la /dev.
Potrebbe tornarti utile il binding della home o anche dell'intera root:

Codice: Seleziona tutto

# mkdir /CHROOT/hostfisico
#mount -o bind / /CHROOT/hostfisico

o

Codice: Seleziona tutto

# mount -o bind /home /CHROOT/home

Personalmente piuttosto che usare installpkg, come descritto in quel post, preferisco utilizzare proprio l'installer di slackware che configura anche altre cose. E' un po' più complicato ma mi sembra più completo. vedi: http://slacky.eu/wikislack/index.php?ti ... re_a_caldo per l'installazione

Qualche volta poi configuro anche l'ambiente di chroot per poterci effettuare il boot (viewtopic.php?t=28951). Mi è capitato di compilare qualche pacchetto (chromium per la precisione) in un ambiente chrootato 32bit su un host a 64bit, ma si vede che qualche comando prendeva informazioni per il configure dal kernel (e quindi i tipi di dati venivano sballati). Inoltre è utile per testare gli applicativi compilati.

Se vuoi contribuire al repository di slacky scrivi a Loris che sarà ben felice di inserirti nel gruppo dei pacchettizzatori.

[conraid]

Se hai un pc con estensioni per le virtualizzazione, usa qemu-kvm e vivi felice
Anche io usavo chroot, ma mi funziona "perfettamente" solo se è nella stessa architettura, quindi dove posso uso qemu-kvm e mi trovo decisamente meglio. Tra l'altro se usi l'immagine raw puoi montarla nel sistema quando ti serve

[boh]

Ringrazio entrambi per le risposte!

@ZeroUno: darò un'occhiata per l'installazione "fatta" dall'installer al posto di installpkg, mentre per il boot credo sia eccessivo per i miei scopi (ovvero la compilazione dei pacchetti) Una volta presa confidenza, scriverò a Loris; questo post è giusto il primo passo verso la pacchettizzazione!

@conraid:

mi funziona "perfettamente" solo se è nella stessa architettura

Intendi che host e chroot devono essere della stessa architettura? Perchè qui nel forum ho letto che molti usano una 32bit in chroot con una 64bit come host; che problemi ti dava? Per qemu-kvm intendi questo pacchetto? Quindi per scongiurare "imperfezioni" sarebbe meglio un chroot della 64bit ed una emulazione della 32bit?

[conraid]

problemi come ti ha detto zerouno, a volte viene presa l'architettura e quindi devi stare attento.
No, non intendo quel pacchetto, da una breve ricerca non sembra ci sia qui su slacky. Intendo questo
http://connie.slackware.com/~alien/slac ... /qemu-kvm/
C'è "molta" differenza di prestazioni, o almeno così a me è sembrato. Però va solo con il modulo kvm del kernel, e con processore abilitato. Infatti lo uso nel notebook e non sul fisso (dove ho un p4 e slack a 32bit)

[ZeroUno]

Indubbiamente la virtualizzazione è la cosa migliore ma, anche con kvm o altre accellerazioni hardware, non può fornire le stesse prestazioni di un ambiente chroot e soprattutto non necessiti di dover fare il boot della distro virtualizzata.

Io il 99% delle volte non ho avuto problemi. Solo con chromium ho avuto problemi. L'unica accortezza è per i pacchetti di SBo che rilevano l'architettura con uname -m se non erro. Per il resto no problem.

[414N]

Stavo per suggerire anch'io la virtualizzazione con kvm se supportata dal processore del pc fisso di boh

Indubbiamente la virtualizzazione è la cosa migliore ma, anche con kvm o altre accellerazioni hardware, non può fornire le stesse prestazioni di un ambiente chroot e soprattutto non necessiti di dover fare il boot della distro virtualizzata.

Le prestazioni non saranno massime ma con l'opportuno supporto hardware, la virtualizzazione viagga a velocità molto simili alla macchina fisica, con gli ovvi benefici della separazione degli ambienti host e guest. Il boot è tranquillamente evitabile salvando lo snapshot della macchina quando si deve sospendere il lavoro (può essere anche fermato nel bel mezzo di una compilazione, cosa forse difficilmente gestibile in un chroot con il suspend to ram/disk offerto dal kernel).

[boh]

Viste le varie argomentazioni, sembrerebbe opportuno mettere in chroot una slackware pulita a 64bit, così da evitare eventuali problemi di configure, e virtualizzare quella a 32bit con qemu-kvm. Il processore è un corei7 ed indagando sul sito della intel supporta la virtualizzazione (e meno male! ).

Al di là di tutto questo, su cui rifletterò, due "partizioni" chroot possono quindi coesistere?

[ZeroUno]

con l'i7 vai tranquillo
io uso tranquillamente vmware con dentro un seven e accelerazione video ed effetti 3d attivi sulla macchina guest.

@ 414N
a me la sospensione su disco o ram funziona perfettamente.

[boh]

Riesumo un attimo il topic per chiedere una cosa.
Alla fine ho installato VirtualBox e le relative guest additions. Queste ultime caricano dei moduli del kernel, ma influiscono sulla corretta compilazione dei pacchetti in stile "slackware pulita"?

[ZeroUno]

no, non credo.

Ma quando finisci di compilare dai sempre una occhiata allo slack-required e vedi che non ci sia nulla che non dovrebbe esserci.

[boh]

no, non credo.

Ma quando finisci di compilare dai sempre una occhiata allo slack-required e vedi che non ci sia nulla che non dovrebbe esserci.

Ok. Ma come faccio a sapere se c'è qualcosa di troppo? Con cosa lo confronto?

[ZeroUno]

se ti mostra qualcosa che non è pacchettizzato, allora è di troppo.

L'output corretto di slack-required è questo:

Codice: Seleziona tutto

libpng >= 1.4.9-x86_64-1
libsoup >= 2.35.5-x86_64-1sl

in cui libpng-1.4.9-x86_64-1 è un pacchetto slackware, libsoup-2.35.5-x86_64-1sl è un pacchetto slacky e entrambi sono presenti in /var/log/packages.
Qualunque altra cosa compaia è di troppo.
Questo potrebbe significare che
1) il pacchetto si è preso una libreria non installata con installpkg
2) c'è un bug in requiredbuilder

Nel dubbio segnalacelo e cerchiamo di scoprire insieme di cosa si tratta.

se invece viene sempre fuori
pacchetto >= versione-arch-build
o similare,
allora sei sicuro.


EDIT:
Errata corrige.
Ho rivisto il codice di requiredbuilder.
A quanto pare se una dipendenza non è pacchettizzata non te lo dice e non la include nello slack-required (si vede che qualche altro tool o versioni più vecchie lo facevano, perchè io questa cosa me la ricordo.
Ho fatto una piccola aggiunta per requiredbuilder.
edita /usr/bin/requiredbuilder
cerca "excludefilters()" intorno alla riga 210 circa
poche righe sopra (appena prima della chiusa parentesi graffa) aggiungi

Codice: Seleziona tutto

        if test -z "$PACKETDEP";then
                echo "========================== $REALFILE non pacchettizzato!!! ================================="
                PACKETDEP=$REALFILE
        fi

In questo modo se un file non è pacchettizzato e il programma vuole però usarlo ti avverte con un messaggio:

Codice: Seleziona tutto

========================== usr/lib64/libJudy.so.1.0.3 non pacchettizzato!!! =================================

Se il pacchetto è grande però potrebbe sfuggire, quindi la modifica aggiunge una cosa sporca nello slack-required:

Codice: Seleziona tutto

glib2 >= 2.28.6-x86_64-1
glibc-solibs >= 2.15-x86_64-2
gtk+2 >= 2.24.4-x86_64-1
popt >= 1.7-x86_64-3
usr/lib64/libJudy.so.1.0.3 >=
zlib >= 1.2.6-x86_64-1

cioè ti indica la libreria che ha fallito.
Se vedi qualcosa del genere stai sicuro che c'è qualcosa che non hai pacchettizzato.

EDIT2:
In alternativa pacchettizza le virtualbox tools e poi vedi se il pacchetto ti compare nello slack-required.
(Non è necessario creare il pacchetto. è sufficiente individuare i file che ha creato l'installer (bastano le librerie) e crearti un file /var/log/packages/virtualbox-tools-0-x86_64-0 contenente

Codice: Seleziona tutto

PACKAGE NAME:     virtualbox-tools-0-x86_64-0
COMPRESSED PACKAGE SIZE:     0K
UNCOMPRESSED PACKAGE SIZE:     0K
PACKAGE LOCATION: virtualbox-tools-0-x86_64-0
PACKAGE DESCRIPTION:
virtualbox-tools: VirtualBox Tools
FILE LIST:
./
usr/
usr/lib64/
usr/lib64/libvirtualbox.so.0.0
usr/lib64/libboxvirtual.so.1.2
....

Puoi aiutarti con http://www.slacky.eu/slacky/Find_extern ... kPkg_files per individuare quali sono i file)

[boh]

Grazie per l'esauriente risposta!!