Emergency mode - dependency failed for ...

Hinweis: In dem Thema Emergency mode - dependency failed for ... gibt es 37 Antworten auf 4 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Hallo,


    ich bitte um Hilfe!


    mein Notebook hängt im Emergency Mode.


    HP-Laptop.
    Leap 15, mit 4.19 Kernel (wg. rtl8723de - bluetooth)
    Gnome


    Habe das Notebook schon öfter ohne Probleme upgedated. Was eigenartig ist, oder zumindest mir so vorkommt ist, dass ich gelegentlich die btrfs-snapshops rauslöschen muss, weil der Rechner sonst irrsinnig langsam wird. Habe mir auf jeden Fall eingebildet, dass das die Lösung war. Langsam war er vor diesem Vorfall auch wieder. Jetzt startet er aber gar nicht mehr.


    Habe versucht einen USB-Stick einzubinden, um die logs und diverse Ausgaben hier reinzukopieren. Der Stick wird mir aber mit fdisk -l nicht angezeigt. Darum schreibe ich mal händisch hier rein, aber etwas gekürzt...


    fdisk -l sagt mir
    Disk /dev/sda: 931GiB...
    Sector size 512 bytes / 4096 bytes
    I/O= size ... 4096 bytes
    Disklabel type: gpt
    Disk identifier: BAAA....
    Device
    /dev/sda1 ... ... BIOS boot
    /dev/sda2 ... ... Microsoft basic data
    /dev/sda3 ... ... Microsoft basic data
    /dev/sda4 ... ... Microsoft basic data



    dev/sda3 dürfte root sein. dev/sda4 home.


    cat /etc/fstab zeigt mir volgendes an


    UUID=bc01be28.... swap swap
    UUID=50e65 .../btrfs defaults
    UUID=50e65 .../opt btrfs subvol=@/
    UUID=50e65 .../srv btrfs subvol=@/


    UUID=50e65 .../tmp btrfs subvol=@/


    UUID=50e65 ... /usr/local btrfs subvol=@/


    UUID=50e65 ... /var/cache btrfs subvol=@/


    UUID=50e65 ... /var/crash btrfs subvol=@/


    UUID=50e65 ... /var/lib/libvirt/images btrfs subvol=@/


    UUID=50e65 ... var/lib/machines btrfs subvol=@/


    UUID=50e65 ... var/lib/mailman btrfs subvol=@/


    UUID=50e65 ... var/libmariadb btrfs subvol=@/


    UUID=50e65 ... var/lib/mysql btrfs subvol=@/


    UUID=50e65 ... var/lib/named btrfs subvol=@/


    UUID=50e65 ... var/lib/pgsql btrfs subvol=@/


    UUID=50e65 ... var/log/btrfs subvol=@/


    UUID=50e65 ... var/opt btrfs subvol=@/


    UUID=50e65 ... var/spool btrfs subvol=@/


    UUID=50e65 ... var/tmp btrfs subvol=@/


    UUID=50e65 ... /.snapshots btrfs subvol=@/


    UUID=20713 ... /home xfs



    Mit "journalctl -xb | grep dependency" steht bei allen obigen Einträgen "Job ... failed with result "dependency""
    Dasselbe auch mit "local-fs.target" und "home.mount"


    Mit "jourcalctl -xb | grep timed" sehe ich dass alle UUID aus /etc/fstab/ mit "...device/start timed out." drinnenstehen.


    Falls nur das System hin ist aber /home noch intakt ist, habe kein Problem damit, mir das System neu zu installieren und /home zu behalten.


    Danke
    cooljazz

    Für den Inhalt des Beitrages 126927 haftet ausdrücklich der jeweilige Autor: cooljazz

  • Da du im Emergency Mode bist, läuft das Ding.


    Was spricht mount ?
    Poste mount | grep -E '/dev/(mapper/)|/dev/sd[a-z]' (der grep fischt alle Einträge, die die Zeichenkette /dev/mapper oder /dev/sdX beeinhalten heraus.)


    Deine Rootpartition unter BTRFS ist wohl viel zu klein gewählt. Macht nicht wirklich Sinn.
    Das Löschen von Snapshots stellt das System zurück auf den Zustand bevor dieser Snapshot erzeugt wurde.
    Mit der Methode schaffst du zwar wieder Platz, aber dem System fehlen dann wieder alle Updates, die zwischenzeitlich reingeprügelt wurden.
    Die werden mit dem nächsten Update wieder eingespielt.
    Ein Perpetuum Stupidas.

  • Hallo
    wie bist du zu openSUSE Leap 15 gekommen?
    Immer wieder Upgrades von Version x zu Version y usw.?


    Seit openSUSE Leap 15 gibt es Änderungen bzgl. Subvolumes:
    Standardmäßig schlägt openSUSE weiterhin ein btrfs-Dateisystem für die Systempartition und ein xfs-Dateisystem für /home vor. Im Root-Dateisystem gibt es nun aber weniger btrfs-Subvolumes. Insbesondere wurden alle /var-Subvolumes zu einem Volume zusammengefasst, für das die Option nocow gilt. Das ist mit Geschwindigkeitsvorteilen beim Logging sowie beim Ändern von Datenbank- und Image-Dateien (Virtualisierung) verbunden.


    Und nur weil dein Stick nicht eingebunden wird, kannst du doch trotzdem die Ergebnisse hier als Code Tags posten, oder?
    Konsole öffnen - Befehl eingeben - und alles kopieren und hier als Code Tags einfügen (ist das Symbol </>).


    Angesprochene Änderungen hier:
    SDB:BTRFS - openSUSE Wiki


    Dieses habe ich geschrieben, da manchmal eine Neuinstallation Sinn macht.
    Hängt hier jedoch von der Antwort meiner ersten Frage ab.


    Poste noch:

    Code
    zypper lr -d

    Für den Inhalt des Beitrages 126933 haftet ausdrücklich der jeweilige Autor: sterun

  • Hallo,


    Berichtigung: Danke für die Info, werde das beizeiten mal umstellen (root vergrößern). Das klingt in der Tat suboptimal. Das ganze im Zuge einer Neuinstallation und gesicherter /home Partition.

    Code
    mount | grep -E '/dev/(mapper/)|/dev/sd[a-z]'


    spuckt mir folgendes aus

    Code
    3 on / type btrfs (ro,relatime,space_cache,subvolid=764,subvol=@/.snapshots/395/snapshot


    sterun: das Problem mit dem Stick habe ich angeführt, weil mein System eben nicht startet und ich im Emergency Mode hänge. Ich wollte die Logs auf den Stick übertragen. Ich poste hier von einem anderen Notebook.


    Ich habe das System, glaub ich, von der letzten Leap 42.3 Version upgedated.


    Code
    zypper lr -d


    spuckt mir sehr viel aus. Neben repo-non-oss, repo-update und repoupdate-non-oss habe ich noch Kernel:stable , Libdvdcss, Packman, und von sauerland Kernel_stable_standard on openSUSE_Leap_15.0 aktiviert.

    Für den Inhalt des Beitrages 126940 haftet ausdrücklich der jeweilige Autor: cooljazz

  • Poste bitte als root ausgeführt:

    Code
    fdisk -l


    Und bitte die Ausgabe in Code-Tags.


    Falls dein Netzwerk in der Konsole funktioniert, kannst du susepaste installieren und benutzen:

    Und benutzen:

    Code
    linux64:~ # fdisk -l | susepaste
    Pasted as:
       http://susepaste.org/59830715
       http://paste.opensuse.org/59830715
    Link is also in your clipboard.
    linux64:~ #

    Die Ausgabe von fdisk-l ist dann unter folgenden Links zu sehen:
    SUSE Paste
    oder
    SUSE Paste

    Für den Inhalt des Beitrages 126951 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Da bekomme ich leider folgendes als Antwort:



    Zitat

    Error: The target filesystem is mounted as read-only. Please make sure the target filesystem is writable.


    Was mir das Kommando fdisk -l sagt habe ich in meinem ersten post schon händisch übertragen.

    Für den Inhalt des Beitrages 126954 haftet ausdrücklich der jeweilige Autor: cooljazz

  • Was mir das Kommando fdisk -l sagt habe ich in meinem ersten post schon händisch übertragen.

    Aber nur die Stellen, die dir wichtig erscheinen.........


    Es fehlt die Hälfte.....
    Klick mal auf eine susepaste-Link in meinem letzten Beitrag und vergleiche mit deiner Ausgabe........

    Für den Inhalt des Beitrages 126955 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Wenn du dorthin etwas installieren möchtest, müsstest du erst einen Remount machen.
    Sowas, wie: mount -o remount,rw <partition> <mountpoint>
    ( -o == mounte mit den Optionen ... )

  • Kannst du denn nicht mit einem Schnappschus starten?
    Im Grub2 unten links?

    Für den Inhalt des Beitrages 126960 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Starten von anderen Snapshots habe ich schon versucht, bei allen bisher das selbe Ergebnis.


    fdisk -l sagt mir folgendes, schön abgeschrieben:



    Spricht was dagegen, wenn ich das System neu installiere? Ist es möglich, dass mein /home beschädigt ist?

    Für den Inhalt des Beitrages 126962 haftet ausdrücklich der jeweilige Autor: cooljazz