Beiträge von Lindauer_Linse

  • Auslagerungsdatei einrichten

    Neu ist, daß der Rechner zwar nach längerer Nichtbenutzung in den Bereitschaftszustand geht (Lüfter etc. aus, Betriebsanzeige-LED blinkt), aber wenn man ihn daraus hochfahren will, dann bleibt der PC hängen. Drückt man den Reset-Knopf (mein 14 Jahre alter PC hat den noch), startet ohne Anzeige des Grub-Menüs Tumbleweed im Normalmodus, bleibt hängen und muß wieder mit Affengriff ("Strg+Alt+Entf) neu gestartet werden.. Die Linux Standby-Funktion war aber immer schon etwas anfällig für ähnliche Fehlfunktionen, daher denke ich kaum, daß dies mit dem Swap-Fehler zu tun hat.

  • Auslagerungsdatei einrichten

    Hallo Feli,

    Code
    roland@linux:~> free -m
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:       2962        1369         506          42        1287        1593
Swap:           8605           0        8605

    Also im "Recovery mode" gestartet steht die Swap-Partition anscheinend zur Verfügung. Im "Normalmodus" bleibt der Rechner beim Systemstart hängen.

    Das deutet wieder auf einen fehlerhaften Befehl oder *.cfg-Datei beim "normalen Hochfahren". Macht es Sinn, die Skripte etc., die dabei ausgeführt werden, nach der veralteten UUID zu durchsuchen? Wo befinden sich diese?

    Gruß, Roland

  • Auslagerungsdatei einrichten

    Ich habe einmal in der Manpage vom Befehl "swapon" gestöbert und fand dort interessante Hinweise, die mich vermutlich ein Schrittchen weiterbrachten:

    Starte ich im Recovery-Modus, so ist die Swap-Partition sdb7 eingehängt (Das K-Infozentrum zeigt anscheinend nur die Belegung des physischen RAM an, bei mir ca. 3 GB):

    Code
    linux:/home/roland # cat /proc/swaps
Filename                                Type            Size            Used            Priority
/dev/sda7                               partition       8812540         0               -2
linux:/home/roland # swapon -a
linux:/home/roland # cat /proc/swaps
Filename                                Type            Size            Used            Priority
/dev/sda7                               partition       8812540         0               -2

    Der Befehl "swapon -a" ändert daran nichts.

    Vermutlich ist alles im System in Ordnung, und der PC kommt derzeit noch mit dem RAM aus (used: 0).

    Beim "normalen Start" versucht der PC allerdings wohl ein fehlerhaften Eintrag abzuarbeiten, der sich auf die alte, falsche Swap-UUID bezieht.

    Aus einem Foto abgetippt:

    "A start job ist running for /dev/disk/by-uuid/d1ee22f0-da63-443f-9d71-57fb38f357ef (zeit/no limit) ... und wegen "no limt" bleibt der PC hängen.

    Vermutlich braucht man nur diesen Eintrag zu korrigieren oder zu löschen ... aber damit bin ich leider ohne Hilfe überfordert.

  • Auslagerungsdatei einrichten

    Hallo zusammen,


    erst einmal die von FE gewünschten informationen - nachdem ich den falschen Swap-Eintrag aus der "fstab" entfernt habe:

    Beide Festplatten haben auch nicht formatierte, freie Bereiche. An den Windows-Betriebssystem-Partitionen sda1 (Windows 7) und sdb1 (Windows XP) soll man nicht so ohne weiteres aus Linux heraus Änderungen vornehmen, daher haben sie keinen Einhängepunkt. Es finden sich keine Nutzdaten darauf, die sind in die übrigen einhängbaren Partitionen ausgelagert.


    Vielen Dank für Deinen Link, Alero. Die dort erwähnten Befehle finden sich auch bei OpenSuse. Falls jetzt keine anderen Hinweise mehr kommen, werde ich das ausprobieren.


    Die Swap-Partition habe ich neu formatiert, da - wie bereits beschriieben - bei der Installation des inzwischen wieder gelöschten Linux-Mint deren Dateisystem so verändert wurde, daß mein Windows-Partitionierungs- und Datensicherungprogramm Paragon Festplattenmanager 17 sie als ungültige Partition markierte und damit Datenwiederherstellung auf der gesamten Festplatte sdb verweigerte. Mein havariertes Windows 7 mußte ich daher auf sda wiederherstellen.

    Da Paragon einige Dinge bei der neuen Version 17 echt "verschlimmbessert" hat, wäre ich für Hinweise auf Alternativen dankbar, mit dem man Datensicherungen regelmäßig und komprimiert vornehmen und per Notfall-CD unabhängig von einem funktionierenden Betriebssystem wiederherstellen kann.

  • Auslagerungsdatei einrichten

    Hallo Alero,


    vielen Dank für Deine Hinweise. Ich konnte damit nachvollziehen, was es mit der UUID auf sich hat - und bin auch einen Schritt weitergekommen.

    Ausgabe von blkid:

    Code
    linux:/home/roland # blkid
/dev/sdb4: LABEL="Linux_Tumbleweed" UUID="c168f73e-2116-4bfa-90dd-60932afb2686" BLOCK_SIZE="4096" TYPE="ext4" PTTYPE="dos" PARTUUID="76923b49-04"
/dev/sdb2: LABEL="Reserve(NTFS)" BLOCK_SIZE="512" UUID="14B9E25A4ADABDE0" TYPE="ntfs" PARTUUID="76923b49-02"
/dev/sdb7: UUID="af01ef0a-4cc9-4cec-ad9d-efc4d231c531" TYPE="swap" PARTUUID="76923b49-07"
/dev/sdb5: LABEL="Internet" BLOCK_SIZE="512" UUID="708E0ADC6DE19F5D" TYPE="ntfs" PARTUUID="76923b49-05"
/dev/sdb1: LABEL="Windows_XP" BLOCK_SIZE="512" UUID="4C5484C25484B06E" TYPE="ntfs" PARTUUID="76923b49-01"
/dev/sdb6: LABEL="Multimedia" BLOCK_SIZE="512" UUID="544CC7164CC6F1B2" TYPE="ntfs" PARTUUID="76923b49-06"
/dev/sda5: LABEL="Permanente_Daten" BLOCK_SIZE="512" UUID="4D3D4A94583D9587" TYPE="ntfs" PARTUUID="f6407b20-05"
/dev/sda1: LABEL="Windows_7" BLOCK_SIZE="512" UUID="FEDAB4A2DAB4591B" TYPE="ntfs" PARTUUID="f6407b20-01"
/dev/sda6: LABEL="Temporaer" BLOCK_SIZE="512" UUID="62C695E7C695BBAB" TYPE="ntfs" PARTUUID="f6407b20-06"

    Die entscheidende Partition ist sdb7. Dann habe ich mir angesehen, was in der "fstab" steht und fand dort 2 Einträge für "swap"

    fstab(swap_doppelt).bak.txt

    Davon hat ein Eintrag die falsche UUID d1ee22f0-da63-443f-9d71-57fb38f357ef, die auch beim Hochfahren angezeigt wurde. Diesen Eintrag habe ich gelöscht.


    Danach versucht das System aber immer noch beim "normalen" Hochfahren, die Swap-Partition auf dieser falschen UUID einzuhängen. Im "Recovery-Modus" läuft das Hochfahren jetzt glatt durch, aber der swap-Speicher steht nicht zur Verfügung.

    Also muß noch irgendwo anders ein Eintrag richtig gestellt werden.

  • Auslagerungsdatei einrichten

    Vorübergehend hatte ich parallel zu meinem OpenSuse Tumbleweed noch Linux Mint installiert. Die Swap-Partition sda7 wurde von beiden Systemen benutzt.

    Wegen ansonsten nicht lösbarer Schwierigkeiten mit meinem Windows-Daternsicherungsprogramm (Paragon Festplattenmanager 17, Linux Mint scheint ein spezielles Ext4-Dateisystem zu verwenden, mit dem die PM17 überfordert ist) habe ich Linux-Mint heute heruntergeschmissen und die Swap-Partition neu mit "GParted" formatiert.

    Danach startet mein Tumbleweed nur noch im "Recovery Modus", auch nachdem ich dort mit Hilfe des YAST-Partitionieres die Swap-Partition erneut formatierte und zum Einhängen als "Swap" kennzeichnete.

    Beim normalen Start bleibt der PC in einer Endlos-Schleife hängen ("a start job ist running"), im "Recovery mode" wird dieser na 1'30'' abgebrochen, und mit einem blitzschnell geschossenen Foto erhielt ich folgende Infos:

    "[ Time ] Timed out waiting for device /dev/disk/by-uuid/d1ee22f0-da63-443f-9d71-57fb38f357ef.

    [Depend] Dependency failed for /dev/disk/by-uuid/d1ee22f0-da63-443f-9d71-57fb38f357ef.

    [Depend] Dependency failedfor Swap."

    In der System-Info wird tatsächlich nur der RAM-Arbeitsspeicher angezeigt, und das System ist zeitweise instabil.

    Anscheinend muß man dem System außer mit YAST noch an anderer Stelle sagen, daß es eine Swap-Partition hat und wo sich diese befindet. Kann mir jemand sagen, wo? Stimmt vielleicht trotz Neupartitionien mit YAST die in der fstab hinterlegte UUID (was auch immer das ist) nicht mehr?

  • Problemmeldungen bei Tumbleweed-Aktualisierung: Dateien können nicht bereitgestellt werden

    Ich habe die überflüssigen Repositories per YAST deaktiviert, das zusätzliche Repository "openh264" (Nachfolger des veralteten "libdvdcss"?) hinzugefügt - und siehe da, die Aktualisierungsprobleme waren auf beiden Rechnern gelöst! Das veraltete "ruby3.1" wurde anscheinend komplett deinstalliert und das neue "ruby3.2" installiert. Vielen Dank!

    Das Repository von der Installations-DVD hat Tumbleweed beim Aufsetzen selbstständig angelegt, und als ich noch über das KDE-Programm aktualisierte, auch immer wieder die DVD angefordert. Auch "zypper" griff auf dieses Repository zurück, wenn - wie es immer wieder der Fall ist - vermutlich fehlerhafte neue Softwarepakete durch ältere Versionen ersetzt wurden. Anscheinend kann aber "zypper" diese alten Pakete aus einer anderen Quelle beziehen, denn jetzt waren auch Pakete zurückzusetzen. Wenn es weiterhin keine Probleme gibt, werde ich die überflüssigen Repositories löschen.

    Frage: Wo erfahre ich, welche Repositories gerade aktuell sind? Das scheint sich ja immer wieder einmal zu ändern.

  • Problemmeldungen bei Tumbleweed-Aktualisierung: Dateien können nicht bereitgestellt werden

    Hallo Alero,


    zunächst die Ausgabe auf den Befehl: "zypper lr -d":

    roland@linux:~> su

    Passwort:

    linux:/home/roland # zypper lr -d

    # | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI

    | Serv->

    ---+----------------------------------------+---------------------------------+-----------+-----------------+----------------+-----------+----------+-----------------------------

    --------------------------------------------------+-------

    1 | Kopie_Installations-DVD | Kopie_Installations-DVD | Ja | (r ) Ja | Nein | 99 | rpm-md | dir:/home/roland/OpenSuse_Tu

    mbleweed_Installations-DVD |

    2 | Mozilla+Thunderbird | Mozilla+Thunderbird | Ja | (r ) Ja | Ja | 99 | rpm-md | https://download.opensuse.or

    g/repositories/mozilla/openSUSE_Tumbleweed/ |

    3 | OpenOffice | OpenOffice | Ja | ( p) Ja | Nein | 99 | plaindir | dir:/home/roland/OpenOffice/

    de |

    4 | download.nvidia.com-tumbleweed | nVidia Graphics Drivers | Ja | (r ) Ja | Ja | 99 | rpm-md | https://download.nvidia.com/

    opensuse/tumbleweed |

    5 | download.opensuse.org-non-oss | Haupt-Repository (NON-OSS) | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org

    /tumbleweed/repo/non-oss/ |

    6 | download.opensuse.org-oss | Haupt-Repository (OSS) | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org

    /tumbleweed/repo/oss/ |

    7 | download.opensuse.org-tumbleweed | Hauptaktualisierungs-Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://download.opensuse.org

    /update/tumbleweed/ |

    8 | ftp.gwdg.de-Essentials | Packman Essentials Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://ftp.gwdg.de/pub/linux

    /misc/packman/suse/openSUSE_Tumbleweed/Essentials |

    9 | ftp.gwdg.de-openSUSE_Tumbleweed | Packman Repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://ftp.gwdg.de/pub/linux

    /misc/packman/suse/openSUSE_Tumbleweed/ |

    10 | openSUSE-20220302-0 | openSUSE-20220302-0 | Ja | (r ) Ja | Nein | 99 | rpm-md | cd:/?devices=/dev/disk/by-id

    /ata-HL-DT-STDVD-RAM_GSA-H58N |

    11 | opensuse-guide.org-openSUSE_Tumbleweed | libdvdcss repository | Ja | (r ) Ja | Ja | 99 | rpm-md | http://opensuse-guide.org/re

    po/openSUSE_Tumbleweed/ |

    12 | repo-debug | openSUSE-Tumbleweed-Debug | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org

    /debug/tumbleweed/repo/oss/ |

    13 | repo-source | openSUSE-Tumbleweed-Source | Nein | ---- | ---- | 99 | NONE | http://download.opensuse.org

    /source/tumbleweed/repo/oss/ |

    linux:/home/roland #

    Ich hoffe, ich habe das mit "Code-Tags" richtig gemacht, irgendwie ist die Darstellung ist aber längst nicht so übersichtlich wie in der Konsole.

    Das Repository "Kopie Installations-DVD" habe ich über YAST eingerichtet, nachdem ich diese in den aufgeführten Ordner kopiert habe. So entfällt das lästige Holen der DVD. Da ich den Fehler dort vermutete, habe ich dieses Repositorty vorübergehend deaktiviert, aber ohne daß sich an der Fehlerausgabe etwas änderte.

    Update führe ich nur noch per Konsole mit "zypper dup" durch, nachdem ich mich zunächst als su (hat bei mir ein anderes Kennwort als der Normalbenutzer) angemeldet habe. Es ist die Konsole, die im Startmenü von KDE angeboten wird.

    Auffällig sind die letzten beiden Einträge. Muß ich hier noch neue Repositories einrichten?

    Das Problem mit dem Update scheinen inzwischen aber auch andere zu haben, z.B. "big262" vor 3 Stunden.


  • Problemmeldungen bei Tumbleweed-Aktualisierung: Dateien können nicht bereitgestellt werden

    Seit einigen Tagen meldet "zypper dup" immer wieder neue Probleme auf meinen beiden PC's (siehe Anhang). Für zu aktualisierende Programme können bestimmte andere dafür notwendige Dateien nicht bereitgestellt werden. Insbesondere das Programm "ruby" (vermutlich ein Script-Interpreter) scheint davon betroffen zu sein.

    Da ich mit der Beurteilung den vorgeschlagenen Lösungen überfordert bin, brach ich die Aktualisierung bisher jedesmal ab und versuchte es einige Tage später wieder - in der Hoffnung, die fehlenden Dateien würden inzwischen auf dem Server bereitgestellt. Inzwischen sind über 740 Updates aufgelaufen, und die Probleme werden schlimmer, nicht besser.

    Da beide Rechner betroffen sind, schließe ich ein spezifisches Problem meiner Computer eher aus, lasse mich aber gerne eines besseren belehren.

    Sollte ich dieses als Bug melden?

    Bleibt vielleicht nur die Lösung, eine neue DVD herunterzuladen und die Aktualisierung von dort vorzunehmen? Die dort bereitsgestellte Software sollte ja frei von Abhängigkeitskonflikten sein.

  • Tubleweed: Kernel 6.1.8.1 startet nur als Konsole

    Heute habe ich - diesmal über Terminal - erneut eine ganze Latte Updates installiert, einschließlich des Kernels 6.1.10-1. Freundlicher Weise machte dieses mich auch darauf aufmerksam, daß ich meinen Rechner neu zu starten hätte.

    Danach war - zu meinem großen Erstaunen - die Fehlfunktion bei der Grafik weg. Ich kann an den unteren Bildschirmrand stoßen, soviel ich will,ohne daß sich etwas verschiebt - und zwar beim alten Kernel 6.1.8.1 und beim neuen 6.1.10.1. Auch "Spectacle" zeigt beim Bildschirmfoto wieder den korrekten Bereich (1260x1024) an.

    Da muß also noch ein anderer Bug gewesen sein, der aber inzwischen bemerkt und beseitigt ist.

    Dennoch lasse ich die Sperre über YAST für die NVidia-Grafikartentreiber aus dem Hauptrepository (OSS) erst einmal bestehen, die anscheinend auch zu den Einträgen auf der von "Mustermann" erwähnten Blacklist führt. Meine ältere Grafikkarte benötigt anscheindend die propritären 64bit-Treiber G04 von NVidia.

    Also ist der Fehler nach einigem Hin und Her behoben - erst einmal keine Neuinstallation erforderlich, aber weiterhin Wachsamkeit. Nochmals vielen Dank für Eure Tipps und Anregungen. :)