Linux Kompatibilität mit Debian statt CentOS?

Rosendoktor

Well-Known Member
Hallo zusammen,

hab' mich mit dem mitgelieferten linux-c7 nie so richtig anfreunden können, insbesondere hat mich gestört wie Linux Software da "installiert" werden muss und ich wusste auch nie recht, woher ich fehlende Bibliotheken bekommen soll. Irgendwann hatte ich mal Softmaker Office damit zum laufen gebracht, das war's dann auch.

Bei meinen schon verzweifelten Versuchen, Kodi 18.6 mit dem Plugin was ich brauche auf FreeBSD zu bekommen, hab' ich mir dann mal die Struktur unter /compat/linux angeschaut und mir gedacht, warum nicht einfach ein Debian da rein bügeln?

Gedacht, gemacht.

Also vom parallel installierten Debian 10 aus ein Verzeichnis /stretch auf einer gemeinsam genutzten ZFS Partition angelegt und per debootstrap ein Debian Stretch da installiert. Dann per chroot in das frische Debian Stretch gewechselt und mit apt noch etwas Software installiert, u.a. Emacs X11, VLC, Kodi 18.6, Scribus (DTP) und MakeMKV.

Von FreeBSD aus dann einfach das Verzeichnis /stretch per nullfs mount nach /compat/linux gemounted, dazu noch linprocfs und linsysfs, und noch einen Symlink ld-linux-x86-64.so.2 von absoluten auf relativen Pfad geändert.

Ergebnis:

* Die Systemtools von Debian laufen, soweit sie Sinn machen (z.B. ps, top, nano usw.).
* Emacs X11 läuft einwandfrei, findet nur das Home Verzeichnis des startenden Benutzers nicht.
* Scribus (ein GTK+ Desktop Publishing Programm) läuft einwandfrei, nur mit seltsamen Fonts.
* VLC läuft auch, mit den gleichen seltsamen Fonts und ohne Hardwareunterstützung, Video ruckelt und ist etwas in Zeitlupe, kein Ton (beschwert sich wegen fehlendem Alsa).

MakeMKV und Kodi starten nicht weil die libGL* Bibliotheken nicht die richtigen sind, es ist eine Nvidia Karte verbaut. Also noch die Nvidia Treiber im Debian nachinstalliert, da müssen dann noch etliche Symlinks korrigiert werden. Dann verschwindet der libGL* Fehler.

