Installation chroot 32 bits transparent

Il arrive fréquemment d’avoir une application 32 bits à faire fonctionner dans un environnement 64 bits. Faire un environnement chroot 32 bits est dans ce cas la solution la plus fiable lorsque les i32libs ne suffisent pas. C’est par exemple souvent le cas pour les applications propriétaires (maple, skype, …). Cela donne l’assurance que l’ensemble fonctionnera bien. Cette méthode convient également à ceux voulant faire tourner une application sid dans une Etch sans rapatrier des morceaux de sid alors qu’un backport est trop délicat à faire.

Pour faire cela il faut

  1. Installer un chroot 32bits et installer les applications

  2. Intégrer le tout dans l’environnement 64 bits.

  3. Se fait par debootstrap:
    En clair, si on installe le tout sous /32bits

# mkdir /32bits
# cd /
# debootstrap --arch i386 etch /32bits http://ftp.fr.debian.org/debian/

L’ensemble s’installe. Il n’y a pas de difficultés particulières. debootstrap est une méthode d’installation de debian très efficace.
Il s’agit après de compléter l’installation. Pour cela

  • Créer le fichier /32bits/etc/apt/sources.list en le mettant conforme à vos désirs.
  • Créer les mêmes utilisateurs. Cela peut être fait par exemple par
# grep "^[^:]*:x:[0-9][0-9][0-9][0-9]:" /etc/passwd >> /32bits/etc/passwd
# grep "^[^:]*:x:[0-9][0-9][0-9][0-9]:" /etc/group >> /32bits/etc/group

(cela recopie les utilisateurs standards sur le système 32 bits).

Il s’agit ensuite d’installer les applications voulues. Pour cela il faut successivement faire

# mount -t proc none /32bits/proc
# chroot /32bits
# apt-get update
# apt-get install truc32bitsquejeveux

Parfois, /dev doit être aussi vu de /32bits lors de l’installation de paquets, faire pour cela

# mount -o bind /dev /32bits/dev

qui monte /dev en bind de manière classique. Attention, bien évidemment lors de l’installation de paquets, il peut y avoir des conflits au moment de lancement de serveurs si ceux ci tournent aussi sous l’environnement 64 bits. Les scripts d’installation en tiennent compte en général.

À ce stade, en général je redémarre la machine pour être sur de partir d’un système tel qu’il sera au lancement de la machine.
Pour imprimer, il suffit d’installer cupsys-client ou lprng mais ne pas installer une imprimante, il faut utiliser le cups 64 bits.

  1. Ensuite il s’agit d’intégrer le tout dans l’environnement 64 bits. Tout d’abord, il faut s’assurer que les répertoires utilisateurs, la connexion avec X et les démons 64 bits (cups par exemple) se passera bien. Il faut en fait donc monter en «bind» les répertoires /home (utilisateurs), /tmp (pour X et quelques douilles (sockets)), /var/run (même raison, cups, lprng, etc) et /dev (périphériques). On peut parfois avoir besoin de /sys dans le 32 bits. Pour cela rajouter au /etc/fstab du 64 bits les lignes suivantes
/home           /32bits/home       none    bind            0       0
/tmp            /32bits/tmp        none    bind            0       0
proc            /32bits/proc       proc    defaults        0       0
#none           /32bits/sys        sysfs   defaults
/run            /32bits/run        none bind            0       0
/dev            /32bits/dev        none    bind            0       0

[edit: changement /var/run -> /run]
et faire

mount -a

Le repertoire /32bits/tmp est le même que /tmp, etc.
Installer dchroot

# apt-get install dchroot

Rajouter dans /etc/dchroot.conf les lignes

# etch i386
i32 /32bits

Désormais l’utilisateur standard peut lancer une application 32 bits en tapant

$ dchroot -c i32 -d application32bits argument1 argument2

Il doit voir le répertoire personnel de l’utilisateur, il doit pouvoir imprimer, etc le tout de manière complètement transparente.

Un environnement chroot 32 bits de base pèse 128M plus les applications installées. Sur un disque de 160G, c’est assez indolore pour une solution très pratique et complètement transparente pour l’utilisateur. La technique est identique pour installer une application experimentale ou sid sur un environnement etch qu’on ne veut pas fragiliser.

