Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: dieres on 2010/10/25, 22:45:49
-
moin,
leider kompilieren weder die vmwareplayer module noch die von virtualbox non-ose mit dem neuen kernel out of the box.
fglrx-source hat mit towo|s hinweis geklappt.
gibt es für vmware player und virtualbox non-ose auch schon eine Lösung?
-
Für virtualbox stehts doch hier im Forum, sogar von mir.
Für vmware müßte man schonmal ein log sehen, ob es evtl. sogar das gleiche Problem ist.
-
virtualbox läuft jetzt. Mit vmware gab es schon mit 2.6.35 Probleme, wo ich aber ne Lösung gefunden hatte.
Die letzten zeilen vom log:
Okt 25 22:59:24.326: app-139814470543104| Building module vmmon.
Okt 25 22:59:24.326: app-139814470543104| Extracting the sources of the vmmon module.
Okt 25 22:59:24.348: app-139814470543104| Building module with command: /usr/bin/make -C /tmp/vmware-root/modules/vmmon-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/2.6.36-0.slh.1-aptosid-amd64/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.4.5
Okt 25 22:59:25.389: app-139814470543104| Failed to compile module vmmon!
das letzt mal musste ich die sourcen von vsock und vmmon ändern. Finde die Beschreibung leider nicht mehr wieder :oops:
-
Für mal das händisch als root aus:
/usr/bin/make -C /tmp/vmware-root/modules/vmmon-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/2.6.36-0.slh.1-aptosid-amd64/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.4.5
Dann sollte man sehen, wo das Problem liegt.
Aber mal abgeshen davon, in der Regel hat VMware immer Probleme mit aktuellen Kerneln und erfordert immer einen Patch.
-
root@siduxbox:/home/didi# /usr/bin/make -C /tmp/vmware-root/modules/vmmon-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/2.6.36-0.slh.1-aptosid-amd64/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.4.5
make: *** /tmp/vmware-root/modules/vmmon-only: Datei oder Verzeichnis nicht gefunden. Schluss.
Ich hab dann das Verzeichnis /tmp/vmware-root/modules/vmmon-only
aus /usr/lib/vmware/modules/source/vmmon.tar entpackt und das gleiche noch einmal gemacht, mit folgendem Ergebnis:
root@siduxbox:/home/didi# /usr/bin/make -C /tmp/vmware-root/modules/vmmon-only auto-build SUPPORT_SMP=1 HEADER_DIR=/lib/modules/2.6.36-0.slh.1-aptosid-amd64/build/include CC=/usr/bin/gcc GREP=/usr/bin/make IS_GCC_3=no VMCCVER=4.4.5
Using 2.6.x kernel build system.
make: Entering directory `/tmp/vmware-root/modules/vmmon-only'
make -C /lib/modules/2.6.36-0.slh.1-aptosid-amd64/build/include/.. SUBDIRS=$PWD SRCROOT=$PWD/. \
MODULEBUILDDIR= modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.36-0.slh.1-aptosid-amd64'
CC [M] /tmp/vmware-root/modules/vmmon-only/linux/driver.o
/tmp/vmware-root/modules/vmmon-only/linux/driver.c: In function ‘init_module’:
/tmp/vmware-root/modules/vmmon-only/linux/driver.c:422: error: ‘struct file_operations’ has no member named ‘ioctl’
make[2]: *** [/tmp/vmware-root/modules/vmmon-only/linux/driver.o] Fehler 1
make[1]: *** [_module_/tmp/vmware-root/modules/vmmon-only] Fehler 2
make[1]: Leaving directory `/usr/src/linux-headers-2.6.36-0.slh.1-aptosid-amd64'
make: *** [vmmon.ko] Fehler 2
make: Leaving directory `/tmp/vmware-root/modules/vmmon-only'
-
hab es jetzt mit diesem patch hinbekommen:http://communities.vmware.com/thread/282463?tstart=60
die sourcen aus /usr/lib/vmware/modules/ ausgepackt. den patch angewendet, das Verzeichnis vmmon-only wieder eingepackt und nach /usr/lib/vmware/modules/vmmon.tar kopiert.
beim patchen gab es alledings ein paar rejects ?? Hat aber trotzdem funktioniert. VmWare Player läuft wieder :D
-
Hallo,
da nicht jeder so supergut ist wie Ihr und der Patch auch für vsock gilt habe ich das im folgenden mal etwas ausführlicher für Normalsterbliche beschrieben:
Wie geht der Patch?
Die Patch-Datei vmware-7.1-2.6.36-generic.patch vom obigen Link herunterladen und nach /usr/lib/vmware/modules/source kopieren. Alle folgenden Befehle mit sudo oder als root ausführen:
tar -xvf vmmon.tar (Sourcen in vmmon-only auspacken)
tar -xvf vsock.tar (Sourcen in vsock-only auspacken)
patch -p1 <vmware-7.1-2.6.36-generic.patch (Patch anwenden)
mv vmmon.tar vmmon.bak (Sicherungskopie Originalsource)
mv vsock.tar vmsock.bak (noch eine Sicherungskopie anlegen)
tar -zvf vmmon.tar vmmon-only (Sourcen wieder einpacken)
tar -zvf vsock.tar vsock-only (einpacken)
Dann Vmware normal aus dem Menü starten und
Beten (-:
Gruesse
Jurugu
-
Tja, nur is seit heute (2.6.37) erstmal schluß mit VMWare.
VMWare, bzw, die kernel-module, benötigt BKL, welches seit 2.6.37 nicht mehr im aptosid-kernel drin ist. Da helfen auch die ganzen Patches nyx.
-
Oh, nett zu wissen.
Das klärt dann wohl die Mär von der Stabilität eines rolling sid releases wie aptosid.
Dann ist für mich erstmal Schluss mit upgrades und vielleicht auch bald Schluss mit sid.
Es gibt wichtigeres als ständig den neuesten Kernel anzubeten.
Stabiler Betrieb zum Beispiel...
Gruss
Jurugu
-
was hat das denn wohl mit der stabilität des systems zu tun?
meine aptosid-systeme laufen seit langem ohne probleme...
das BKL nicht mehr erwünscht ist, weiss man auch nicht erst seit gestern...von daher hätte vmware ja nun genügend zeit gehabt...
gruß aus münster
rainer
-
Stabilität ist, wenn eine wichtige Infrastrukturapplikation, die vorher lief,
nach einem regulären Update auch noch läuft. Vmware ist zwar kein OpenSource (also irgendwie böse) aber trotzdem wichtig genug, um in einer IT-Infrastruktur nicht darauf verzichten zu können (es gibt dazu momentan aus 101 Gründen keine Alternative). Die Applikation kann (und muss) für ein Unternehmen wichtiger sein als das Betriebssystem. Eine Update-Politik, die ständig solche Risiken nach sich zieht hat nichts mit Stabil em Betrieb zu tun. Da wackelt hier der Schwanz (Kernel) mit dem Hund (Applikationsstack) und das bedeutet nicht den Tod für die Applikation sondern erstmal das Ende für ein Rolling Release. Aber es gibt ja noch viele andere Distris, die das besser können und man kann ja auch erstmal den alten Kernel noch ein Weilchen behalten. War trotzdem eine nette Zeit mit aptosid...
Gruss, jurugu
-
Für ein Unternehmen würde ich auch nicht auf debian/unstable setzen, sondern auf stable ;)
-
Hallo,
Was ist BKL? Und wer will es warum nicht mehr im Kernel? Zumal Vmware ja nicht die einzige Software ist, die nun nicht mehr läuft.
-
was hat das denn wohl mit der stabilität des systems zu tun?
meine aptosid-systeme laufen seit langem ohne probleme...
das BKL nicht mehr erwünscht ist, weiss man auch nicht erst seit gestern...von daher hätte vmware ja nun genügend zeit gehabt...
gruß aus münster
rainer
Hallo Rainer,
daas hier zeigt doch aber sehr schön, dass Stabilität ein Faktor ist, der sehr umfeldabhängig ist.
Mein aptosid läuft auch ohne Schwierigkeiten, sollte ich allerdings etwas wichtiges nutzen, was BKL noch braucht, und würde ständig ältere Kernel durch aktuelle hier ersetzen und die älteren dann sofort entsorgen, dann hätte ich den Salat :-)
Und ich glaube auch nicht, dass sich die Entwickler von Vmware nach dem aktuellsten Kernel richten, sondern danach, was die großen Distributionen in ihren stabilen Versionen momentan als Kernelversion einsetzen. So werkelt OpenSUSE11.3 zur Zeit mit eimnem 2.6.34er Kernel, das aktuelle Debian stable auch mit einer deutlich älteren Version.
Dass heißt nun nicht, dass ich von Kernelentwicklern erwarte, auf Hersteller proprietärer Lösungen Rücksicht zu nehmen.
Nun haben wir Anwenderinnen und Anwender ja die Wahl, und müssen nicht den aktuellsten Kernel nutzen, übrigens auch nicht in Aptosid :-)
Viele Grüße,
Holger
-
hallo holger,
das ist ja alles richtig...aber wenn ich linux in einer produktivumgebung einsetze, dann mache ich mir doch vorher gedanken darüber, was da auf mich zukommt. eine rolling-release-distribution ist da nach meiner ansicht völlig fehl am platz. dafür gibt es halt kandidaten wie centos, debian stable und co. wenn man eine rolling-release wie sid einsetzt, dann muss man eben damit rechnen, dass es mal größere änderungen/neuerungen gibt. irgendwo müssen die fortschritte in der entwicklung ja schließlich auch mal in die systeme einfließen, und dafür sind die entwicklerzweige und die unstable-versionen doch da.
wenn ich auf unstable setze, darauf software laufen lasse, die ich in meiner firmen-infrastruktur dringend benötige, dann kann ich doch hinterher nicht die distribution dafür verantwortlich machen, wenn etwas nicht mehr funktioniert.
gruß aus münster
rainer
-
Hallo Rainer,
aber wenn ich linux in einer produktivumgebung einsetze, dann mache ich mir doch vorher gedanken darüber, was da auf mich zukommt. eine rolling-release-distribution ist da nach meiner ansicht völlig fehl am platz.
Ja, das sehe ich genau so.
wenn ich auf unstable setze, darauf software laufen lasse, die ich in meiner firmen-infrastruktur dringend benötige, dann kann ich doch hinterher nicht die distribution dafür verantwortlich machen, wenn etwas nicht mehr funktioniert.
Ja, sofern seitens der Distributoren nicht darauf verwiesen wird, dass ihre Distrie auch sehr gut in solchen Firmen-Strukturen eingesetzt werden kann. Das erweckt nämlich bei reinen Anwenderinnen und Anwendern berechtigte Erwartungshaltungen.
Viele Grüße,
Holger
-
Es ist Euch aber bewusst, dass mit BKL hin oder her genau eine Zeile Konfiguration gemeint ist. Und diese Zeile wurde ohne Grund anders gesetzt, als es andere Leute machen. Ich definiere das jetzt mal ganz bewusst als politische Entscheidung. die mit rolling release nichts zu tun hat.
Man klammert sich verbohrt an irgendwelche Ideologien, die mit der Realität nichts zu tun haben. Man kann sehr wohl rolling auch produktiv einsetzen. Es macht allerdings deutlich weniger Spass, wenn man aus solchen nichtigen Gründen Kernel selbst bauen muss oder nicht updaten kann.
-
nun, dass debian sehr ideologisch vorgeht, dürfte auch schon länger bekannt sein.
einige sehen das als vorteil, einige als nachteil. fakt ist aber, dass man vorher weiß, auf was man sich einlässt. und wenn ich weiß, das eine distribution alle paar tage einen neuen kernel erhält, oder wichtige dinge wie x.org, grub, udev und co. sich ändern, dann setze ich diese distribution nicht ein, um dort für eine firma wichtige services laufen zu lassen.
es beim einsatz einer sich stark verändernden rolling-release dann der distri anzulasten, dass programm xyz sich nicht mehr kompilieren läßt, finde ich halt etwas kurzsichtig.
das argument, das etwas ohne grund anders gesetzt wurde, als es andere machen, kann ich nicht gelten lassen. BKL wird schon seit jahren als etwas angesehen, das man gern wieder loswerden möchte. nun wird es halt konsequent umgesetzt. ich persönlich finde das völlig okay. würden alle nur das tun, was andere auch schon machen, hätten wir einen ziemlichen stillstand in der entwicklung...
gruß aus münster
rainer
-
Ich verstehe die Aufregung nicht.
http://pubs.vmware.com/ws7_ace26/wwhelp/wwhimpl/js/html/wwhelp.htm?context=ws_user&file=intro_sysreqs_ws.html
Das ist mehr als eindeutig.
-
@ralv
BKL ist bei slh deaktiviert. Im Debian experimental ist bkl aktiviert.
{{{
linux-headers-2.6.37-trunk-amd64 (2.6.37-1~experimental.1) wird eingerichtet ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 2.6.37-trunk-amd64
dkms: running auto installation service for kernel 2.6.37-trunk-amd64:
fglrx (10-12)...done.
linux-headers-2.6.37-trunk-all-amd64 (2.6.37-1~experimental.1) wird eingerichtet ...
}}}
Ich rede hier also nicht von einem debian-Alleingang, sondern von einem Alleingang von Aptosid in persona slh. Nicht mehr und nicht weniger. Übrigens ist im Sid noch der 32-5, der war hier aber nicht wirklich Thema. Der funktioniert.
Ich laste diesen Zustand, wissentlich Optionen abzuschalten, die einen nicht funktionierenden Zustand hinterlassen, nicht der Distribution an, sondern slh. Der Mann ist lange genug im Geschäft, der sollte wissen, was man macht und was besser nicht. Ich weiss nicht wirklich, wer dieses Entscheidung gefällt hat, ich weiss nur, dass die Entfernung des BKL weit fortgeschritten, aber noch nicht abgeschlossen ist. Und dass ist nicht mehr Sid, das ist allenfalls experimental.
Wenn damit geworben wird, dass aptosid kompatibel zu sid wäre und die Pakete aus Sid auch laufen sollen, dann muss das meiner Meinung auch sichergestellt sein. Genau das zielte auch in die Richtung bleeding edge und cutting edge.
Diese Diskussion habe ich hier auch schon durch und ich wahr sehr froh, dass sich aptosid auf dem Pfad cutting edge bewegt.
Wenn ich bleeding haben möchte, dann fahre ich das auch, ohne Rücksicht auf Verluste. Wenn dann was nicht passt, schraube ich solange, bis es wieder passt, wenn ich kann. Ich habe schon vor Wochen keine Probleme mit .37, qt 4.7, Kde 4.6 und einem X 1.9.X gehabt. Das ist dann wirklich frisch aus der Presse. Mit allem dafür und dagegen. Nur damit muss ich nicht täglich arbeiten, da habe ich noch ein Fallback-System, was nicht ganz so aktuell ist. Insgesamt zwar immer noch frischer als Sid, aber was solls.
Ich habe aptosid als Distri nicht gewählt, um damit bleeding edge zu haben, sondern ein in vernünftigem Maẞe aktuelles debian-System. Und da sah und sieht aptosid wesentlich erotischer als eine reines SID aus, was von debian, nun ja, nicht grade als Produktivsystem gefördert wird. Die großen Klopfer, die in den Paketen auf den User zukommen, habe ich schon Wochen vorher in Arch, da kann ich dann immer schonmal anfangen, mich seelisch und moralisch auf den Einschlag in SID vorbereiten. Und natürlich dann auch Obacht walten lassen.
-
@agaida, slh nimmt für neue Kernel auch ziemlich ungetestete stable-queue patches. Wollen wir (ich will helfen) allgemein ein "easy" aptosid Repo bei dir einrichten mit dem Ziel/Sinn:
Weniger Kernel upgrades, udev sicher, aptosid Anfänger auf der etwas sichereren Seite ?
-
Halte ich nicht so viel von. Nachdem ich den gestrigen Tag eigentlich nur mit Lesen verbracht habe (Komisch, die meisten Dokumentationen endeten in .py, .c und .h) bin ich mir sicher, dass man da nicht so viel besser machen kann.
Man hat eigentlich 3 Chancen. Man fährt Sid, was meine Hardware nicht so toll findet, slh oder experimental. Experimental ist dann ungefähr das selbe, was slh auch nimmt, allerdings mit ein wenig Zeitverzug und sehr viel träger bei wichtigen Änderungen. Liquorix empfinde ich nicht als die große Alternative für mich. Das war jetzt nur mal ein Schnellschuss, weil ich noch nicht vollkommen auf freie Treiber setzen wollte. Ich hab da halt gern eine Alternative und auch die Möglichkeiten mir diese zu schaffen. So lange es unbedingt sein muss, halte ich das am Leben, aber auch keinen Tag länger.
Die Entwicklung kann nur nach vorne gehen und das Bewahren von obsoleten Kerneln ist da eher kontraproduktiv. Das Repo hat eigentlich die entgegengesetzte Ausrichtung. Da sollen bleeding-Sachen frisch und ungeschminkt direkt aus git oder svn rein ;) Deswegen auch der Hinweis mit dur als Analogie zum aur. Halt alles, was ich brauche, aber nicht bei debian erhalten kann.
-
Hallo,
besteht denn Aussicht, dass Vmware in aptosid irgendwann mal wieder nutzbar wird, oder sollte man doch lieber auf eine andere Distribution ausweichen?
-
Hallo,
besteht denn Aussicht, dass Vmware in aptosid irgendwann mal wieder nutzbar wird, oder sollte man doch lieber auf eine andere Distribution ausweichen?
Das wirst Du schon vmware fragen müssen.
Spätestens in 2.6.39 ist BKL auch upstream Geschichte.
Und nochmal zu mitmeißeln, VMWare hat schon immer Probleme mit aktuellen Kerneln. Das liegt daran, daß VMware eben nur bestimmte Distros, respektive Kernel-Versionen supportet.
-
besteht denn Aussicht, dass Vmware in aptosid irgendwann mal wieder nutzbar wird, oder sollte man doch lieber auf eine andere Distribution ausweichen?
Guckst Du hier http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=474
Wobei ich die folgende Variante aus dem Debiananwenderhandbuch:
#Vorher installieren:
apt-get install fakeroot kernel-package make libncurses5-dev
____________________________________________ ________________________
#Aktuelle Kernel-Sourcen laden und entpacken
apt-get source linux-image-2.6-aptosid-amd64 (bzw. i.386)
#Aktuelles Kernel-Image laden
wget http://debian.tu-bs.de/project/aptosid/debian/pool/main/l/linux-aptosid-2.6/linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
#und config-Datei daraus extrahieren
ar -x linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
tar xvf data.tar.bz2 ./boot/config-2.6.37-0.slh.14-aptosid-amd64
#extrahierte config-Datei in das Source-Verzeichnis unter .config kopieren
cp ./boot/config-2.6.37-0.slh.14-aptosid-amd64 ./linux-aptosid-2.6-2.6.37/.config
#in das Source-Verzeichnis wechseln und make menuconfig ausführen
cd linux-aptosid-2.6-2.6.37
make menuconfig
#hier: Kernel hacking --> * Big Kernel Lock
#exit mit speichern
#Kernel-image bauen mit:
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 --initrd kernel-image
#Kernel-headers bauen mit
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 kernel-headers
Das sollte so auch noch für Kernel 2.6.39.. umsetzbar sein.
Und dann läuft Vmware auch wieder fein :-)
Gruß
AnJo
-
Das sollte so auch noch für Kernel 2.6.39.. umsetzbar sein.
Nein, wird es nicht, weil BKL in diesem Kernel nicht mehr verfügbar sein wird.
-
Handaufleg. Ich persönlich glaube nicht, dass der BKL in der .39 aus dem Kernel verschwunden ist. Macht aber nichts. Langsam verstehe ich aber die Aufregung wirklich nicht mehr. Bei mir kommt langsam so eine WZT-Frage auf: WzT ist so schwer daran, so lange die Füsse still zu halten, bis sich das Thema geklärt hat?
Die möglichen Lösungswege sind lang und schmutzig geklärt. Wer unbedingt BKL haben muss, der soll sich einen Kernel mit BKL halten, der gegen das Produkt, was laufen soll, funktioniert. Alternativen zum offiziellen .slh-Kernel sind da. Ich sehe auch keinen Grund, dafür warum das nicht so bleiben sollte.
Auch wenn ich zum Thema Kernel nicht ganz Towos Meinung bin: Aptosid hängt doch nicht nur an diesem Kernel. Der ist zwar ein Hauptbestandteil von aptosid, aber in meinen Augen auch ein wenig überbewertet. Und wenn man einen Kernelstand mal für einige Zeit einfrieren muss oder eine Alternative benutzt, ist das doch auch kein Problem. Schließlich ist das Linux, da geht so was. Irgendwann werden auch die Hersteller reagieren.
Deswegen aber eine tolle Distribution in die Tonne zu treten, halte ich für ein wenig übertrieben. Vor allem, weil gewisse Hakeleien bei jeder Distri auftreten werden, mal mehr, mal weniger.
-
Deswegen aber eine tolle Distribution in die Tonne zu treten, halte ich für ein wenig übertrieben. Vor allem, weil gewisse Hakeleien bei jeder Distri auftreten werden, mal mehr, mal weniger.
Da schließ ich mich mal ganz kräftig an :!:
Gruß
AnJo
-
Guckst Du hier http://www.aptosid.de/index.php?name=PNphpBB2&file=viewtopic&t=474
Wobei ich die folgende Variante aus dem Debiananwenderhandbuch:
#Vorher installieren:
apt-get install fakeroot kernel-package make libncurses5-dev
____________________________________________ ________________________
#Aktuelle Kernel-Sourcen laden und entpacken
apt-get source linux-image-2.6-aptosid-amd64 (bzw. i.386)
#Aktuelles Kernel-Image laden
wget http://debian.tu-bs.de/project/aptosid/debian/pool/main/l/linux-aptosid-2.6/linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
#und config-Datei daraus extrahieren
ar -x linux-image-2.6.37-0.slh.14-aptosid-amd64_2.6.37-14_amd64.deb
tar xvf data.tar.bz2 ./boot/config-2.6.37-0.slh.14-aptosid-amd64
#extrahierte config-Datei in das Source-Verzeichnis unter .config kopieren
cp ./boot/config-2.6.37-0.slh.14-aptosid-amd64 ./linux-aptosid-2.6-2.6.37/.config
#in das Source-Verzeichnis wechseln und make menuconfig ausführen
cd linux-aptosid-2.6-2.6.37
make menuconfig
#hier: Kernel hacking --> * Big Kernel Lock
#exit mit speichern
#Kernel-image bauen mit:
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 --initrd kernel-image
#Kernel-headers bauen mit
fakeroot make-kpkg --append-to-version -0.aj.14-aptosid-amd64 --revision 2.6.37-14 kernel-headers
Das sollte so auch noch für Kernel 2.6.39.. umsetzbar sein.
Und dann läuft Vmware auch wieder fein :-)
Gruß
AnJo
Danke, nett gemeint, aber ein- oder zweimal die Woche neue Kernel bauen, dafür muss man erstmal Zeit und Lust haben. Ich halte erstmal meinen letzten 2.6.36er.
Das wirst Du schon vmware fragen müssen.
Spätestens in 2.6.39 ist BKL auch upstream Geschichte.
Und nochmal zu mitmeißeln, VMWare hat schon immer Probleme mit aktuellen Kerneln. Das liegt daran, daß VMware eben nur bestimmte Distros, respektive Kernel-Versionen supportet.
Ganz so ist das ja nun auch nicht. Bis jetzt ließ sich das immer per Patch regeln. Wenn ich die Diskusionen hier richtig interpretiere, funktioniert Vmware ja nur mit dem 2.6.37er aptosid-Kernel nicht mehr.
-
Da hilft auch kein Patch, weil durch den BKL-Schalter einiges an Code schon vor dem Bauen einfach mal nicht mehr mitgebaut wird. Auch wenn es nicht schön ist, es sind ja Alternativen da. Also, was solls. Warum denken alle Leute immer, dass man Kernel so oft wechseln muss, wenn man keine Probleme hat?
-
Was ist BKL?
Das fragte ich mich auch:
http://books.google.de/books?id=PAOvoVr-l74C&pg=PA206&lpg=PA206&dq=BKL+linux&source=bl&ots=cKucqEDqY0&sig=hgWb6VNz6M03q_NDg8A3XKpZ3YQ&hl=de&ei=1QlOTZHSFdO94gaj2LioCQ&sa=X&oi=book_result&ct=result&resnum=2&ved=0CC0Q6AEwAQ#v=onepage&q=BKL%20linux&f=false
Big Kernel Lock (BKL)
http://www.heise.de/open/artikel/Die-Neuerungen-von-Linux-2-6-37-1162390.html
"Die Kernbereiche des Linux-Kernels sind nun nicht mehr auf das Big Kernel Lock (BKL) angewiesen. Dabei handelt es sich um eine Locking-Technik aus den Anfangszeiten der Multiprozessor-Unterstützung von Linux, die Konflikte beim gleichzeitigen Zugriff auf zentrale Datenstrukturen im Kernel vermeidet.
Diese Locking-Technik war damals vergleichsweise einfach umsetzbar, sperrt aber subsystemübergreifend. Das hat sich bei Systemen mit vielen Prozessorkernen negativ auf die Performance ausgewirkt und kann zu langen Latenzen bei Systemaufrufen führen, die nicht nur im Echtzeit-Umfeld unerwünscht sind.
In vielen Bereichen des Kernels hatten die Entwickler das Locking bereits in den letzten Jahren verfeinert."
http://www.freiesmagazin.de/ unter "Der Januar im Kernelrückblick":
Kurz erläutert: „Locking“
Als Locking bezeichnet man eine Methode, die zeitgleiche Zugriffe auf ein Gerät oder einen Speicherplatz verhindert.
Dabei errichtet der erste Prozess, der die Ressource nutzt, eine Sperre (englisch: Lock); alle anderen Prozes- se müssen warten, bis sie wieder freigegeben wurde.
Ältere Locking-Mechanismen zeigen sich häufig sehr gierig und sperren größere Adressräume als notwendig, wodurch andere Prozesse beim Zugriff gegebenenfalls warten müssen und damit ausgebremst werden.
Die Bestrebungen laufen derzeit dahin, dass Prozesse nur den wirklich benötigten Teil einer Ressource sperren, zum Beispiel nur einen kleinen Zweig einer Struktur anstelle des ganzen Baumes.
Dabei verhindert ein Read-Lock das Bearbeiten der Ressource, erlaubt jedoch anderen Prozessen ebenfalls das Lesen und wehrt nur Versuche zum Bearbeiten ab.
Ein Write-Lock dagegen unterbindet auch Lesezugriffe, bis dass die Änderungen vollständig sind und der Lock entfernt wurde.
-
...Warum denken alle Leute immer, dass man Kernel so oft wechseln muss, wenn man keine Probleme hat?
"Rolling Release", der Sinn von aptosid.
-
sorry, falscher Thread
-
...Warum denken alle Leute immer, dass man Kernel so oft wechseln muss, wenn man keine Probleme hat?
"Rolling Release", der Sinn von aptosid.
Da hab ich dann wohl was falsch begriffen und schäme mich ganz doll. Ich wechsele Kernkomponenten eigentlich erst, wenn ich relativ sicher bin, keine Probleme zu bekommen. Ausnahmen bestätigen die Regel.
Rolling Release bedeutet auch nicht, auf Teufel komm raus Pakete nur deshalb zu installieren und uptodate zu halten, weil es sie gibt. Deshalb auch die in den kommenden Wochen wieder an Wichtigkeit gewinnenden Update-Warnungen.
-
Da hab ich dann wohl was falsch begriffen und schäme mich ganz doll. Ich wechsele Kernkomponenten eigentlich erst, wenn ich relativ sicher bin, keine Probleme zu bekommen. Ausnahmen bestätigen die Regel.
Rolling Release bedeutet auch nicht, auf Teufel komm raus Pakete nur deshalb zu installieren und uptodate zu halten, weil es sie gibt. Deshalb auch die in den kommenden Wochen wieder an Wichtigkeit gewinnenden Update-Warnungen.
Du brauchst dich nicht gleich schämen. Du kannst aber auch in deiner "Ecke" stehenbleiben, wenn du magst. Das bringt mich beim aktuellen Problem zwar keinen Schritt weiter, stört mich aber auch nicht sonderlich.
Um Kernel-Updates zu verhindern, muss ich (auch nach einer frischen Installation) ins System eingreifen. Also ist es doch der aptosid-Philosophie entsprechend so gewollt, dass ich den Kernel aktuell halte.
-
Das erste, was ich bei Arch gelernt habe, waren 2 Sachen:
* Mach nie ein Update ohne vorherige Sicherung, wenn Du Dir nicht sicher bist, dass Du die Auswirkungen ohne Neuinstallation beheben kannst.
* Auch wenn alle Leute jubeln, dass bestimmte Pakete endlich verfügbar sind - glaube nicht, dass sie deshalb funktionieren. Im Zweifel mache sie fest und verweigere Dich allen Aktualisierungen, die darauf aufbauen. Lass einfach mal andere in die braune Masse greifen ;)
Ich gebe auch zu, dass Pakete pinnen bei Arch einfacher ist, als bei debian, das ist (wie eigentlich fast alles im Paketmanagement) eine Wissenschaft für sich, die erst mal begriffen werden muss. Hilft aber ungeheuer weiter und belohnt einen mit einem stressfreien Leben. Wenn mir das zu blöd wird, bekommt das betreffende Paket halt eine eigene Revision von mir, dann hat sichs mit dem Pinnen.
Klar soll alles so aktuell sein, wie sinnvoll machbar ist. Das darf aber auf keinen Fall auf Kosten der Benutzbarkeit und Stabilität des Systems gehen (ausser, es ist einem egal oder bei Entwicklern auch gewollt - dann gelten andere Regeln)
Letztes aktuelles Beispiel ist nach dem X-Server der für die meisten hier unwichtige, weil unbenutzbare fglrx. Gestern von mir gefixt und gebaut kommt das Ding ohne funktionale Änderung, dafür aber mit höherer Revision in Sid an. Bei der geringen Bedeutung von proprietären Treibern für debian ein an ein Wunder grenzender Vorgang. Leider mit den selben falschen Abhängigkeiten wie in experimental. 2 Möglichkeiten - pinnen oder ein non-Maintainer update. Ich habe in diesem Fall Variante 2 bevorzugt und meinem Build .1 angefügt. Fall gegessen. Aktuell, so es sich nur in einer Nummer ausdrückt, muss nicht immer gut sein.
Auf jeden Fall ist in den kommenden Tagen und Wochen für Spass, Abwechslung und Frohsinn gesorgt. Langweilig wird es auch nicht, es gibt genug, was zerstört werden kann. Da braucht sich eigentlich keiner besonders anstrengen :lol: