Archiv verlassen und diese Seite im Standarddesign anzeigen : openSUSE 13.1
Ankündigung: http://news.opensuse.org/2013/11/19/opensuse-13-1-ready-for-action/
Download: http://software.opensuse.org/131/de
Macht bisher auf meinem Thinkpad, abgesehen von den üblichen Kleinigkeiten, einen ganz guten Eindruck.
ThorstenHirsch
19.11.13, 19:48
Da ich in ein paar Kommentaren gelesen habe, dass Yast (nun in Ruby implementiert) langsam sein soll bzw. eine längere Startzeit hat, wollte ich mal fragen: ist's Ruby 1.9 oder Ruby 2.0? Wäre enttäuschend, wenn's mit Ruby 2.0 lange braucht.
Die neue Version verrichtet hier ihren Dienst. Macht bisher einen guten Eindruck.
Ich habe ein Upgrade von Version 12.3 durchgeführt. Lediglich ein Konflikt zwischen ibus und libreoffice-kde4-extensions lag vor. Offenbar gab/gibt es da Probleme das ibus wohl zu Gnome-nah geworden ist.
Empfohlen wird die Nutzung von fcitx, was problemlos läuft. :)
Alle, die auf 13.1 upgraden wollen sie allerdings angemerkt, dass von Nvidia zur Zeit KEINE Treiber Pakete angeboten werden. Diese werden wohl erst in Kürze folgen. So lange bleibt entweder nouveau (was bei mir aber im Dual-Screen Modus Probleme bereit) oder man muss sich die Kernelmodule selbst kompilieren.
Da ich in ein paar Kommentaren gelesen habe, dass Yast (nun in Ruby implementiert) langsam sein soll bzw. eine längere Startzeit hat, wollte ich mal fragen: ist's Ruby 1.9 oder Ruby 2.0? Wäre enttäuschend, wenn's mit Ruby 2.0 lange braucht.
Den installierten Paketen nach ist es Ruby2. So richtig aufgefallen ist mir bei YaST jetzt nichts in Sachen Geschwindigkeit, weder positiv noch negativ; wobei ich zugeben muss, dass ich YaST so gut wie gar nicht nutze. Da wäre halt einerseits die Frage, wo es langsam sein soll und zum anderen, ob YaST wirklich die Ursache ist oder ob die Ursache an einem anderen Ort liegt.
stefan.becker
20.11.13, 20:46
Der neueste Nvidia Treiber geht problemlos als DoItYourself-Lösung. Aufruf des Installers reicht aus. Standard Konsole (init 3, su, sh ./N*n).
VBOX geht nach Neuübersetzen der Kernelmodule, VMPlayer ist kompatibel zu jedem Update (sprich geht nicht).
Im Firefox gehen auch Flash 11.9 und Silverlight 5.1 problemlos.
Insgesamt ein rundes Update. Die Probleme sind bei VMWARE normal und nicht dem Suse Team anzulasten.
Fazit: Sehr gute Arbeit. Werde mal nach einer VMWARE Lösung suchen, dann wird auch die 2. Maschine aktualisiert.
dass von Nvidia zur Zeit KEINE Treiber Pakete angeboten werden.
Leider! :mad:
Und der nuveau macht hier nur Probleme. Nach einer gewissen Zeit bekomme ich nur noch Konfetti auf dem Bildschirm und das ganze System hängt.
Aber sonst läuft die Suse rund :)
Gruss
Michael
@Stefan: Virtualbox geht erst nach Selbstkompilierung von Kernelmodulen ?
In dem Falle werde ich mit dem Update noch warten und hoffen dass das bald wieder "aus dem Repo" läuft... (Zuerst kommt eh erst mal der Laptop dran..)
Rain_maker
20.11.13, 22:59
@Stefan: Virtualbox geht erst nach Selbstkompilierung von Kernelmodulen ?
Huh?
Sofern man die Version von der VB-Homepage bzw. aus deren Repo nimmt, war das noch nie anders.
In 13.1 ist allerdings auch Version 4.2.18 mit entsprechenden KMP-Paketen mit enthalten, sofern Dir die neu genug ist.
Greetz,
RM
P.S. Wer ein wenig auf software.opensuse.org/search sucht, findet übrigens auch jetzt schon fertige Pakete für nvidia-gfx$IRGENDWAS, die meisten linken via OBS auf die Dateien im OBS-Repo, welches die Bauvorschriften für "offiziellen" Pakete bereit stellt, sieht für mich eher so aus, als würde da NVIDIA mit der Veröffentlichung der Pakete pennen.
OK.. daher.. hatte ich nicht mitbekommen da ich bisher immer die aus dem Repo verwendet habe... ich brauche nicht unbedingt "Multitouch" auf meinem Uralt Bildschirm...
Hier ist noch ne Anleitung, scheint also nicht sooo kompliziert zu sein:
http://www.unixmen.com/install-virtualbox-4-3-opensuse-13-1/
Rain_maker
20.11.13, 23:09
Ich hätte da noch eine Kurzanleitung, aber die gilt nur für Nutzer, die auch einen OBS-Account haben.
1) Paket nvidia-gfxG03 (nvidia-gfxG02) vom Projekt X11:Drivers:Video mit osc co auschekcen.
2) Script fetch.sh ausführen oder entsprechende Installer (siehe SPEC file) direkt bei NVIDIA herunterladen und ins ausgecheckte Paketverzeichnis packen
3) osc build (--local-package) passend zur Distroversion und Architektur ausführen
//Edit (Ausführen gilt für beide Specfiles, sowohl x11-video-nvidiaG0X.spec als auch nvidia-gfxG0X.spec, das eine liefert den Binärblob mit allen libs bzw. binaries, das andere das Kernelmodul)
4) Lokal gebaute Pakete installieren freuen
Greetz,
RM
stefan.becker
21.11.13, 19:52
@Stefan: Virtualbox geht erst nach Selbstkompilierung von Kernelmodulen ?
In dem Falle werde ich mit dem Update noch warten und hoffen dass das bald wieder "aus dem Repo" läuft... (Zuerst kommt eh erst mal der Laptop dran..)
Ist aber nur ein Aufruf: "sudo /etc/rc.d/vboxdrv setup". 1 Minute und gut ist.
VMPlayer 6.01 geht noch nicht. Gast startet kurz an, danach Crash ohne Meldung in der Konsole. Problem ist wohl noch zu neu, Tante G. findet was, aber alles bisher ohne Lösung. Mal abwarten, ist ja nur die 2. Maschine.
Habe mit zypper Update von 12.3 auf 13.1 gemacht.
Lief einwandrei, Dauer ca. 1 h.
musste nur NVIDIA-Treiber neu installieren.(NVIDIA-Linux-x86_64-331.20.run)
Noch die Internet-Zugangsdaten wieder eingeben und fertig.
System läuft wunderbar.
Ginsengelf
23.11.13, 16:11
Moin, Update hat recht problemlos geklappt, beim ersten Neustart danach gab's kein Bild (warum auch immer), und rubyripper stürzt beim Start des Rippens ab, aber sonst läuft alles rund.
Ginsengelf
Hallo,
Update ist zwar glatt durchgelaufen, dafür sind einige Probleme, die ich unter 12.3 nicht mehr hatte wieder da.
1. die Soundkarte knackt regelmäßig
Notebook Amilo PI 1536 Soundkarte 82801G (ICH7 Family) Treiber snd-hda-intel.
Ändere ich in Yast power-saving timout auf 0 dann ist das regelmäßige Knacken weg, kommt aber wieder beim nächsten Start. Verlängere ich die Zeit auf 1000000, was bei 12.3 der Workaround war, klappt bei 13.1 nicht.
2. Bluedevil schmiert ab, bei der Verbindung zu meinem AV Receiver.
Es geht um eine Verbindung für Soundübertragung A2DP
Ich kann den Receiver bluetooth-mäßig verknüpfen, wenn ich aber die Audioverbindung erstellen will stürzt Bluedevil ab und spuckt folgenden Fehlerbericht aus
Application: Bluetooth Audio Helper (bluedevil-audio), signal: Segmentation fault
Using host libthread_db library "/lib/libthread_db.so.1".
[KCrash Handler]
#6 0xb7359a24 in BlueDevil::Device::isPaired() const () from /usr/lib/libbluedevil.so.2
#7 0x0804a640 in _start ()
Ich kann nicht verstehen, wie ein (1) bestehender Fehler sogar noch schlimmer werden kann oder ein funktionierendes Programm (2) in der nächsten Version schlechter werden kann.
So langsam frustriert mich Opensuse, welches ich seit Version 6.? verwende.
Gruß Dirk
[...]
2. Bluedevil schmiert ab, bei der Verbindung zu meinem AV Receiver.
Es geht um eine Verbindung für Soundübertragung A2DP
Ich kann den Receiver bluetooth-mäßig verknüpfen, wenn ich aber die Audioverbindung erstellen will stürzt Bluedevil ab und spuckt folgenden Fehlerbericht aus
[...]
Zu KDE und Bluetooth steht was in den Releasenotes:
5.10. KDE und Bluetooth
Die Bluetooth-Unterstützung wird von Bluez 5 bereitgestellt (eine nicht abwärtskompatible Hauptversionsänderung), die nötig ist für den Gnome-Desktop und einige andere Basissystemkomponenten. Leider unterstützt KDE in den derzeit veröffentlichten Versionen nur die Bluez-Version 4.
Deshalb bietet das openSUSE-KDE-Community-Team ein inoffizielles Bluedevil-Paket an, das wenigstens Basisfunktionen wie die Geräte-Kopplung oder Unterstützung für Bluetooth-Mäuse bietet. Einige andere Funktionen, wie die Dateiübertragung, funktionieren bekanntermaßen noch nicht.
Derzeit sollten keine Fehler in der Bluetooth-Unterstützung in KDE gemeldet werden, da die Umstellung von Bluedevil auf Bluez 5 noch in Arbeit ist.
Mal was anderes: Gibt es noch andere, die Gnome 3.10.1 in openSUSE 13.1 nutzen und bei denen der Speicherverbrauch der Gnome-Shell jenseits von Gut und Böse ist (bei mir ohne Extensions 17% ~ >600MB)?
Da das mein erstes Update von OpenSuse sein wird, drei kurze Fragen in die Runde:
1.) Wenn ich das richtig sehe, macht man das Update wohl am Besten indem man sich 13.1 herunterlädt, dann vom Installationsmedium bootet und dann Upgrade wählt? Oder kann man problemlos aus dem laufenden System updaten?
2.) Repositories: Ich habe zusätzlich das Repository von Overman79 (Bumblebee) sowie das Kernel:Stable-Repository eingebunden, beide werden auch genutzt. Muss/sollte ich vor dem Upgrade die Pakete der Repositories deinstallieren?
3.) Ich habe mein System komplett verschlüsselt, das war ein ziemlicher Aufwand mit einigem an Handarbeit weil der Installer von 12.3 damals Mucken gemacht hat. Kann ich mir die berechtigte Hoffnung machen dass meine Konfiguration übernommen wird oder sind da Probleme zu erwarten? Ein Backup meiner Daten werde ich so oder so machen, das steht außer Frage, aber verständlicherweise habe ich wenig Lust auf Ärger.
Danke schonmal!
-hanky-
Rain_maker
24.11.13, 10:55
1.) Wenn ich das richtig sehe, macht man das Update wohl am Besten indem man sich 13.1 herunterlädt, dann vom Installationsmedium bootet und dann Upgrade wählt? Oder kann man problemlos aus dem laufenden System updaten?
Das "Hot-Upgrade" aus dem laufenden System ist für mich seit langem der Standardweg und vor allem in Anbetracht des vollverschlüsselten Systems sehr wahrscheinlich sogar die einfachere Alternative.
Bei meinem Setup (LUKS aber ohne die Nutzung von LVM), welches von der Standardmethode LUKS mit LVM (ist das noch so?) abweicht, würde ein Upgrade mit der Installer-DVD wahrscheinlich deutlich mehr Handarbeit bedeuten, da man dem Installer erst mal beibringen müsste, wo er was zu suchen hat.
Garantien gibt es natürlich keine, aber da Du nur auf die nächste Version gehst, stehen die Chancen gut, ich bin in letzter Zeit sogar öfters über eine Version gesprungen und es hat immer funktioniert, allerdings auch meist mit ein wenig Handarbeit danach, weil bestimmte Scripte zur Migration diesen Weg nicht offiziell unterstützen.
2.) Repositories: Ich habe zusätzlich das Repository von Overman79 (Bumblebee) sowie das Kernel:Stable-Repository eingebunden, beide werden auch genutzt. Muss/sollte ich vor dem Upgrade die Pakete der Repositories deinstallieren?
Hier muss man differenzieren.
Das Deaktivieren eines Fremdanbieterrepos reicht in der Regel, denn dann erkennt zypper, daß die Pakete aus jenem Repo nicht mehr aus den noch aktiven Quellen verfügbar ist (Anzeige von zypper se -s $PAKETNAME sagt einem dann "Systempakete") und dann ein zypper dist-upgrade solche Pakete auch mit älteren Versionen überschreiben würde, sofern es diese gibt. Sollte es keine kompatiblen Pakete für die neue Version geben, dann würde ich auf jeden Fall diese Pakete aus Drittanbieterrepos deinstallieren, bzw. erst dann upgraden, wenn dieses Drittanbieterrepo auch für die neue openSUSE-Version verfügbar ist, sofern mir die dortige Software sehr wichtig ist.
Aber es gibt auch Ausnahmen, die die Regel bestätigen und manchmal hilft es einem sogar ein Fremdrepo aktiviert zu lassen oder zumindest dessen Pakete nicht zu deinstallieren.
Das gilt hier für Kernel:Stable, das würde ich sogar auf jeden Fall drin lassen und mir ein klein wenig Handarbeit vorher machen.
Begründung kommt gleich, denn
3.) Ich habe mein System komplett verschlüsselt, das war ein ziemlicher Aufwand mit einigem an Handarbeit weil der Installer von 12.3 damals Mucken gemacht hat. Kann ich mir die berechtigte Hoffnung machen dass meine Konfiguration übernommen wird oder sind da Probleme zu erwarten? Ein Backup meiner Daten werde ich so oder so machen, das steht außer Frage, aber verständlicherweise habe ich wenig Lust auf Ärger.
gerade weil es sich um ein vollverschlüsseltes System handelt, würde ich mir zumindest einen Kernel zurück behalten, von welchem ich annehmen kann, daß er auch auf der neuen Version sehr wahrschenlich funktionieren wird.
Eigentlich geht es weniger um den Kernel sondern eher um die initrd, denn der Kernel hängt ja nicht von der neuen glibc ab und seine initrd hat mit dem Setup aus 12.3 das getan, was sie tun musste um im frühen Bootvorgang die Passwortabfrage/Entschlüsselung hinzubekommen.
Nun wird es aber beim Upgrade auch neue Pakete von mkinitrd&co. geben und mir ist es einmal passiert, daß dort nicht automatisch eines der Module für die Verschlüsselung übernommen wurde und so aus der initrd flog, bzw. hatten sich glaube ich Namen geändert und das Kernelmodul war nicht mehr im neuen Kernel unter diesem Namen verfügbar und im alten Kernel, den ich behalten wollte flog es während des Upgrades aus der neu gebauten initrd heraus.
Genau das kann man verhindern, wenn man sich _vor_ dem Upgrade eine Sicherungskopie der zum Kernel passenden initrd anlegt, z.B. so:
# cp /boot/initrd-3.12.0-1.ge8fa6b4-desktop /boot/initrd-3.12.0-1.ge8fa6b4-desktop.bak
Während des Upgrades wird diese initrd sich mehrfach ändern, weil bestimmte Pakete bei der Installation automagisch einen Neubau triggern (udev wäre so ein Kandidat). Sollte dann das passieren, was ich oben beschrieben habe, dann fehlen die Module zwar in der neu gebauten initrd, in der Kopie sind sie aber noch da und mit dieser initrd kann man im Notfall wahrscheinlich noch booten.
Es kann auch gerade so sein, daß die Kopie nicht mehr bootet, wenn sich bei udev&co sehr viel geändert hat, aber die Chancen stehen ganz gut, vor allem, weil man aus dem Kernel:Stable-Repo nicht nur den aktuellsten "stable" Kernel sondern auch eine aktuelle Version von "mkinitrd" bekommen haben dürfte, und mit der ging es ja vor dem Upgrade auch.
Das Kernel:Stable-Repo würde ich also aktiviert lassen, es ist übrigens auch nicht an eine Distroversion gebunden
zypper lr -d|grep Kernel_stable
2 | Kernel_stable | Kernel_Builds_latest_stable | Ja | Ja | 99 | rpm-md | http://download.opensuse.org/repositories/Kernel:/stable/standard/
weil eben nicht von der jeweiligen glibc abhängig.
Ich würde Folgendermassen vorgehen.
1) Sich für das Bumblebee-Repo überlegen nachsehen, ob es für 13.1 verfügbar ist oder nicht, danach sich entscheiden, welchen Weg man dort geht.
2) Repos in /etc/zypp/repos.d/$FOO.repo auf 13.1 bringen, Kernel:Stable auf jeden Fall behalten und nichts deinstallieren o.ä.
3) Sicherungskopie der funktionierenden initrd für den Kernel aus Kernel:Stable (aktuell ein 3.12.1-irgendwas) anlegen
4) zypper ref ausführen
5) Den Kernel der 13.1 (3.11.6-irgendwas) parallel installieren und ggf. initrd auf die Version der 13.1 bringen, sofern letzteres viele weitere Upgrades nach sich zieht (udev/systemd etc.) vielleicht lieber mkinitrd erst nal weglassen, Kernel _muss_ gehen, da nicht von den Paketen nur aus 12.3 oder nur aus 13.1 direkt abhängig. sehr wahrscheinlich ist das schon installiert Paket "mkinitrd" aus Kernel:Stable eh aktueller und bleibt dann auf dem System.
6) Zumindest temporär verhindern, daß Kernelpakete automatisch gelöscht werden, dazu sollte man die Datei "/boot/do_purge_kernels" löschen und den systemd-service "purge-kernels.service" deaktivieren/maskieren.
7) Reboot in den Kernel der 13.1 (3.11.6-irgendwas) und im Erfolgsfall sich vielleicht auch von dessen initrd eine Kopie anlegen.
8) Sicherungskopien der Konfigurationsdateien des Bootloaders, damit man nach dem Upgrade einen Vergleich hat.
9) Upgrade mit zypper dup
Irgendwo zwischen 5) und 9) kann man dann noch den 3.7.10-irgendwas der 12.3 runterwerfen, hängt natürlich auch von der Größe der /boot-Partition ab, wer ganz vorsichtig ist, arbeiete für die (De-)Installationsscritte bei Kernelpaketen nicht mit zypper sondern auf der Kommandozeile mit "rpm -i" (ggf. braucht man "--oldpackage") und "rpm -e kernel-$flavor-$version" um auch wirklich keine Pakete zu überschreiben bzw. keine Kernel zu entfernen, die man noch behalten wollte.
Greetz,
RM
Hallo,
ich habe die 13.1 über die 12.3 per DVD Neuinstallation drüber gebügelt.
das hat ohne Probleme Funktioniert. Home partition ist separat wodurch ich alle user weiterverwenden konnte, auch hier keine Probleme.
Dauer der Installation ca. 40 min., Händische nacharbeiten wie bei den letzen opensuse Versionen auch der Treiber für meine Broadcom wlan karte (Packman Repo einbinden).
Hibernate usw. funtioniert., Start subjektiv sehr schnell. Keine Probleme bisher.
Hardaware:
ACER Aspire 5750G
gruß boeser
Hi,
vielen Dank für die ausführliche Antwort!
Dann werde ich mich wohl für die Variante des Upgrades aus dem laufenden System entscheiden. Das Overman79-Repository gibt es bereits für OpenSuse 13.1, das sollte also keine Probleme machen. Und wie ich eben gesehen habe nutzt OpenSuse 13.1 nur Kernel 3.11, insofern werde ich das Stable-Repository auf jeden Fall weiter nutzen.
Ich werde wohl erst nächstes Wochenende dazu kommen das Upgrade durchzuführen, ich gebe dann aber auf jeden Fall nochmal Rückmeldung ob alles soweit geklappt hat!
-hanky-
P.S.: Ich nutze LUKS mit LVM, also die Standardmethode. Aber beim Installer von 12.3 gab es da wenn ich mich richtig erinnere das Problem, dass er /boot auch in das LVM gepackt hat und das System dann, Überraschung (:ugly:), nicht gebootet hat. Daher die notwendige Handarbeit.
Rain_maker
24.11.13, 12:37
Und wie ich eben gesehen habe nutzt OpenSuse 13.1 nur Kernel 3.11, insofern werde ich das Stable-Repository auf jeden Fall weiter nutzen.
Allgemeiner Tipp für Nutzer dieses Repos.
Auch wenn es mittlerweile default für zypper sein sollte, daß Kernel nicht automatisch beim Update überschrieben werden, so würde ich auf jeden Fall gut aufpassen, daß ein "bekanntermassen gut funktionierender Kernel" verfügbar ist.
Das kann auch gerne der Distrokernel (bei 13.1 eben "nur ein 3.11er") sein, der einem im Notfall den Hintern retten kann, wenn bei einem Update aus Kernel:Stable das System nicht mehr booten will.
Ich habe immer einen weiteren Kernel als Fallback, der muss nicht einmal in der RPM-Datenbank stehen.
Das kann man z.B. so machen:
rpm -q kernel-desktop
kernel-desktop-3.12.0-1.1.ge8fa6b4.i686
kernel-desktop-3.11.6-4.1.i686
# rpm -e --justdb kernel-desktop-3.11.6-4.1.i686 --testsollten hier irgendwelche KMP-Pakete auftauchen, dann müssen diese vorher ebenfalls "deinstalliert" werden, die Anführungszeichen, weil man mit dem Parameter "--justdb" das tut, was er sagt.
Man deinstalliert _nur_ den Eintrag in der RPM-Datenbank, _nicht_ die Dateien!
Wenn es keine Abhängigkeitsprobleme mehr gibt, dann lässt man oben einfach das "--test" weg und ein "rpm -q kernel-desktop" zeigt den Kernel in Version 3.6.11-4-desktop nicht mehr an (er ist aber noch immer da).
Damit kann aber auch nichts bei einem Update von RPM selbst überschrieben werden, denn das Paket existiert ja für RPM gar nicht mehr.
Was aber passieren kann, ein Paket triggert "mkinitrd" für alle installierten Kernel und dann bootet die neu gebaute initrd für diesen Fallback nicht mehr, also:
# cd /boot
# cp initrd-3.11.6-4-desktop initrd-3.11.6-4-desktop-fallbackund abschliessend in der Konfiguration des Bootloaders den Eintrag für 3.11.6-4-desktop clonen und als initrd eben die Datei mit dem "-fallback" als Suffix angeben.
Nach Updates bestimmter Pakete (udev) wird das System auch die Datei "initrd-3.11.6-4-desktop" neu schreiben, die Datei "initrd-3.11.6-4-desktop-fallback" aber nicht, so daß man für den Fall eines Problems mit neuen Einstellungen in der initrd zumindest eine Sicherheitsleine hat.
Nach einem Update der initrd-3.11.6-4-desktop kann man testweise den "normalen" Eintrag für diesen Kernel (wir haben diesen für unsere Fallback-Lösung ja nur kopiert und abgeändert) booten, und wenn dieser funktioniert kopiert man wieder wie oben, weil ja das Update der Datei nachweislich keinen Schaden angerichtet hat.
Will man irgendwann (z.B. wenn die 13.2 herauskommt) diesen Kernel loswerden, dann muss man nur
a) die Einträge im Bootloader
b) die Dateien in /boot mit Version des Fallback Kernels
ls -1 /boot/*3.11.6-4-desktop*
/boot/config-3.11.6-4-desktop
/boot/initrd-3.11.6-4-desktop
/boot/symvers-3.11.6-4-desktop.gz
/boot/sysctl.conf-3.11.6-4-desktop
/boot/System.map-3.11.6-4-desktop
/boot/vmlinux-3.11.6-4-desktop.gz
/boot/vmlinuz-3.11.6-4-desktop
c) Das Verzeichnis mit den Modulen
/lib/modules/3.11.6-4-desktop
und
d) Das Verzeichnis mit Firmwaredateien
/lib/firmware/3.11.6-4-desktophändisch löschen und gut ist.
Der händische Aufwand hält sich also in Grenzen und man kann beruhigt Kernelupdates machen, denn wenn etwas schief geht, hat man immer noch ein "Netz und doppelten Boden".
Einziger "Haken" an der Sache, vor allem bei der /boot-Partition sollte man -sofern man denn eine extra Partition für /boot hat- nicht allzu knausrig sein, 150-200 MB wären eine gute Marke, damit man auch ggf. von (einem) anderen Kernel(n) ein(ige) Fallbacks anlegen kann.
Greetz,
RM
VMPlayer 6.01 geht noch nicht. Gast startet kurz an, danach Crash ohne Meldung in der Konsole. Problem ist wohl noch zu neu, Tante G. findet was, aber alles bisher ohne Lösung. Mal abwarten, ist ja nur die 2. Maschine.
Ich hab den VMPlayer 6.01 installiert und er läuft sauber.
Muss dazu noch sagen, dass ich das System komplett neu aufgesetzt habe, weil der alte Nvidia-Treiber gesponnen hat.
stefan.becker
24.11.13, 21:14
Welchen Desktop (Gnome, KDE) nutzt du?
Wie Nvidia installiert?
Welchen Desktop (Gnome, KDE) nutzt du?
Wie Nvidia installiert?
KDE 4.11
Nvidia läuft derzeit über xorg-x11-driver-video-nouveau.
stefan.becker
25.11.13, 18:12
Also am Desktop liegt es nicht, ich habe es mit IceWM getestet, geht auch nicht.
stefan.becker
25.11.13, 20:44
Es liegt am Nvidia Treiber. Mit einer älteren Version (325.15) klappt es auf Anhieb, mit dem aktuellen (331.20) nicht.
asterixxer
26.11.13, 10:26
Ich habe von 12.3 auf 13.1 upgedatet. Alles laeuft bis auf Firefox und Seamonkey. Probleme mit glibc. Die ueblichen Tips fruchten bei mir leider nicht. Ich mache jetzt mal einen cleaninstall bei beibehaltener home...
Ich habe gestern abend eine Neuinstallation auf meinem Laptop gemacht. Da ich in der letzten Zeit etwas von der SuSI enttaeuscht war, weil einiges schlecht oder gar nicht mehr funktioniert hat, habe ich in eine separate Partition installiert, so dass mein Original-System 12.2 unversehrt beibehalten wurde.
Zu meinem Erstaunen hat eigentlich alles auf Anhieb funktioniert, Sound, Grafik, WLAN etc. Nur die Definition meines Proxy in YaST meldet immer einen Fehler. Ansprechbar in Firefox ist er aber. Wird wohl ein YaST-internes Problem sein...
So, und jetzt gehts an Feintunig. Wenn das auch klappt, kommen die anderen Maschinen an die Reihe;-)
Gruss Pit.
SUSEDJAlex
27.11.13, 00:40
Der neueste Nvidia Treiber geht problemlos als DoItYourself-Lösung. Aufruf des Installers reicht aus. Standard Konsole (init 3, su, sh ./N*n).
VBOX geht nach Neuübersetzen der Kernelmodule, VMPlayer ist kompatibel zu jedem Update (sprich geht nicht).
Im Firefox gehen auch Flash 11.9 und Silverlight 5.1 problemlos.
Insgesamt ein rundes Update. Die Probleme sind bei VMWARE normal und nicht dem Suse Team anzulasten.
Fazit: Sehr gute Arbeit. Werde mal nach einer VMWARE Lösung suchen, dann wird auch die 2. Maschine aktualisiert.
Wie kommst du auf Flash 11.9 ?
dann zeige mir das mal....
Warum ich das frage, hängt einfach mit der Unterstützung des Flash-player für Linux zusammen....
LG SUSEDJAlex
stefan.becker
27.11.13, 18:38
Wobei Silverlight 5.1 noch abstruser ist :)
Wundert mich, das erst jetzt jemand fragt.
https://build.opensuse.org/project/show/home:rbos:pipelight
Ist eine Lösung zum Zugriff auf DRM geschützte Online-Mediatheken wie LoveFilm etc.
Übrigens kann Chrome per PepperFlash auch Flash 11.9 nativ. Auch Chromium.
So, Update durchgeführt. Ich habe mich für das Update aus dem laufenden System entschieden, vorher aber das System gesichert (komplett, inkl. /boot) und mir einen Live-USB-Stick erstellt für mögliche Probleme. Ganz problemlos lief das Update leider nicht ab und es sind wohl noch Nacharbeiten notwendig.
Ein Zwischenfazit:
1.) Bootloader: Mein System hat(te) zwei UEFI-Einträge, einmal einen veralteten der auf Ubuntu verweist (\EFI\ubuntu\grubx64.efi) und dann einen aktuellen der auf OpenSuse verweist. Ich hatte bislang schlicht keine Lust/Zeit das zu ändern. Nach dem Update hat OpenSuse hier aufgeräumt... leider nicht in positivem Sinne. :ugly: Jedenfalls war nur noch der Eintrag für Ubuntu da. Falls jemand das gleiche Problem hat: Das lässt sich beheben durch:
efibootmgr --create --disk /dev/sda --part 1 --label "OpenSuSE" --loader \\EFI\\opensuse\\grubx64.efi
(Quelle: http://wiki.ubuntuusers.de/efibootmgr)
Die Partition und ggf. die Platte muss natürlich noch angepasst werden.
2.) Dritt-Repositories: Habe sowohl Bumblebee als auch Kernel:Stable aktiviert gelassen, bislang keine Probleme feststellbar. Der Nvidia-Treiber baut zwar scheinbar nicht unter dem 3.11er-Kernel, aber das hängt wohl mit diversen Änderungen meinerseits zusammen. Muss ich nochmal genauer überprüfen.
3.) Bootsplash: Der Bootsplash ist weg, warum auch immer. Bislang habe ich noch keine Möglichkeit gefunden ihn wieder zu aktivieren, habe auch im Netz bislang nix dazu gefunden.
Ansonsten noch diverser Kleinkram:
- im Nautilus sind diverse Texte nicht lokalisiert, z.B. in der Leiste links "Recent", "Devices", "Browse Network", ...
- In der Grub-Konfiguration wurde die Versionsnummer nicht aktualisiert (von 12.3 auf 13.1), habe ich dann manuell gemacht
- Bei einem Reboot wollte er das Festplattenpasswort nicht akzeptieren, trotz mehrfacher (korrekter) Eingabe. Trat bei späteren Bootvorgängen jedoch nicht mehr auf.
Dass sich Opensuse beim Update selbst den Booteintrag wegbügelt darf meiner Meinung nach absolut nicht passieren. Ein Linux-Einsteiger wäre hier aufgeschmissen gewesen. Davon abgesehen lief das Update bislang aber ganz ok. Mal schauen ob ich die angesprochenen Punkte noch beheben kann.
-hanky-
edit: Ok, das mit dem Bootsplash (Plymouth) ist wohl Absicht:
++++ plymouth:
- disable plymouth in initrd if the root volume is encrypted. This
is a workaround until plymouth is able to handle the prompt
correctly (bnc#834063).
Quelle: http://suse.mirrors.tds.net/pub/opensuse/ports/aarch64/distribution/13.1/repo/oss/ChangeLog
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.