[Gelöst] OS 13.2 - System startet nicht mehr nach AMD Update

Martin85 · 31. Dezember 2014

Zitat von Sauerland
Repo Nr. 6 home:codeminister ist für openSUSE 13.1, würde ich entfernen:
Als root (du hast Dich als User Martin eingeloggt):
Code
zypper rr 6
Dann den Treiber noch einmal installieren:
Code
zypper in -f fglrx64_xpic_SUSE132
Neustart.

Wenn das nicht funktioniert, den Treiber als root wieder deinstallieren:
Code
zypper rm fglrx64_xpic_SUSE132
Da sollten dann auch in der Übersicht die anderen 4 fglrx-Pakete mit deinstalliert werden.
Alles anzeigen

Habe mich als root eingeloggt und die Befehle eingegeben. Soweit auch alles geloescht. Als beim Neustart immer noch alles beim Alten war, habe ich den Treiber wie beschrieben deinstalliert. Wenn ich jetzt nochmal den Befehl zum installieren eingeben kommt "Package 'fglrx64_xpic_not found". Muss ich jetzt vielleicht nochmal den SUSE eigenen Treiber laden ...und wenn ja, wie?

Sauerland · 31. Dezember 2014

Zitat von Martin85

Muss ich jetzt vielleicht nochmal den SUSE eigenen Treiber laden ...und wenn ja, wie?

Ne eigentlich nicht.

Poste noch einmal:

Code

zypper se -si fglrx

Martin85 · 31. Dezember 2014

Code

i | fglrx64_amdcccle_suse132 | package | 14.501.1003-1 | x86_64 | System Packages
i | fglrx64_core_suse132 | 
i | fglrx64_graphics_suse132 |
i | fglrx_opencl_suse132 |

..nach dem jeweils letzten Trennstrich sind die Parameter der nachfolgenden Zeilen gleich

Sauerland · 31. Dezember 2014

Dann hat der die nicht mit deinstalliert:
Als root:

Code

zypper rm fglrx64_amdcccle_suse132 fglrx64_core_suse132 fglrx64_graphics_suse132 fglrx_opencl_suse132

Martin85 · 31. Dezember 2014

jaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Ganz ganz herzlichen Dank!!! Das Ding läuft wieder.
Ich freue mich echt riesig. Das rettet mir den Tag
Nochmals ganz großes Dankeschön

Sauerland · 31. Dezember 2014

Poste bitte noch einmal:

Code

/sbin/lspci -nnk | grep -E -iA2 'vga|3d'

Ist der PC immer noch so lahm? Poste einmal:

Code

systemd-analyze blame

herunterscrollen mit Pfeiltasten, abbrechen am Ende mit q

Martin85 · 31. Dezember 2014

jep, von der Geschwindigkeit so wie vor dem Zeitpunkt, an dem ich mir das System mit den AMD Treibern zerschossen habe

Code

martin@linux-mlm3:~> /sbin/lspci -nnk | grep -E -iA2 'vga|3d'
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6320] [1002:9806]
	Subsystem: Lenovo Device [17aa:397b]
	Kernel driver in use: radeon
martin@linux-mlm3:~> systemd-analyze blame
      	5.530s systemd-udev-settle.service
      	2.842s ModemManager.service
      	2.494s display-manager.service
      	2.465s postfix.service
      	1.985s SuSEfirewall2_init.service
      	1.679s vboxdrv.service
      	1.659s polkit.service
      	1.549s SuSEfirewall2.service
      	1.488s NetworkManager.service
      	1.442s systemd-fsck@dev-disk-by\x2duuid-cf578ce6\x2d3ae1\x2d40ac\x2db0
      	1.288s apparmor.service
      	1.017s nscd.service
      	1.005s wpa_supplicant.service
       	933ms \x2esnapshots.mount
       	898ms var-tmp.mount
       	851ms var-spool.mount
       	848ms systemd-tmpfiles-setup.service
       	811ms var-opt.mount
       	782ms lvm2-activation-early.service
       	681ms sys-kernel-debug.mount
       	673ms var-log.mount
       	670ms dev-mqueue.mount
       	669ms dev-hugepages.mount
