Nabend,

ich habe mir ein neues Arch aufgesetzt. Das läuft auch soweit. Nun habe ich noch eine zweite SSD auf der mein altes Antergos lief. Bei der alten SSD hab ich mir leider meine Partitionstabelle zerschossen.

Es waren drei primäre Partitionen auf der SSD (/dev/sda):

/dev/sda1 /boot mit 200 oder 250 MB ext4
/dev/sda2 / mit ?? GB ext4
/dev/sdb3 /home mit dem Rest der Platte ext4
/dev/sda4 swap

Die beiden Partitionen /dev/sda1 und /dev/sda2 sind weg. Die alte Homepartition /dev/sda3 ist noch da und lässt sich auch einhängen und lesen.

Das gibt fdisk /dev/sda aus:
Gerät      Boot    Anfang      Ende  Sektoren  Größe Kn Typ
/dev/sda1  *         2048 103817215 103815168  49,5G 83 Linux
/dev/sda2          514048 103694335 103180288  49,2G 83 Linux
/dev/sda3       103817216 436322303 332505088 158,6G 83 Linux
/dev/sda4       436322304 468862127  32539824  15,5G 82 Linux Swap / Solaris
Die ersten beiden Partitionen sind also nicht korrekt. Die Boot partition wäre mir noch egal. Aber bei der Rootpartition wäre es schon nicht schlecht, wenn ich noch einmal darauf zugreifen könnte.

Irgendwelche Vorschläge, was ich machen kann?

VG
Martin
OK, ich hab wohl überlappende Partitionen:
sudo sfdisk -d /dev/sda
label: dos
label-id: 0x655f8c94
device: /dev/sda
unit: sectors

/dev/sda1 : start=        2048, size=   103815168, type=83, bootable
/dev/sda2 : start=      514048, size=   103180288, type=83
/dev/sda3 : start=   103817216, size=   332505088, type=83
/dev/sda4 : start=   436322304, size=    32539824, type=82
kann ich die Bootpartition /dev/sda1 aus der Partitionstabelle löschen, ohne was zu zerstören?
Da dieser Eintrag schon falsch ist, würdest du einen Teil von Root löschen.
Der Startpunkt von der Bootpartition ist sehrwahrscheinlich richtig. Der Endpunkt eben nicht.
Du kannst erkennen, dass die sda4 zur sda3 die Endpunkte und Startpunkte stimmen.
bei den Anderen Partitionen ist es verschoben.
Der Startpunkt von sda2 könnte richtig sein, da die Bootpartition doch sehr klein ist.
Ob man jetzt einfach mal den Endpunkt der Bootpartition auf Sektor 514047 setzen könnte und sehen ob alles klappt?? Weiß ich leider nicht.
Du kannst es mal probieren und danach die Rootpartition per isoimage mounten.
Bedenke, die Partitionstabelle markiert bloß die Grenzen. Wenn diese verschoben werden sind die Daten und dessen Dateisystem immer noch nicht verändert.
Theoretisch wenn du die richtigen Grenzen kennen würdest, dann könntest du die Partitionstabelle wieder so anpassen und alles ist wie vorher.
Ein backup der Partitionstabelle fehlt wohl. hmm.
hmm, scheint wohl ein größeres Problem zu sein. die Partitionstabelle müsste wieder korrekt sein. Aber mounten von sda1 und sda2 funktioniert leider noch nicht.
sudo mount /dev/sda1 /mnt
mount: /mnt: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/sda1 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.

sudo mount /dev/sda2 /mnt
mount: /mnt: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/sda2 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.
hab dann mal ein fsck auf sda2 gemacht:
sudo fsck.ext4 -v -f -c /dev/sda2

e2fsck 1.45.4 (23-Sep-2019)
ext2fs_open2: Ungültige magische Zahl im Superblock
fsck.ext4: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
fsck.ext4: Ungültige magische Zahl im Superblock beim Versuch, /dev/sda2 zu öffnen

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>

und mit mke2fse die Superblöcke ermittelt.
sudo mke2fs -n /dev/sda2
mke2fs 1.45.4 (23-Sep-2019)
Ein Dateisystem mit 12912896 (4k) Blöcken und 3229520 Inodes wird erzeugt.
UUID des Dateisystems: dd2a676b-40c2-49fb-8610-87e9d51130af
Superblock-Sicherungskopien gespeichert in den Blöcken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424

mit diesen Superblöcken habe ich dann z.B e2fsck -b 11239424 /dev/sda2 ausgeführt. Aber mit allen Blöcken geht es nicht.

Mist :-(
Könnte es sein, dass die Anfangssektoren der Partitionen doch nicht richtig sind?
Wie ist es überhaupt dazu gekommen?
Ob testdisk das noch kann, nachdem versucht wurde den superblock wieder herzustellen?
Kein backup der wichtigen Dateien vorhanden?
Ich glaube ich werde mit qemu mal sowas durchspielen. Dann versuche ich mal testdisk wie gut der was kann. Zum Glück brauchte ich sowas noch nicht.
So, die Feiertage sind geschafft.

Bei den Sektoren bin ich mir eigentlich sicher. Wie das ganze passiert ist, kann ich nicht mit Sicherheit sagen. Ich vermute bei der Installation des neuen Arch auf /dev/sdb habe ich versehentlich mal /dev/sda eingetippt. Ich kann mich erinnern, das ich mal Probleme mit den Partitionen hatte.

Nunja, mein /home ist ja gesichert. Leider habe ich nicht bedacht, das ein paar Programme doch noch Konfigurationen außerhalb von /home ablegen. Im Moment nervt gerade, das meine Cura Einrichtung wohl verloren ist. Das ist echt arbeit gewesen ...
niemand schrieb Die Cura-Configs für die User liegen unter ~/.config/cura/[version]/
Nur ein Teil - nämlich die Preferences ... der Rest (die Settings) unter $USER/.local/share/cura/$CURA_VERSION/settings/

Aber Danke für den Hinweis ... Das hat nämlich dazu geführt, das ich noch mal nach der Pfadangabe gesucht habe und diese Differenzierung gefunden habe. Und der zweite Pfad ist ja auch in meiner Sicherung