System startet nicht mehr

Hinweis: In dem Thema System startet nicht mehr gibt es 25 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Mal ein kleines Update.
    Die Anleitung von @TuxSv748 scheint der richtige Weg zu sein, allerdings scheibt er mir nicht auf meinen Stick, auch nicht als root.
    Ich werde berichten...

    Systembeschreibung:
    Notebook HP Spectre 360 X2
    8GB RAM, SSD 256GB, DualBoot Leap 15 / Win10

    Für den Inhalt des Beitrages 122847 haftet ausdrücklich der jeweilige Autor: HomerJ.S.

  • Kannst du mal Bilder von dem Bildschirm schießen und hier als Anhang einstellen?

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

  • Sorry hat ein bisschen gedauert. Im Anhang sind zwei Bilder das erste zeigt den Bildschirm wenn der Startvorgang hängen bleibt und das zweite wenn ich dann das root Passwort eingegeben habe.

  • Das System startet.
    Nur kann es den weiteren Krempel nicht laden, weil du ein Problem mit deiner Btrfs Partition hast.


    Versuche folgendes, wenn du dich als root in dem Notfall- System angemeldet hast:

    Btrfs ist einfach noch zu jung, als dass schon verlässliche Infos, wie es sich im Katastrophenfall wirklich verhalten wird, vorliegen könnten.
    Btrfs is was für die dummen, jungen Tapferen, die immer das allerneueste haben müssen.
    scnr.

  • Hi,


    wollte mich nochmals kurz melden, kann sein dass meine letzten Angaben aus dem Gedächtnis evtl. nicht ganz richtig waren, deswegen wurde evtl nichts kopiert, weil die zusätzliche Angabe des Subvolume-Bezeichners irreführend war.


    Ich würde es vorzugsweise erst mal versuchen die Daten zu retten, mit:
    Verzeichnis für recovery erstellen:

    • $:> cd <usbstick>
    • $:> sudo mkdir recovery
    • $:> sudo btrfs restore --path-regex '^/(|home(|/.*))$' /dev/<partition> ./recovery
    • zu beachten: ich würde den Stick auf jeden Fall vorher mit einem Linux-Filesystem formatieren um die Attribute etc. beim Kopieren nicht zu verlieren, z.B. ext4
      /dev/<partition> durch den eigenen Partitionsbezeichner ersetzen evtl sdb6 ???

    evtl testen mit:

    • $:> restore -v -F -D -i -o --path-regex '^/(|home(|/.*))$' /dev/<partition> /dev/null

    hierbei sind die Optionen:

    • -s: Also restore snapshots. Without this option snapshots will not be restored.
    • -x: Get extended attributes. Without this option, extented attributes will not be retrieved.
    • -m: Restore metadata: owner, mode and times.
    • -S: Restore symbolic links.
    • -v: Increase verbosity. May be given multiple times.
    • -i: Ignore errors. Normally the restore tool exits immediately for any error. This option forces it to keep going if it can, usually this results in some missing data.
    • -o: Overwrite existing files. If files exist at the output location with the same name, normally the restore utility will skip restoring that file. This option will overwrite the existing files instead.
    • -t: Tree location. The location of the tree of tree roots.
    • -f: Filesystem location. The byte number given will be used as the root of the filesystem, instead of the location specified by the superblock. This can be useful if your superblocks are inconsistent.
    • -u: Superblock mirror. Valid values are 0,1,2. Specifies an alternate superblock copy to use. This may be useful if your 0th superblock is damaged.
    • -d: ???
    • -r: Root objectid. The objectid given will be used as the root of the filesystem, instead of the location specified by the superblock. This may assist in recovery of subvolumes where the real root is damaged.
    • -c: Case insensitive regex matching.
    • -l: List tree roots.
    • -D: Dry run (only list files that would be recovered).
    • --path-regex: Regex for files to restore. In order to restore only a single folder somewhere in the btrfs tree, it is unfortunately necessary to construct a slightly nontrivial regex, e.g.: '^/(|home(|/username(|/Desktop(|/.*))))

    ich hatte bei mir das Problem, dass nach mounten der btrfs Partition die CPU Last sofort auf 100% hochging, was hier scheinbar nicht der Fall ist. Ein restore hat dann aber ohne diese Probleme (weil eben ohne mount) funktioniert.


    Hab die Anweisung mit regex selber jetzt nicht angetestet, sieht aber meiner Ansicht nach ok aus.


    ps: ich hoffe ich habe korrekt nachgebessert, hatte beim eingeben etwas falsch kopiert.

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    3 Mal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 122948 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Nach welchem Mountversuch ___genau___?
    Und warum darf die CPU- Last nicht hochgehen? Evtl. ist genau das nötig, wenn er zu reparieren versucht?


    Es hilft nicht, wenn du in Prosa deine Reparaturversuche poetisch verbrämst.
    Wir wollen kopierte Befehle samt deren kopierter Ausgabe.
    Dann sind die Dinge klar.


    Deinen Befehl kannst du ruhig probieren.
    Gibt Fehlermeldung.
    Die Option -F gibt es bei diesem Befehl nicht.
    Und die -D Option meint Dry-run - tut also genau gar nichts. Vor allem keine Wiederherstellung von Dateien in dein restore Verzeichnis.
    Außerdem fehlt am Anfang "btrfs ".
    Es gibt keinen Befehl von btrfs, der einfach nur "restore" heißt.


    Warum willst du überhaupt eine offensichtlich schon vergeigte Systempartition wiederherstellen?
    (Die zudem eh recht jung zu sein scheint)


    Wo liegt das tatsächliche Home?
    grep -o home /etc/fstab (sollte auch im Rettungslinux funktionieren)

  • Das CMD sollte natürlich so heißen:

    • $:> sudo btrfs restore -v -F -D -i -o --path-regex '^/(|home(|/.*))$' /dev/<partition> /dev/null
      hatte mit einigen Nachbearbeitungen etwas Probleme, deswegen ist manches fälschlich widergegeben
    • über die Optionen: -v -F -D -i -o kann man diskutieren ... ich würde darauf verzichten .... evtl zum testen.


    diese Zeile ist so aus dem Web übernommen.

    • -D ist dry-run, sollte somit nur als Test dienen, was immer als die Ausgabe erscheint (?)
    • -F hab ich selber als Option nicht gefunden, scheint nicht zu existieren, wahrscheinlich ein Fehler in der Vorgabe
    • ich hab deshalb die sinnvolle Eingabe entsprechend abgekürzt


    ich hatte meine Installationen in einer VM jeweils, konnte mit restore meine Daten retten in die neue Installation. Der Mount befehlt dürfte in etwa mount -t btrfs /dev/<partition> /mn/<partition> gelautet haben. Es gibt unter wiki.ubuntuusers Meldungen, dass dieses Problem mit erhöhter CPU Last auftreten kann, allerdings für Kernel 3.


    Meine 42er Installation (neu) unter VM war nach dem mount nicht mehr bedienbar, deswegen hab ich abgebrochen, evtl hätte ich 1h oder mehr warten müssen damit es sich gefangen hätte, - wer weiß.


    Fazit:

    • Mir war es wichtig meine Daten unter /home/... zu retten was ich hiermit geschafft habe, die Partition zu retten hatte ich nie vor und auch nicht vollzogen.
    • Neu installiert und /home wieder eingespielt, das war's ... - läuft

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 122960 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • OK da hab ich jetzt einiges auszuprobieren.


    Versuche folgendes, wenn du dich als root in dem Notfall- System angemeldet hast:

    Der erste Befehl funktioniert, naja halb. Also ich geb den Befehl ein, der Cursor springt in die nächste Zeile und es passiert nichts weiter.
    Beim zweiten Befehl schaut der Bildschirm wie im Anhang aus:



    Der btrfs restore ... funktioniert nicht, hab auch schon versucht was daran zu ändern, aber das ist für mich nur stochern im Dunklen


    Ich bin ehrlich gesagt kurz vorm aufgeben, aber ihr haltet mich momentan noch davon ab. Danke euch allen für die Mühe.

  • Wenn der erste Befehl völlig korrekt getan hat,
    was unter Linux keine Jubelarien hervorruft, wie bei Windows, weil bei Linux davon ausgegangen wird, dass jeder User und jedes Programm einfach tut, ist es überhaupt keine gute Idee den zweiten Befehl auch noch auszuführen.
    Ich hatte deshalb auch geschrieben, "wenn das nicht tut".


    Grundgesetz unter Linux: No news, good news.
    Wird ein Kommando ordungsgemäß und erfolgreich ausgeführt, so gibt es keinerlei Meldung.
    Nur wenn irgendein Fehler auftritt, wird Linux gesprächig. Was dann aber ausgegeben wird, ist i.d.R. Klartext, der jeder Verständigen sofort zeigt, wo zu graben ist und was Sache ist.


    Der erste Befehl sollte die Partition im Repairmodus mounten.
    Das wurde erfolgreich erledigt.
    Damit hast du dann Zugriff auf diese Partition.
    Einfach mit cd /mnt dorthin wechseln und gucken, ob alles da ist. Es sollte dann dort alles sein.
    Und wir wären einen Schritt weiter.


    Falls wir vom gleichen Befehl reden; du solltest der Klarheit halber IMMER den Befehl samt Ausgabe posten, statt darüber zu reden, was du vermeintlich getan hast.


    Probiere es nochmal und poste danach korrekt.

  • lass mal die -F Option weg, scheint falsch im Internet vorgegeben gewesen zu sein:


    $:> sudo btrfs restore -v -D -i -o --path-regex '^/(|home(|/.*))$' /dev/sda6 /dev/null

    • -v: Increase verbosity. May be given multiple times.
    • -i: Ignore errors. Normally the restore tool exits immediately for any error. This option forces it to keep going if it can, usually this results in some missing data.
    • -o: Overwrite existing files. If files exist at the output location with the same name, normally the restore utility will skip restoring that file. This option will overwrite the existing files instead.
    • -D: Dry run (only list files that would be recovered).

    scheinen mir sinnvoll. Hoffe sda6 ist dann auch die richtige Partition !!!


    Damit keine Mißverständnisse auftreten, damit kannst du nur testen ob es funktionieren könnte, wenn dabei schon keine Dateien als Ausgabe gelogt erscheinen ist es wohl sinnlos es konkret auszuführen.
    Falls keine Files gelistet werden, mal kurz sudo fdisk -l posten
    Falls damit Files gelistet werden sollte:


    $:> sudo btrfs restore --path-regex '^/(|home(|/.*))$' /dev/sda6 ./recovery


    letztendlich zum Ziel führen

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    2 Mal editiert, zuletzt von TuxSv748 ()

    Für den Inhalt des Beitrages 122965 haftet ausdrücklich der jeweilige Autor: TuxSv748