* MakeMKV bricht immer noch ab wegen fehlendem Syscall, irgendwas mit mempolicy...
* Kodi bleibt nach dem Start einfach hängen, ohne ein Fenster zu öffnen und ohne Fehlermeldung...
* VLC hab ich damit nicht nochmal ausprobiert (hab's wieder plattgemacht, da ich beim Symlinks korrigieren zu sehr gepfuscht hatte).

Zusammenfassung:

* Debian Buster läuft gar nicht, jedes Binary liefert "Kernel too old", da ist die API zu alt... Debian Stretch scheint zu funktionieren.
* Die eigentlichen Zielprogramme, Kodi 18.6 und MakeMKV, sind nicht lauffähig. Halte das für aussichtslos.
* Das meiste andere scheint zu funktionieren.
* Mit einem im chroot gepflegten Debian kann man Software bequem und sauber per apt installieren und deinstallieren, mit allen Abhängigkeiten, ohne aufwendige Bibliothekskopiererei.
* Es gibt kein Netzwerk. Ein einfaches /compat/linux/bin/ping 8.8.8.8 liefert nur "Die Adressfamilie für Hostnamen wird nicht unterstützt". Selbiges übrigens auch im linux-c7.

Fragen:

* Macht es Sinn, das weiter zu verfolgen und zu optimieren (z.B. Nvidia Treiber für Video, Alsa/Pulseaudio für Audio, Fonts nachinstallieren...), oder bin ich da komplett auf dem Holzweg?
* Warum geht da offenbar kein Netzwerkzugriff, auch nicht im linux-c7?

Andere Frage:

* Welche Möglichkeiten hätte ich noch, Kodi 18.6 auf FreeBSD zu bekommen? Es gibt nur Kodi 17.6 und 19.0 nativ, das benötigte Plugin lässt sich mit 17.6 zwar kompilieren, stürzt aber ab, hab das aufgegeben. Virtualisierung kommt auf dem altersschwachen Pentium D nicht in Frage... Irgendeine Containerlösung?

Grüße,

Robert
 
Das scheint doch nen centos zu sein, solange es Netzwerk gibt sollte man doch mit dem yum arbeiten können?
 
Kurz dazwischen, wenn in /compat/linux/ der ganze CentOS kram ist, könnte ich dann im Prinzip meine CentOS Installation beispielsweise vom Notebook dahin verfrachten mit diversen Libraries zu Spielen? Interessant aber klingt auch nach ner Menge Aufwand.
 
Kleine Anmerkung noch: Netzwerkzugriff funktioniert für die Linux Binaries, der Folding@home Client z.B. kann sich Work Units holen und wieder hochladen (sowohl mit Debian als auch linux-c7). Warum ein ping nicht geht k.A.
 
Das scheint doch nen centos zu sein, solange es Netzwerk gibt sollte man doch mit dem yum arbeiten können?
Yum ist da nicht vorhanden. Vielleicht könnte man es hinkopieren und dann benutzen, k.A. Das Debian apt funktioniert schon mal nicht.

Dieses /compat/linux ist aber kein Container, auch keine chroot Umgebung, insofern bezweifle ich dass es funktionieren könnte. Ich blick ehrlich gesagt selber nicht durch was es eigentlich ist ausser dass es Linux Syscalls abfängt und an den FreeBSD Kernel durchreicht. Wann die Linux Binaries aber auf welche Libraries und vor allem welche Pfade zugreifen ist mir unklar.
 
Also "sauberer" ist es, wenn man sich für Linux Software, die mit den linux-c7 Paketen laufen soll, eigene Ports schreibt -- leider ist das nicht ganz einfach. Es hilft aber auch nicht, in /compat/linux einfach eine komplett andere Distribution zu installieren: Die Linux-Emulation ist nie "vollständig", es liegt also nicht nur an der Distribution wenn etwas nicht funktioniert.

  • "Kernel too old" sollte nicht das Hauptproblem sein, welche Linux kernelversion dem Userspace gemeldet wird ist konfigurierbar. Oft reicht ein sysctl compat.linux.osrelease=3.2.0
  • Speziell MakeMKV hat mehrere Problemchen: Das GUI wirst du nie zum laufen kriegen, weil der "guiserver" mode im closed-source Binary nicht funktioniert, wenn es auf FreeBSD läuft. Der Zugriff auf die optischen Laufwerke nutzt sg devices, das ist der "SCSI generic" Kram von Linux. Die gibt es auch auf FreeBSD, man muss aber einen Kernel damit bauen. Um die Laufwerke zu finden wird sysfs benutzt, was es zwar auf FreeBSD auch gibt, aber die Einträge, die MakeMKV sucht, fehlen. Nichtsdestotrotz kann man MakeMKV an der Commandline nutzen, und mein Port ist seit einiger Zeit im Tree, ich würde dir empfehlen, den einfach zu verwenden. Aktuell liegt da noch 1.15.0, mit 1.15.1 wird es sogar ein installierbares Paket geben (das liegt noch hier rum und wartet auf einen Commit: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245665) -- allerdings ums Kernel bauen kommt man wegen sg device nicht herum.
 
Dieses /compat/linux ist aber kein Container, auch keine chroot Umgebung, insofern bezweifle ich dass es funktionieren könnte. Ich blick ehrlich gesagt selber nicht durch was es eigentlich ist ausser dass es Linux Syscalls abfängt und an den FreeBSD Kernel durchreicht. Wann die Linux Binaries aber auf welche Libraries und vor allem welche Pfade zugreifen ist mir unklar.
Ein Linux binary sucht jeden Pfad erst mit /compat/linux prefixed, nur wenn da nichts gefunden wird, wird der Pfad ohne das Prefix verwendet. Für das Linux binary ist das transparent, es "sieht" immer nur Pfade ohne dieses Prefix. Ist also quaso ein "Overlay".
 
Warum ein ping nicht geht k.A.
Weil manche lowlevel APIs eben auf FreeBSD nicht so funktionieren wie auf Linux. Wenn man etwas anderes als Centos 7 verwenden will empfiehlt sich ein eigenes Jail abseits von /compat/linux, ich habe da auch mal mit Devuan herumgespielt, hier gibt's einen Thread dazu: https://forums.freebsd.org/threads/setting-up-a-debian-linux-jail-on-freebsd.68434/ -- für Linux "system-tools", die da nicht funktionieren, habe ich mir so beholfen, dass ich die statisch gelinkten FreeBSD-Versionen aus /rescue in das Jail kopiert habe.
 
Welche Möglichkeiten hätte ich noch, Kodi 18.6 auf FreeBSD zu bekommen? Es gibt nur Kodi 17.6 und 19.0 nativ, das benötigte Plugin lässt sich mit 17.6 zwar kompilieren, stürzt aber ab, hab das aufgegeben. Virtualisierung kommt auf dem altersschwachen Pentium D nicht in Frage... Irgendeine Containerlösung?
Hm, das hab ich mir auch mal kurz angesehen. Kodi 19 gibt es noch nicht, denke mal der kodi-devel Port ist einfach dazu gedacht, mehr oder weniger regelmäßig dem git master zu folgen :) Warum allerdings multimedia/kodi auf so einer alten Version festhängt erschließt sich mir nicht. Dass der Port keinen Maintainer hat, ist ein erster Hinweis ;)