[lire la suite du fil pour peaufiner (message de Matt et ma conclusion)

Merci pour ce tuto :smt023

OOooh c’est beaux !
Juste un ch’tite question, bind sert à quoi ?

[quote=“debianhadic”]OOooh c’est beaux !
Juste un ch’tite question, bind sert à quoi ?[/quote] Ca “monte” un répertoire à un nouvel endroit.

mount -o bind /dev /32bits/dev permet par exemple d’accèder ensuite à /dev soit par /dev, soit par /32bits/dev. C’est plus “en dur” qu’un ln -s.

fran.b,
Rem. 1: Pourquoi recopier les users ? C’est inutile: de toutes les manières, les appels à pam ne dépendent pas du contenu du /etc/passwd dans le chroot.

Rem. 2: dchroot est en fin de vie, tu devrais regarder schroot (fonctionne presque pareil, mais plus sécurisé).

Rem. 3:
pour l’utilisation de dhcroot, il y a plus subtil que de taper une ligne dchroot -c i32 -d application32bits argument1 argument2

on peut créer un raccourci pour lancer une application du chroot en faisant la chose suivante:

  • créer un script /usr/local/bin/do_dchroot, et le rendre executable, avec le contenu suivant:

#!/bin/sh /usr/bin/dchroot -c i32 -d "`echo $0 | sed 's|^.*/||'` $*"

  • passer dans le chroot et créer un nouveau nom pour la commande que vous voulez lancer pour qu’elle ne rentre pas en conflit avec la même commande en environnement 64, par exemple:

dchroot -c i32 -d ln -s /usr/sbin/synaptic /usr/sbin/synaptic32

  • ressortir du chroot et créer une commande du même nom dans l’environnement 64:

Aprés, dans l’exemple pour lancer la version 64 de synaptic, c’est juste synaptic, et pour lancer la version en environnement 32 bits, c’est juste synaptic32.

[quote=“mattotop”][quote=“debianhadic”]OOooh c’est beaux !
Juste un ch’tite question, bind sert à quoi ?[/quote] Ca “monte” un répertoire à un nouvel endroit.

mount -o bind /dev /32bits/dev permet par exemple d’accèder ensuite à /dev soit par /dev, soit par /32bits/dev. C’est plus “en dur” qu’un ln -s.

fran.b,
Rem. 1: Pourquoi recopier les users ? C’est inutile: de toutes les manières, les appels à pam ne dépendent pas du contenu du /etc/passwd dans le chroot.[/quote]Pour les application qui utilisent les champs de passwd.

Ah, je connaissais pas, je vais regarder. Tu connais mon penchant pour les trucs neufs…

[quote]
Rem. 3:
pour l’utilisation de dhcroot, il y a plus subtil que de taper une ligne dchroot -c i32 -d application32bits argument1 argument2

on peut créer un raccourci pour lancer une application du chroot en faisant la chose suivante:

  • créer un script /usr/local/bin/do_dchroot, et le rendre executable, avec le contenu suivant:

#!/bin/sh /usr/bin/dchroot -c i32 -d "`echo $0 | sed 's|^.*/||'` $*"

  • passer dans le chroot et créer un nouveau nom pour la commande que vous voulez lancer pour qu’elle ne rentre pas en conflit avec la même commande en environnement 64, par exemple:

dchroot -c i32 -d ln -s /usr/sbin/synaptic /usr/sbin/synaptic32

  • ressortir du chroot et créer une commande du même nom dans l’environnement 64:

Aprés, dans l’exemple pour lancer la version 64 de synaptic, c’est juste synaptic, et pour lancer la version en environnement 32 bits, c’est juste synaptic32.[/quote]
Assez pratique à l’usage ce truc…

C’est quoi dchroot et schroot par rapport à chroot ?

Ça permet à un utilisateur de lancer chroot dans un environnement donné.

[quote=“MisterFreez”]C’est quoi dchroot et schroot par rapport à chroot ?[/quote] Surtout, contrairement à la commande chroot qui effectue une opération qu’on pourrait dire atomique, non seulement ça execute le chroot à proprement parler, mais ça emballe ce chroot avec tout un tas de précautions et de fonctionnalités comme, par exemple et si je me souviens bien, une gestion fine des paramètres env passés au chroot, un changement automatique de l’uid à l’execution, le montage automatique de disques, ou ce genre de choses.

Sympa ce tuto…chroot à toujours été un peu flou pour moi, quand j’aurais le temps j’essayerai de suivre ton tuto

J’ai adapté le script de Matt:

#!/bin/sh CMD=`echo $0 | sed -e 's/32$//'` ARG="$*" dchroot -q -c i32 -d "$CMD $ARG"
nommé en dchroot, pour lancer l’application /usr/bin/pouet en environnement 32 bits, on fait juste un

ln -s /usr/local/bin/do_chroot /usr/bin/pouet

Si l’application existe aussi en 64bits, on fait

ln -s /usr/local/bin/do_chroot /usr/bin/pouet32

et dans ce cas
$ pouet lance pouet en 64bits
$ pouet32 lance pouet en 32bits

Très bonne astuce. Le tout est vraiment transparent. Ça permet d’interfacer SAGE 64 bits avec un Maple 32 bits sans souci.

J’ai procede aux operations de le premiere etape. Avant de passer a la deuxieme, voila quelques questions de debutant :

ne m’a pas copie mon /etc/group dans /32bits/etc/group. Je veux dire, il y a bien un fichier /32bits/etc/group, mais il n’est pas identique a mon /etc/group, et pour cause, il n’y aucun user dedans. Juste les noms des groupes et c’est tout. C’est normal? Si non, c’est grave?

J’ai bien installe les paquets dont j’aurai besoin pour la compilation de mon programme 32bits, j’ai juste des :

[quote]perl: warning: Falling back to the standard locale (“C”).
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "fr_FR.UTF-8"
are supported and installed on your system.[/quote]
Ca risque de poser des problemes par la suite?

En tous cas cool, si j’arrive a faire fonctionner le truc, ca m’arrangera bien. D’autant plus que je m’etais deja dit qu’un jour faudrait que je m’interesse a chroot, voila c’est l’occasion. Merci.

Bon ben je suis alle jusqu’au bout et ca semble fonctionner.
Y’a juste un truc qui m’echappe, la compilation du programme 32 bits que je veux, je dois la faire au debut du tuto quand je suis dans le chroot? Si je peux la faire plus tard, comment je dois proceder?
Faut refaire un

je suppose?
C’est ce que j’ai tente, mais vu que ma compilation echoue, je voudrais etre sur que c’est la bonne methode pour savoir si ca vient de la ou pas.

Pour faire ta compil 32, une fois installé le chroot, il te suffit de passer dans le chroot en faisant dchroot -d. Là, tu es en 32 bits, et tu peux y faire ta compil.

Ok merci, je penses avoir tous les elements pour me demerder seul maintenant.

Bon voila, en essayant de de fouiller du cote du /etc/security/limits.conf pour faire fonctionner cet Ardourvst, qui s’il est finalement compile ne fonctionne toujours pas, j’ai remarque cette ligne que j’ai mise en gras :

[quote]# can be one of the following:

- core - limits the core file size (KB)

- data - max data size (KB)

- fsize - maximum filesize (KB)

- memlock - max locked-in-memory address space (KB)

- nofile - max number of open files

- rss - max resident set size (KB)

- stack - max stack size (KB)

- cpu - max CPU time (MIN)

- nproc - max number of processes

- as - address space limit

- maxlogins - max number of logins for this user

- maxsyslogins - max number of logins on the system

- priority - the priority to run user process with

- locks - max number of file locks the user can hold

- sigpending - max number of pending signals

- msgqueue - max memory used by POSIX message queues (bytes)

- nice - max nice priority allowed to raise to

- rtprio - max realtime priority

# - chroot - change root to directory (Debian-specific)

#

#* soft core 0
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#ftp - chroot /ftp
#@student - maxlogins 4

Support Temps réel pour le groupe audio

@audio - rtprio 100
@audio - nice -10
@audio - memlock 1500000[/quote]

Autant je comprends bien les items que j’utilise d’habitude dans ce fichier, autant je comprends mal cet item “chroot”, son usage et son utilite. Quelqu’un peut m’eclairer?

Je ne sais pas trop, mais ce genre de paramètre permet en général de faire l’install du paquet dans un environnement chrooté dans un but de sécurisation, mais peut être que dans le cas qui t’interresse tu dois utiliser ce paramètre pour déclarer que tu es dans un chroot ?

Sinon, quand tu dis qu’il ne fonctionne pas, tu as bien installé tout >dans le chroot< ?
Et quand tu dis que tu joues avec limits.conf, tu parles bien du limits.conf >dans le chroot< ?

[quote=“mattotop”]Je ne sais pas trop, mais ce genre de paramètre permet en général de faire l’install du paquet dans un environnement chrooté dans un but de sécurisation, mais peut être que dans le cas qui t’interresse tu dois utiliser ce paramètre pour déclarer que tu es dans un chroot ?

Sinon, quand tu dis qu’il ne fonctionne pas, tu as bien installé tout >dans le chroot< ?
Et quand tu dis que tu joues avec limits.conf, tu parles bien du limits.conf >dans le chroot< ?[/quote]
Ardour fonctionne avec jackd comme serveur de son temps reel. Donc pour compiler ardour il faut jackd de toutes facons a la base. Je l’ai donc installe dans le chroot 32bit avec tous les autres paquets necessaires a la compilation (ce qui avec les dependances et tutti quanti fait que je suis passe de 48% a 62% de ma partiton / occupee d’ailleurs).
Donc pour lancer jackd et avoir le temps reel il me faut parametrer ce /32bits/etc/security/limits.conf tout comme je l’avais parametre dans le 64bits d’ailleurs (le quote au dessus est le limits.conf du chroot). J’ai aussi du changer les droits de /32bits/dev/shm en drwxrwxrwt comme ca l’etait pour le 64bits.
Donc la j’ouvre un terminal, je fais :

[quote]$ dchroot -d
I : [chroot i32] Exécution de l’interpréteur de commandes : « /bin/bash »
kaos@geezer:~$ /usr/bin/jackd -t 0 -m -p 128 -R -P 90 -T -d alsa -n 2 -r 96000 -p 1024 -d hw:0,0
jackd 0.109.2
Copyright 2001-2005 Paul Davis and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

JACK compiled with System V SHM support.
loading driver …
apparent rate = 96000
creating alsa driver … hw:0,0|hw:0,0|1024|2|96000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 32bit little-endian
ALSA: use 2 periods for playback[/quote]
Ca fonctionne en 32bits.
J’ouvre un autre terminal, je fais :

et il reste bloque a l’image de startup et jackd se ferme.

[quote]$ subgraph starting at ardour timed out (subgraph_wait_fd=7, status = 0, state = Triggered)

**** alsa_pcm: xrun of at least 0.020 msecs

cannot read event response from client [ardour] (Connection reset by peer)
bad status for client event handling (type =8)
cannot send event to client [ardour] (Broken pipe)
bad status for client event handling (type =8)

**** alsa_pcm: xrun of at least 29.683 msecs[/quote]
Et voila. Avant il me mettait une erreur de segmentation qui semble avoir disparue depuis que j’ai modifie /32bits/etc/security/limits.conf, avant [quote]@audio - memlock 1500000[/quote] etait en memlock unlimited.

Bon j’ai pas un besoin urgent de l’utiliser avec les vst, donc je cherche tranquillement des pistes.

Bon, aussi bien pour le limits.conf que pour /dev, tu ne devrais pas travailler avec ceux du chroot mais les partager entre les deux environnements.

Pour le limits.conf, puisque to chroot est dans la partoche racine, fais un lien (pas symbolique) entre /32bits/etc/security/limits.conf et /etc/security/limits.conf .
Tu peux aussi éventuellement faire la même chose pour partager (au lieu de recopier) d’autres fichiers utiles comme /etc/password, /etc/group, ou /etc/fstab.

Pour /dev, il faut imperativement mapper le /dev de l’install 64 sur celui de l’install 32, avant de commencer à créer des devices dans le chroot: normalement, si ton jackd fonctionne en 64 bits, tu n’auras pas besoin (et AMA, c’est ça qui gène) de le lancer dans le chroot 32. Ton ardour 32 du chroot causera alors au jackd 64 en passant par le device créé dans le /dev commun aux deux environnements.
Pour faire ça, tu peux tester avec mount -t bind /dev /32bits/dev, et si c’est bon, tu mets ce montage en automatique dans fstab, pour que ça soit monté au boot.
Une bonne pratique aussi, c’est de faire la même chose avec /home pour avoir la même chose en 32 et 64 bits.

Tu as bien fait un mount /proc, aussi, dans ton environnement chrooté ?

Juste avant de partir, je pense que tes pbms viennent effectivement de là, regardes les «montages» en bind du tuto, je les ai fait afin de ne pas avoir de souci pour le matériel aisni que pour les connexions via des sockets unix (je pense surtout aux imprimantes par exemple mais pas seulement). C’est pour cela que je partage également /var/run et /tmp.

[quote]Juste avant de partir, je pense que tes pbms viennent effectivement de là, regardes les «montages» en bind du tuto, je les ai fait afin de ne pas avoir de souci pour le matériel aisni que pour les connexions via des sockets unix (je pense surtout aux imprimantes par exemple mais pas seulement). C’est pour cela que je partage également /var/run et /tmp.
Juste avant de partir, je pense que tes pbms viennent effectivement de là, regardes les «montages» en bind du tuto, je les ai fait afin de ne pas avoir de souci pour le matériel aisni que pour les connexions via des sockets unix (je pense surtout aux imprimantes par exemple mais pas seulement). C’est pour cela que je partage également /var/run et /tmp.[/quote]
J’ai bien monte le tout dans le /etc/fstab :

[quote]# /etc/fstab: static file system information.

proc /proc proc defaults 0 0
/dev/sda2 / ext3 errors=remount-ro 0 1
/dev/sda4 /home ext3 defaults 0 2
/dev/sda1 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0

32 bits

/home /32bits/home none bind 0 0
/tmp /32bits/tmp none bind 0 0
proc /32bits/proc proc defaults 0 0
#none /32bits/sys sysfs defaults
/var/run /32bits/var/run none bind 0 0
/dev /32bits/dev none bind 0 0
[/quote]
Ca me fait penser, faut il faire le mount -a a chaque fois ou est-ce cense etre monte automatiquement? Parce que dans ce cas le /dev/shm aurait du etre identique, or il ne l’etait pas… Et pourtant mon /home est bien monte dans /32bits/home.
Et la vite fait je viens de faire mount -a au cas ou, j’ai lance dchroot -c i32 -d ardourvst, il ne prend pas en compte le fait que jackd est lance en 64bits.

[quote=“mattotop”]Bon, aussi bien pour le limits.conf que pour /dev, tu ne devrais pas travailler avec ceux du chroot mais les partager entre les deux environnements.

Pour le limits.conf, puisque to chroot est dans la partoche racine, fais un lien (pas symbolique) entre /32bits/etc/security/limits.conf et /etc/security/limits.conf .
Tu peux aussi éventuellement faire la même chose pour partager (au lieu de recopier) d’autres fichiers utiles comme /etc/password, /etc/group, ou /etc/fstab.

Pour /dev, il faut imperativement mapper le /dev de l’install 64 sur celui de l’install 32, avant de commencer à créer des devices dans le chroot: normalement, si ton jackd fonctionne en 64 bits, tu n’auras pas besoin (et AMA, c’est ça qui gène) de le lancer dans le chroot 32. Ton ardour 32 du chroot causera alors au jackd 64 en passant par le device créé dans le /dev commun aux deux environnements.
Pour faire ça, tu peux tester avec mount -t bind /dev /32bits/dev, et si c’est bon, tu mets ce montage en automatique dans fstab, pour que ça soit monté au boot.
Une bonne pratique aussi, c’est de faire la même chose avec /home pour avoir la même chose en 32 et 64 bits.

Tu as bien fait un mount /proc, aussi, dans ton environnement chrooté ?[/quote]
Bon, ca aborde des trucs que je ne connais pas trop encore (et c’est tant mieux).
Quand tu me dis de faire un lien c’est bien par le fstab? Dans ce cas c’est fait depuis le debut. Si non, quelle est la procedure?
Bon je viens de lancer un [quote]# mount -t bind /dev /32bits/dev
mount: unknown filesystem type ‘bind’
[/quote]
Et ce unknown file system type ‘bind’ pourait bien etre une piste.