Beiträge von TuxSv748

vielleicht hilft folgende Seite etwas weiter: Laufwerk als User mounten

Hallo,

ich liege mit meinen Empfehlungen in dieser Richtung ja selten auf Mainstream, dennoch:

Check this out: http://processors.wiki.ti.com/…lSUITE_Linux_Installation
von: http://e2e.ti.com/support

Grüße
T.

hab keine aktive Erfahrung damit, aber vresuch es mal mit einem Lock auf das Paket:

z.B. von https://en.opensuse.org/SDB:Zypper_usage_12.2

z.B.
add lock: $:> zypper al <nano>
To list currently active locks: $:> zypper ll
To remove a lock, do: $:> zypper rl <nano>

weiterhin:

Other examples:
zypper al zypper # lock package 'zypper' (exact match)zypper al -r repo-oss virtualbox* # restrict the lock to 'repo-oss' repository (allowing installation from others)zypper rl 3 # remove lock by numberYou can manipulate the locks also by directly editing the locks file.

vielleicht hilft es !?

ich kenn die genaue Ausgabe des dry-runs nicht, hätte aber schon eine Auflistung der Files erwartet.

Einfach mal auf Verdacht:
auf dem Stick das recovery Verzeichnis anlegen und dorthin wechseln, dann $:> sudo btrfs restore /dev/sda6 . eingeben ... und hoffen, dass Daten aus dem /home Verzeichnis möglichst früh wiederhergestellt werden, ggfalls mit Ctrl-C abbrechen falls der Stick volläuft.

während der Wiederherstellung, sofern es läuft aus einem anderen Terminal ls -al /<stick>/recovery oder du -sk /<stick>/recovery/home eingeben, sofern sich im 2.Fall die Größe nicht mehr ändert dürfte alles aus home wiederhergestellt sein.

mehr wüsste ich sonst als Hilfe auch nicht.

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

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

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.

Hatte genau dasselbe Problem mit zypper patch unter 42.3

du brauchst eine schreibbare Partition wo die zu rettenden Daten hingeschrieben werden sollen:
dorthin erst mal wechseln mit 'cd'
dann
$:> mkdir ./recovery
$:> btrfs restore /dev/<sdb1>/@home ./revovery
evtl auch ohne /
$:> btrfs restore /dev/sdb1@home ./revovery

@home könnte auch groß geschrieben sein .. @HOME, weiß ich momentan nicht auswendig, kannst du aber fstab entnehmen
sdb1 oder entsprechend ist dann die gemountete btrfs Partition, oder sdb2, ...

sollte so oder ähnlich funktionieren.

Zitat von Berichtigung

wie verseucht alle offiziellen Repos

und wieder 100% das Gegenteil von dem getroffen was ich meinte.

meine Annahme ist das mir das mit Offiziellen nicht passiert, und die Privaten evtl. einer lascheren Prüfung unterliegen - sinnlos - sorry

( Admin: ich denke den Thread kann man als Ganzes löschen, die dies betrifft haben es vernommen - ist nicht erhaltenswert für die Nachwelt )

sorry - ich schreib mir hier noch die Finger blutig weil es manche nicht in den Schädel bekommen um was es in diesem Thread eigentlich geht, ständig Äpfel mit Birnen verwechseln und immer immer immer wieder HIER openSuse ins Spiel bringen.

Es ist eine "Vor der Installations Frage":
Es geht um Linux Mint (19) und Ubuntu (18.04) und nicht openSuse hier. 'andere Linux-Distributionen'

• ich habe kein Mint installiert um die Listen vergleichen zu können
• Wie lange eine Mint Installation dauert und wie komfortabel sie durchzuführen ist - ich habe keine Erfahrung damit.
• und es ging mit bei dem 1/2 Tag auch darum wieder einiger dieser Projekte um die es mir geht aus dem Internet zusammenzusuchen und zu installieren, evtl zu kompilieren. und damit sind gut 3-4h weg von meiner Zeit.

Bremsen produzieren Feinstaub, u.a. auch das ist falsch verstanden. - sorry

eingentlich wollte ich mich auskllinken aus dem Thread, was hiermit vollzogen wird.