Also, der "richtige" Weg wäre sicher, sich den Port mal vorzunehmen und auf die neueste Version (aktuell wohl 18.6) zu ziehen.
 
Danke @Zirias für Deine ausführlichen Erklärungen! Mittlerweile verstehe ich etwas besser, wie das ganze funktioniert. Auch wenn das eigentliche Ziel, die Multimedia Anwendungen, wohl leider so nicht geht...

Etwas verwirrend waren dann noch Skripten, denn die werden wenn direkt gestartet auch von FreeBSD direkt ausgeführt, was je nach Pfad im Shebang entweder den FreeBSD Interpreter ausführt (falls der Pfad passt), oder einen falschen (bei /bin/sh), oder gar keinen (bei /bin/bash)... Letztendlich muss man den binären Interpreter in /compat/linux starten und das Skript als Argument übergeben, dann laufen sie in der Linux Umgebung und greifen auf die richtigen Pfade zu.

Lustig ist, dass man so auch Linux Daemons über deren Linux Startskript in /etc/init.d/ starten kann. Warum auch immer man das machen sollte... In meinem Fall ist es der Folding@home Client, der ist leider Closed Source. Der läuft nun wenn FreeBSD gebootet ist in der Linux Umgebung, wenn Debian gebootet ist in einem systemd-nspawn Container. Was leider nicht geht, ist /compat/linux/sbin/init zu starten (also das alte sysvinit), und damit das Linux quasi zu "booten"... Wobei meiner Ansicht nach gar nicht viel fehlt damit das gehen könnte (?).

Deinen MakeMKV Thread hab ich mit Interesse verfolgt, da bei mir eigentlich immer auch ein Linux greifbar ist hab ich es aber noch nicht ausprobiert.

Ich bleib jetzt dabei, das Debian Stretch unter /compat/linux zu mounten, zwischenzeitlich hatte ich auch CentOS 7 probiert, welches sich mit dem "rinse" Tool genauso einfach bootstrappen lässt wie Debian, aber damit läuft noch weniger (ist wohl langsam echt zu alt). Vielleicht probiere ich auch nochmal Buster, mit der gefakten Kernel Version.

Danke nochmal,

Robert
 
Ich finde aber du ziehst teilweise die falschen Schlüsse, deshalb hier mal noch stichpunktartiger Widerspruch, wo es mir angebracht scheint ;)
  • Die Linux-Kompatibilität von FreeBSD geht ziemlich weit, aber es bleibt eben doch eine "Emulation". Die erste Wahl ist immer "native", und bei Opensource ist das in den meisten Fällen auch möglich. Bezüglich Kodi: man kann auch einen Bug report schreiben, dass ein Port "out of date" ist, ohne ihn gleich selbst zu aktualisieren. Natürlich ist letzteres oft schneller und einfacher, aber mir scheint Kodi ist nicht gerade der simpelste Port um sich einzuarbeiten ;)
  • Shebangs funktionieren an sich wie erwartet nach der gleichen Logik: die Shell startet den angegebenen Interpreter. Wenn du in einer "Linux shell" bist greift also das /compat/linux overlay, andernfalls nicht.
  • Ich würde dringend empfehlen, in /compat/linux die "linux-c7" ports zu belassen. Grund: Das ist nunmal das "offizielle" Userland zum FreeBSD "Linuxulator". Es gibt einige Ports von Linux-Software (dazu zählt jetzt auch mein MakeMKV port, auch einen für folding@home gibt es inzwischen, usw), die sich genau darauf verlassen und von den entsprechenden linux-c7 ports abhängen. Die funktionieren alle nur richtig, wenn man da nicht herumfummelt. Natürlich kann man andere Linux userlands ausprobieren, da wäre aber die Empfehlung, das in einem jail zu tun. Ein "Devuan jail" hatte ich auch schonmal testweise so weit, dass es per sysv-init "booten" konnte. Was aber speziell MakeMKV angeht, zumindest aktuell wirst du das nie dazu kriegen, dass es mit GUI läuft, egal was du bastelst :)
 