lines 1-23...skipping...
      	5.530s systemd-udev-settle.service
      	2.842s ModemManager.service
      	2.494s display-manager.service
      	2.465s postfix.service
      	1.985s SuSEfirewall2_init.service
      	1.679s vboxdrv.service
      	1.659s polkit.service
      	1.549s SuSEfirewall2.service
      	1.488s NetworkManager.service
      	1.442s systemd-fsck@dev-disk-by\x2duuid-cf578ce6\x2d3ae1\x2d40ac\x2db028\x2df5048c59c4ab.service
      	1.288s apparmor.service
      	1.017s nscd.service
      	1.005s wpa_supplicant.service
       	933ms \x2esnapshots.mount
       	898ms var-tmp.mount
       	851ms var-spool.mount
       	848ms systemd-tmpfiles-setup.service
       	811ms var-opt.mount
       	782ms lvm2-activation-early.service
       	681ms sys-kernel-debug.mount
       	673ms var-log.mount
       	670ms dev-mqueue.mount
       	669ms dev-hugepages.mount
       	632ms var-lib-pgsql.mount
       	631ms colord.service
       	601ms systemd-tmpfiles-setup-dev.service
       	546ms systemd-remount-fs.service
       	543ms var-lib-named.mount
       	490ms ntpd.service
       	462ms systemd-udev-root-symlink.service
       	382ms systemd-udev-trigger.service
       	350ms lvm2-lvmetad.service
       	341ms systemd-update-utmp.service
       	296ms alsa-restore.service
       	275ms systemd-user-sessions.service
       	258ms rc-local.service
       	257ms home.mount
       	255ms accounts-daemon.service
       	244ms plymouth-read-write.service
       	243ms var-lib-mailman.mount

Alles anzeigen

Alero · 31. Dezember 2014

@Sauerland
Kann man anhand der ausgegebenen Werte etwas herauslesen respektive gibt es Richtlinien was in etwa wie schnell sein sollte?

Sauerland · 31. Dezember 2014

Zitat von Alero

Kann man anhand der ausgegebenen Werte etwas herauslesen respektive gibt es Richtlinien was in etwa wie schnell sein sollte?

Ja, alles ziemlich im Rahmen.
Richtlinien gibt es keine, es geht auch nur um den Systemstart.
Bei mir fällt natürlich der Start von wicked auf, trotz SSD:

Code

