Diese Anleitung basiert auf dem 32-bit chroot Guide aus dem Gentoo-Wiki und erweitert diesen.
Meine Systeme sind inzwischen alle rein 64bit ohne Multilib/32bit Support. Das geht im Alltag ganz gut, aber leider braucht man speziell für alte Windows-Spiele dann doch eine 32bit Umgebung. Das liegt daran, das Wine (Abkürzung für Wine is not an Emulator) kein Emulator ist, sondern nur eine art API-Wrapper (Übersetzer zwischen Windows Funktionen auf Linux-Funktionen/Syscalls). Somit brauchen 32bit-Windows-Programme auch mit Wine eine 32bit Umgebung.
Mein erster Versuch die chroot-Umgebung per Crossdev zu erzeugen ist leider Fehlgeschlagen (theoretisch sollte es aber möglich sein...). Mein zweiter Ansatz war, ein 32bit Gentoo nach Handbuch zu installieren. Dabei muss natürlich auf ein paar Kleinigkeiten geachtet werden:
- Wir müssen erstmal ein Verzeichnis anlegen in dem die chroot-Umgebung entstehen soll
- Wir brauchen natürlich kein Bootmedium
- Wir müssen keine Netzwerkkonfiguration vornehmen
- Wir müssen keine Festplatten partitionieren
- Nach dem Entpacken vom Basissystem müssen wir uns keinen neuen Portage-Tree-Snapshot runterladen sondern können einfach den Portage-Tree vom Host-System mitbenutzen
- Wir können viele Konfigurationsdateien vom Host-System übernehmen
Bitte schaut für Details und Erklärungen zu der Gentoo-Installation in das Gentoo Handbuch. Ich werde hier nur die Abweichungen von der normalen Installation genauer erklären.
Wichtig: Bevor wir anfangen sollten wir sicherstellen, dass unser Host-System auf einem aktuellen Stand ist. Um Probleme zu vermeiden, empfiehlt es sich auch vorher schon mal auf die Stable-Version der nvidia-drivers zu wechseln.
Am Anfang können wir uns, bis darauf das wir kein Boot-Medium benötigen, nach Handbuch vorgehen:
# mkdir -p /usr/gentoo32/usr/portage
# cd /usr/gentoo32
# wget [stage3-file from https://www.gentoo.org/downloads/]
# wget [stage3-file.DIGEST.asc from https://www.gentoo.org/downloads/]
# gpg --verify [stage3-file.DIGESTS.asc]
# tar xpf [stage3-file] --xattrs-include='*.*' --numeric-owner
# chmod 1777 /usr/gentoo32/tmp
# vim /usr/gentoo32/etc/portage/make.conf
Bis hierher war es fast identisch zu der normalen Gentoo Installation. Für die chroot-Umgebung wollen wir jetzt aber möglichst viel vom Host-System wiederverwenden. Besonders wichtig: Damit OpenGL am Ende funktioniert müssen die Grafikkartentreiber in der chroot-Umgebung und außerhalb zusammenpassen. In meinem Fall bedeutet das, dass ich exakt die gleiche nvidia-drivers-Version innerhalb und außerhalb installiert haben muss! Um das zu erreichen, müssen wir sicherstellen, dass wir die gleichen Versionen per Mask/Unmask freigeschaltet haben. Die meiste Zeit über reicht es, wenn wir einfach die entsprechenden Verzeichnisse/ Dateien aus dem Host-System
in die chroot-Umgebung kopieren:
# cp -r /etc/portage/package.keywords /usr/gentoo32/etc/portage
# cp -r /etc/portage/package.unmask /usr/gentoo32/etc/portage
Achtung: Die Einträge innerhalb der kopierten Dateien aus dem Host-System sind natürlich mit dem Keyword ~amd64 versehen. Das kann gut gehen, aber wird auf Dauer sicher zu Problemen führen! Daher sollten wir das beheben:
# cd /usr/gentoo32/etc/portage/package.keywordsOptional: Wenn eine Trennung der Spiel-Umgebung von dem normalen System-Benutzer gewünscht ist, ist jetzt der richtige Zeitpunkt um diesen anzulegen:
# for i in *.keywords; do sed -ri 's/amd64/x86/' $i; done;
# useradd -m -G audio,video,cdrom playerBevor wir die chroot-Umgebung fertig einrichten können, müssen wir noch ein kleines Tool auf dem Host-System installieren:
# emerge -av sys-apps/util-linux
In dem Packet steckt das kleine Tool linux32 bzw. setarch. Damit lässt sich die gemeldete Architektur (z.B. von uname) verändern. Das Tool brauchen wir also, damit die Programmen innerhalb der chroot-Umgebung die richtige Architektur sehen.
Das war jetzt (erstmal) der letzte Schritt den wir im Host-System durchführen müssen. Jetzt können wir alles notwendige in die chroot-Umgebung einhängen und dann das erstmal Mal den Wechsel hinein vornehmen. Bei den ganzen notwendigen Mount-Befehlen gehen wir auch wieder etwas anders vor als im Handbuch beschrieben:
# mount -o bind /dev /usr/gentoo32/dev
# mount -o bind /dev/pts /usr/gentoo32/dev/pts
# mount -o bind /dev/shm /usr/gentoo32/dev/shm
# mount -o bind /proc /usr/gentoo32/proc
# mount -o bind /sys /usr/gentoo32/sys
# mount -o bind /tmp /usr/gentoo32/tmp
# mount -o bind /usr/portage /usr/gentoo32/usr/portage/
# mount -o bind /home /usr/gentoo32/home
# cp -pf /etc/resolv.conf /usr/gentoo32/etc
# cp -pf /etc/passwd /usr/gentoo32/etc
# cp -pf /etc/shadow /usr/gentoo32/etc
# cp -pf /etc/group /usr/gentoo32/etc
# cp -pf /etc/gshadow /usr/gentoo32/etc
# cp -pf /etc/hosts /usr/gentoo32/etc
# cp -Ppf /etc/localtime /usr/gentoo32/etc
Damit haben wir neben dem Portage-Tree auch alle Home-Verzeichnisse und die Benutzerkonfiguration übernommen. Das stellt sicher, dass auch die Berechtigungen passen und wir die selben Benutzer auf dem Host-System und in der chroot-Umgebung haben. Achtung: Veränderungen der Benutzer/ Benutzer-IDs müssen immer sorgfältig zwischen Host und Chroot-Umgebung synchronisiert werden. Auseinender laufende Berechtigungen können schnell zu security-Problemen führen!
Jetzt können wir zum ersten Mal in die chroot-Umgebung wechseln. Dabei können wir auch direkt noch das Profil richtig setzen und eine erste Aktualisierung durchführen:
# linux32 chroot /mnt/gentoo32 /bin/bash
# export PS1="(chroot32) ${PS1}"
(chroot32) # env-update
(chroot32) # source /etc/profile
(chroot32) # emerge -auDN @world
(chroot32) # emerge -av wine-vanilla
An der Stelle beginnt jetzt der spannende Teil. Wir müssen sicherstellen das wir innerhalb und außerhalb der chroot-Umgebung die gleichen nvidia-driver installiert haben. Um Probleme zu vermeiden, leider kommt es immer wieder vor das Versionen der nvidia-drivers nicht mit den neuesten Kernel-Versionen kompatibel sind, sollten wir auch die Kernel-Quellen auf beiden Seiten in der gleichen Version installiert haben. Bitte prüft bei folgendem Befehlen also genau ob es die gleich Version innerhalb und außerhalb der chroot-Umgebung ist:
(chroot32) # emerge -av gentoo-sourcesDie Details Kernel-Configuration überspringe ich hier. Ihr braucht für die chroot-Umgebung zwar keinen vollständigen Kernel bauen, allerdings wollen die nvidia-drivers zumindest einen rudimentäre Kernel-Konfiguration unter /usr/src/linux.
(chroot32) # emerge -av linux-headers
(chroot32) # eselect kernel set [NUMBER]Bevor wir jetzt die nvidia-drivers installieren, sollten wir deren Use-Flags noch anpassen. Schließlich brauchen wir nur den Userspace-Anteil und keine Kernel-Module:
(chroot32) # cd /usr/src/linux
(chroot32) # make menuconfig
(chroot32) # make prepare
(chroot32) # echo "x11-drivers/nvidia-drivers -driver -tools X" > \
/etc/portage/package.use/nvidia.use
(chroot32) # emerge -av nvidia-drivers
(chroot32) # emerge -av mesa-progs
Jetzt ist unsere chroot-Umgebung fertig. In der chroot-Umgebung mit root ausgeführt, sollten glxgears funktionieren und auch die HW-Beschleunigung nutzen.
Leider funktioniert der X-Zugriff noch nicht für den Benutzer player: Für ihn müssen den Zugriff auf den X-Server des Hosts erlauben (Achtung: Der Befehl muss außerhalb der chroot-Umgebung ausgeführt werden):
# xhost +SI:localuser:player
Danach sollte sich glxgears auch vom Benutzer player innerhalb und außerhalb der chroot-Umgebung starten lassen. Somit haben wir unser Ziel erreicht!
Kleine Helferlein
Folgende Helferlein sollten wir uns noch anlegen um die Benutzung der chroot-Umgebung komfortabler zu machen:
1) openrc-Script zum Vorbereiten der Umgebung beim Systemstart: /etc/init.d/gentoo32
#!/sbin/openrc-run
chroot_dir=/usr/gentoo32
depend() {
need localmount net bootmisc
after dhcpd
}
start() {
ebegin "Mounting 32-bit chroot directories"
mount -o bind /dev ${chroot_dir}/dev >/dev/null
mount -o bind /dev/pts ${chroot_dir}/dev/pts >/dev/null &
mount -o bind /dev/shm ${chroot_dir}/dev/shm >/dev/null &
mount -o bind /proc ${chroot_dir}/proc >/dev/null
mount -o bind /sys ${chroot_dir}/sys >/dev/null &
mount -o bind /tmp ${chroot_dir}/tmp >/dev/null &
mount -o bind /usr/portage ${chroot_dir}/usr/portage/ >/dev/null &
mount -o bind /home ${chroot_dir}/home >/dev/null &
eend $? "An error occured while attempting to mount 32bit chroot directories"
ebegin "Copying 32bit chroot files"
cp -pf /etc/resolv.conf ${chroot_dir}/etc >/dev/null &
cp -pf /etc/passwd ${chroot_dir}/etc >/dev/null &
cp -pf /etc/shadow ${chroot_dir}/etc >/dev/null &
cp -pf /etc/group ${chroot_dir}/etc >/dev/null &
cp -pf /etc/gshadow ${chroot_dir}/etc >/dev/null &
cp -pf /etc/hosts ${chroot_dir}/etc > /dev/null &
cp -Ppf /etc/localtime ${chroot_dir}/etc >/dev/null &
eend $? "An error occured while attempting to copy 32 bits chroot files."
}
stop() {
ebegin "Unmounting 32-bit chroot directories"
umount -f ${chroot_dir}/dev/pts >/dev/null
umount -f ${chroot_dir}/dev/shm >/dev/null
umount -f ${chroot_dir}/home >/dev/null &
umount -f ${chroot_dir}/dev >/dev/null &
umount -f ${chroot_dir}/proc >/dev/null &
umount -f ${chroot_dir}/sys >/dev/null &
umount -f ${chroot_dir}/tmp >/dev/null &
umount -f ${chroot_dir}/usr/portage/ >/dev/null &
eend $? "An error occured while attempting to unmount 32bit chroot directories"
}
2) Script zum schnellen Wechsel als root: /usr/local/bin/chroot32
#!/bin/sh3) Automatisches Profile laden und Environment aktualisieren innerhalb der Umgebung: /usr/gentoo32/root/.bashrc
chroot_dir=/usr/gentoo32
cp -pf /etc/resolv.conf $chroot_dir/etc
linux32 chroot $chroot_dir /bin/bash
source /etc/profile
env-update
export PS1="(chroot32) ${PS1}"
4) Script zum schnellen Wechsel in die 32bit-Game Umgebung: /usr/local/bin/play32
#!/bin/sh
chroot_dir=/usr/gentoo32
cp -pf /etc/resolv.conf $chroot_dir/etc
xhost +SI:localuser:player
linux32 chroot $chroot_dir /bin/login -f player
5) sudo ohne Passwort für den Befehl play32: /etc/sudoers
%wheel ALL= NOPASSWD:/usr/local/bin/play32
Fazit/Rückblick/Praxistauglichkeit
Ich habe das auf diese Art jetzt seit ca. einem Jahr im Einsatz und keine größeren Probleme. Schwierigkeiten gab es bisher nur einmal mal:
Ich hatte Anfangs in beiden Umgebungen das Keyword ~amd64 für die nvidia-drivers gesetzt und die damit freigeschaltete Version wurde einmal erst mit Verspätung für x86-stable veröffentlicht. Dummerweise war zeitgleich die verfügbare Version für x86 nicht lauffähig auf dem aktuellsten Linux Kernel (4.16). Somit musste ich ein Kernel-Update hinauszögern :(
Keine Kommentare:
Kommentar veröffentlichen