Ich finde aber du ziehst teilweise die falschen Schlüsse, deshalb hier mal noch stichpunktartiger Widerspruch, wo es mir angebracht scheint ;)
  • Die Linux-Kompatibilität von FreeBSD geht ziemlich weit, aber es bleibt eben doch eine "Emulation". Die erste Wahl ist immer "native", und bei Opensource ist das in den meisten Fällen auch möglich. Bezüglich Kodi: man kann auch einen Bug report schreiben, dass ein Port "out of date" ist, ohne ihn gleich selbst zu aktualisieren. Natürlich ist letzteres oft schneller und einfacher, aber mir scheint Kodi ist nicht gerade der simpelste Port um sich einzuarbeiten ;)
Kann mich jetzt nicht genau erinnern, ich glaube so einen Bugreport gibt es schon. Der bisherige Maintainer macht es nicht mehr. Mich selbst würde das jetzt glaub' ich überfordern... ;)

  • Shebangs funktionieren an sich wie erwartet nach der gleichen Logik: die Shell startet den angegebenen Interpreter. Wenn du in einer "Linux shell" bist greift also das /compat/linux overlay, andernfalls nicht.
Sag ich doch, so ungefähr jedenfalls ;)

  • Ich würde dringend empfehlen, in /compat/linux die "linux-c7" ports zu belassen. Grund: Das ist nunmal das "offizielle" Userland zum FreeBSD "Linuxulator". Es gibt einige Ports von Linux-Software (dazu zählt jetzt auch mein MakeMKV port, auch einen für folding@home gibt es inzwischen, usw), die sich genau darauf verlassen und von den entsprechenden linux-c7 ports abhängen. Die funktionieren alle nur richtig, wenn man da nicht herumfummelt. Natürlich kann man andere Linux userlands ausprobieren, da wäre aber die Empfehlung, das in einem jail zu tun. Ein "Devuan jail" hatte ich auch schonmal testweise so weit, dass es per sysv-init "booten" konnte. Was aber speziell MakeMKV angeht, zumindest aktuell wirst du das nie dazu kriegen, dass es mit GUI läuft, egal was du bastelst :)
Ich hatte schon mal so einen Thread mit Linux im Jail gefunden, da ich von Jails aber noch so gar keine Ahnung habe hab ich es erst mal bleiben lassen. Klingt aber interessant, ein Debian 9 mit SysVInit das im systemd-nspawn Container sauber bootet gibt es hier bereits, wär ein guter Ausgangspunkt. Danke für den Hinweis auf der FAHClient Port, den kannte ich noch nicht. Ich bleib' dran!

Grüße,

Robert
 
Das ist lange her und ich hab's wieder aufgegeben, weil ich am Ende keinen Nutzen davon hatte ;) Aber wenn ich es nicht in dem Thread geschrieben hab, dann hab ich mich an das gehalten, was im OP steht :) Ich glaube was du schreibst ergibt auch Sinn, ein "init" sollte es im System ja nur einmal geben.
 
Wer entscheidet/bestimmt eigentlich, auf welcher Linux-Distribution der Linuxulator basiert? Früher basierte er auf Fedora 10(?), dann plötzlich auf CetOS 6. Warum? Und warum nimmt man nicht besser Ubuntu? Das wäre sicher sehr vorteilhaft für das Betreiben des Linux-Steam Clients.
 
Das bestimmt der, der entsprechende Ports baut. Natürlich müssen die auch zu dem nicht mehr ganz frischen Kernel-Interface passen, also ist long-term Support wichtig, das ist bei Centos 7 erfüllt, vor ein paar Tagen kam ein neues Release raus und die linux-c7 Ports wurden aktualisiert. Dazu kommt noch, dass Debian schon öfter mal Pakete "kaputtgespielt" hat, bin zum Beispiel zuletzt hierüber gestolpert: https://rspamd.com/downloads.html#debian-standard-repos-notes
 
dann plötzlich auf CetOS 6. Warum?
Vermutlich, weil CentOS länger supportet wird und damit auch die Pflege einfacher wird.

Natürlich könnte man auch mehrere "Distributionen" via Ports zur Auswahl stellen. Das wird, wie bei vielem, an mangelnder Man-Power liegen. Wenn Du sozusagen ein Port für ein ubuntu-flavorite Linuxulator bereitstellen würdest, hätte sicher niemand was dagegen einzuwenden. :-)
 
Zurück
Oben