systemd-analyze blame
          6.954s wicked.service
          1.681s systemd-udev-settle.service
           799ms systemd-fsck@dev-disk-by\x2did-ata\x2dSAMSUNG_HD501LJ_S0MUJ1FP
           416ms systemd-fsck@dev-disk-by\x2did-ata\x2dST1000DM003\x2d9YN162_W1
           391ms vboxdrv.service
           367ms udisks2.service
           344ms systemd-fsck@dev-disk-by\x2did-ata\x2dSAMSUNG_HD501LJ_S0MUJ1FP
           285ms postfix.service
           271ms systemd-fsck@dev-disk-by\x2did-ata\x2dST1000DM003\x2d9YN162_W1
           173ms SuSEfirewall2.service
           160ms systemd-fsck@dev-disk-by\x2did-ata\x2dST1000DM003\x2d9YN162_W1
           139ms mnt-home.mount
           118ms SuSEfirewall2_init.service
           116ms systemd-fsck@dev-disk-by\x2did-ata\x2dSAMSUNG_HD103UJ_S13PJ1KS
           113ms ModemManager.service
           111ms mnt-openSUSE132.mount
           109ms systemd-tmpfiles-setup.service
            92ms systemd-udev-root-symlink.service
            90ms lvm2-activation-early.service
            84ms display-manager.service
            83ms dev-mqueue.mount
            82ms dev-hugepages.mount
            82ms sys-kernel-debug.mount
            78ms home-musik.mount
            78ms apparmor.service
            77ms ddclient.service
            70ms systemd-user-sessions.service
            67ms alsa-restore.service
            67ms noip2.service
            66ms plymouth-read-write.service
            65ms lm_sensors.service
            64ms systemd-fsck-root.service
            62ms openct.service
            60ms home-video.mount
            60ms systemd-tmpfiles-setup-dev.service
            59ms avahi-daemon.service
            53ms nscd.service
            49ms systemd-fsck@dev-disk-by\x2duuid-57a75bf0\x2d1db3\x2d496c\x2d9
            47ms systemd-udev-trigger.service
            46ms rc-local.service
            41ms home-1000TB.mount
            40ms dev-disk-by\x2duuid-5e6e20b1\x2d15ec\x2d4598\x2d9d3d\x2defd083
            39ms wpa_supplicant.service
            31ms systemd-logind.service
            31ms libvirtd.service
            30ms user@1000.service
            30ms ntpd.service
            27ms rtkit-daemon.service
            26ms dm-event.service
            23ms lvm2-lvmetad.service
            22ms systemd-tmpfiles-clean.service
            22ms kmod-static-nodes.service
            22ms lvm2-activation.service
            21ms systemd-readahead-replay.service
            20ms polkit.service
            20ms cycle.service
            19ms systemd-readahead-collect.service
            17ms pdns-recursor.service
            17ms vboxweb-service.service
            16ms home.mount
            16ms vboxautostart-service.service
            16ms plymouth-start.service
            16ms vboxballoonctrl-service.service
            16ms mnt-openSUSE131.mount
            15ms systemd-random-seed.service
            15ms systemd-modules-load.service
            15ms iscsi.service
            15ms logrotate.service
            13ms systemd-sysctl.service
            10ms upower.service
             8ms sshd.service
             8ms wickedd-dhcp4.service
             8ms systemd-vconsole-setup.service
             7ms systemd-journal-flush.service
             6ms wickedd-dhcp6.service
             5ms systemd-update-utmp-runlevel.service
             5ms systemd-update-utmp.service
             4ms wickedd-auto4.service
             4ms wickedd-nanny.service
             4ms wickedd.service
             3ms systemd-remount-fs.service
             2ms systemd-readahead-done.service
             2ms sys-fs-fuse-connections.mount
             1ms systemd-backlight@backlight:eeepc-wmi.service
             1ms systemd-udevd.service

Alles anzeigen

Ist aber auch alles noch normal.
Bei openSUSe 13.1 und 12.3 hat ifup immer lange gedauert, das war bekannt und konnte durch umschwenken auf NetworkManager behoben werden.

Trekkie00 · 31. Dezember 2014

Hier ein Link, der Dir vielleicht einen kleinen Einblick in die Interpretation gibt.

Für das Auge ansprechender und leichter interpretierbar ist vielleicht die Variante

Code

systemd-analyze blame plot > output.svg

Statt output kann man auch jeden anderen Namen einsetzen.
Dieser Befehl erzeugt in dem Verzeichnis, in dem der Befehl abgesetzt wurde, eine svg Grafik, in der das Ganze grafisch veranschaulicht wird.

[Gelöst] OS 13.2 - System startet nicht mehr nach AMD Update

Ubuntu 26.10 „Stonking Stingray“ ist erschienen

Tumbleweed-Update bricht ab

KDE Plasma 6.8 verabschiedet sich von X11

VBox - gemeinsame Zwischenablage

Linux-Kernel: Kennzeichnungspflicht für KI-generierten Code soll entfallen

k.113

BlackPhoenix

aitexturegenerator

Giorgio68

pavelstr

Teilen