[13:51] <bmbbsr> Guten Tag kann man var/log komplett löschen um aufzuräumen
[13:51] <bmbbsr> den inhalt nicht das verzeichniss
[14:34] <ryker> tomreyn hi. weißt du schon, ob bzw. wann du heute zeit haben wirst?
[14:38] <tomreyn> ryker: hi, ab 17:00 uhr, mach gerne schon mal ne zusammenfassung - vielleicht kann ja auch schon jemand anderes vorher helfen, wir machen den support hier ja gemeinschaftlich.
[14:39] <ryker> ok, was genau meinst du mit zusammenfassung?
[14:40] <ryker> ich denke, dass das die operation ist, die ich als erstes durchführen muss: https://wiki.ubuntuusers.de/dd/#Festplatte-klonen ich bräuchte nur jemanden, der mir hilft, sie auch wirklich korrekt auszuführen
[14:40] <le_bot> Title: dd › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[14:40] <tomreyn> du willst daten retten - um was für nen datenträger (modellnummer bekannt?) geht es, was für daten sind da in welchen formaten drauf etc.
[14:41] <ryker> ok, ich versuche es
[14:42] <tomreyn> und sorg dafür dass du freien datenspeicher in der gleichen größe hast (das kann auch auf einem existierenden dateisystem sein, es muss kein unpartitionierter speicher sein - wichtig ist dass es die volle kapazität an einem stück abbildet)
[14:43] <tomreyn> volle  kapazität des quellmediums, also des datenträgers, der die wiederherzustellenden daten enthält. bis soäter
[14:44] <ryker> gut, mach ich, bis später
[14:49] <ryker> es geht um eine Seagate Barracuda 7200.7 80Gb (Model: ST380013 AS), die ich aus einem nicht mehr funktionierenden iMac G5 ausgebaut habe und die jetzt per USB-adapter (mit separater stromzufuhr) an meinen ubuntu-laptop (20.04.5 LTS) angeschlossen ist. laut dem programm "laufwerke" hat die festplatte 4 partitionen (sdc1-sdc4), wobei sdc3 die
[14:49] <ryker> größte ist (80 GB). unter "partitionierung" steht "Unbekannt (mac)"
[14:59] <ryker> zieldatenträger für die datenrettung wäre eine 1 TB große, externe TOSHIBA festplatte, auf der noch 457 GB frei sind. laut "laufwerke" hat diese nur 1 partition (sdd1); dateisystem: ext4
[16:45] <ryker> tomreyn ich glaube, dass ich den folgenden befehl benötige: dd if=/dev/sdc3 of=/media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc3.img
[17:04] <tomreyn> ryker: sorry, musste familiär noch was klären.
[17:04] <tomreyn> ryker: gibt's hinweise darauf, dass die festplatte oder die datenstrukturen darauf defekt / inkohärent sind?
[17:05] <tomreyn> ist das ext4-dateisystem von der sdd1-partition nach /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/ gemountet?
[17:06] <tomreyn> der "mount"-befehl sollte das bestätigen
[17:09] <tomreyn> grundsätzlich würde ich empfehlen nicht direkt mit den gerätepfaden wie z.B. /dev/sdc3 oder /dev/sdd1 sondern mit deren geräte-id-pfaden wie z.B. /dev/disk/by-id/ata-ST380013AS-D6A2F_P4GM9AS-part1 zu arbeiten, weil man so leichter vermeidet, das falsche blockgerät zu erwischen
[17:11] <ryker> @tomreyn hi. kein problem
[17:11] <ryker> also ich habe bisher keine hinweise darauf, dass sdd irgendwie defekt sein könnte
[17:12] <ryker> ich denke, sie ist gemountet, weil ich in "dateien" auf sie zugreifen kann
[17:12] <ryker> aber ich überprüfe das mal eben mit dem mount befehl
[17:13] <tomreyn> das geht ja sehr fix.
[17:13] <tomreyn> ansonste sieht der dd-befehl gut aus, ja
[17:13] <ryker> ./dev/sdd1 on /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e type ext4 (rw,nosuid,nodev,relatime,uhelper=udisks2)
[17:14] <tomreyn> töfte
[17:14] <ryker> wie bekomme ich die geräte-id-pfade heraus?
[17:15] <tomreyn> ls -1 /dev/disk/by-id     sollte dir nen hinweis geben
[17:15] <tomreyn> aber die die du da jetzt hast werden schon stimmen, auf jeden fall der zielpfad, und so veremiden wir schon mal dass was flaches überschrieben wird.
[17:15] <tomreyn> *falsches
[17:16] <ryker> ok, da lese ich folgendes heraus: usb-ST380013_AS_0322052312CC-0:0
[17:16] <ryker> usb-ST380013_AS_0322052312CC-0:0-part1
[17:16] <ryker> usb-ST380013_AS_0322052312CC-0:0-part2
[17:16] <ryker> usb-ST380013_AS_0322052312CC-0:0-part3
[17:16] <ryker> usb-ST380013_AS_0322052312CC-0:0-part4
[17:16] <tomreyn> !paste | ryker 
[17:16] <tomreyn> ach menno
[17:17] <tomreyn> ryker: bitte ein pastebin verwenden, wie z.B. https://paste.debian.org
[17:17] <tomreyn> äh https://paste.debian.net/
[17:17] <le_bot> Title: Debian Pastezone (at paste.debian.net)
[17:18] <tomreyn> für alles was 2 zeilen oder mehr sind
[17:18] <tomreyn> ryker: du bist jetzt grade stumm geschaltet, darfst aber in ca. ner minute wieder reden
[17:19] <tomreyn> jetzt
[17:19] <ryker> alles klar. sorry
[17:19] <tomreyn> nutz den dd-befehl mal einfach wie du ihn hast, der wird schon passen
[17:20] <ryker> ok
[17:22] <tomreyn> oder pack am ende noch das dran, dann geht's schneller:   bs=4M status=progress
[17:22] <ryker> jetzt hab ich schon angefangen
[17:22] <ryker> die platte macht geräusche
[17:22] <tomreyn> kannst auch canceln und den gleichen befehl wieder starten
[17:23] <tomreyn> oder abwarten, wie du magst
[17:23] <ryker> wie cancelt man?
[17:23] <tomreyn> strg-c
[17:23] <ryker> oh, er hat schon von sich aufgehört
[17:23] <ryker> mom
[17:24] <tomreyn> erstaunlich fix. dann guck mal wie groß die image-datei ist
[17:24] <ryker> https://paste.debian.net/1267919
[17:24] <le_bot> Title: debian Pastezone (at paste.debian.net)
[17:24] <ryker> 41 kb
[17:24] <tomreyn> wichtiger ist der fehler
[17:25] <tomreyn> sdc3 existiert wohl nicht (mehr?)
[17:25] <ryker> moment
[17:25] <ryker> also laut 'laufwerke' schon
[17:26] <tomreyn> für solche aktionen würde ich empfehlen nur die shell zu nutzen
[17:27] <ryker> wäre da jetzt der blkid-befehl geeignet?
[17:27] <tomreyn> ah, vielleicht hast du es einfach nicht mit sudo aufgerufen?
[17:27] <ryker> doch, hab ich
[17:27] <tomreyn> den dd-befehl, ja?
[17:27] <ryker> sudo dd if=/dev/sdc3 of=/media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc3.img
[17:28] <tomreyn> okay dann mach mal: sudo ls -l /dev/disk/by-id |& nc termbin.com 9999
[17:29] <ryker> https://termbin.com/g2ca7
[17:29] <tomreyn> und dann: sudo ls -l /dev/sdc* |& nc termbin.com 9999
[17:30] <ryker> https://termbin.com/62pd
[17:30] <ryker> womöglich sollte ich es doch mit "part3" probieren?
[17:30] <tomreyn> und dann: sudo fdisk -l /dev/sdc | nc termbin.com 9999
[17:31] <ryker> https://termbin.com/zulk
[17:31] <tomreyn> das würde nicht das darunter liegende, noch nicht identifizierte, problem beheben.
[17:31] <ryker> ok
[17:32] <tomreyn> also fdisk kann die partitionstabelle darauf schon mal nicht lesen
[17:32] <ryker> vielleicht noch folgender hinweis
[17:33] <tomreyn> (falls es denn eine gibt)
[17:33] <ryker> vor ein paar tagen habe ich versucht, die platte mit sudo smartctl -t long -d sat /dev/sdc zu überprüfen
[17:33] <ryker> und das hat auch schon nicht geklappt
[17:33] <tomreyn> gabs ne fehlermeldung?
[17:34] <ryker> ähm, das weiß ich jetzt gar nicht mehr
[17:34] <ryker> ich glaube nicht
[17:34] <ryker> soll ich den befehl nochmal ausführen?
[17:36] <tomreyn> nee, erst mal müssen wir sicherstellen, dass die datenstrukturen auf der disk lesbar sind. ist das apt-paket hfsplus installiert?
[17:37] <ryker> ja, ist installiert
[17:37] <tomreyn> welches tool hat die nochmal "sdc3" angezeigt?
[17:37] <tomreyn> *diR
[17:38] <ryker> 'laufwerke'
[17:39] <tomreyn> sudo file -s /dev/disk/by-id/usb-ST380013_AS_0322052312CC-0:0-part3
[17:40] <ryker> da kommt: /dev/disk/by-id/usb-ST380013_AS_0322052312CC-0:0-part3: symbolic link to ../../sdc3
[17:40] <tomreyn> sudo file -Ls /dev/disk/by-id/usb-ST380013_AS_0322052312CC-0:0-part3
[17:41] <tomreyn> und dann noch
[17:41] <tomreyn> sudo file -Ls /dev/disk/by-id/usb-ST380013_AS_0322052312CC-0:0
[17:43] <tomreyn> ach ich schätze das ist ein APFS-dateisystem, kein HFS+-dateisystem. ich sagte ja schon ich kenn mich mit apple-dateisystemen nicht aus.
[17:43] <ryker> https://pastebin.com/gxXnNh9J
[17:43] <le_bot> Title: /dev/disk/by-id/usb-ST380013_AS_0322052312CC-0:0-part3: Macintosh HFS Extended v - Pastebin.com (at pastebin.com)
[17:43] <ryker> sorry, ich machs nochmal anständig
[17:44] <tomreyn> das ist nur eine zeile, hättest du direkt pasteb dürfen ;)
[17:45] <ryker> https://paste.debian.net/1267922/
[17:45] <le_bot> Title: debian Pastezone (at paste.debian.net)
[17:45] <tomreyn> offenbar ist das dateisystem gemountet
[17:45] <ryker> also hier jetzt nochmal beide befehle
[17:45] <ryker> achso
[17:45] <ryker> dann brauche ich umount, oder?
[17:45] <tomreyn> ja
[17:46] <ryker> sudo umount sdc?
[17:46] <tomreyn> sudo umount /dev/sdc3
[17:46] <ryker> ach ja, danke
[17:46] <ryker> umount: /dev/sdc3: nicht eingehängt.
[17:47] <ryker> sagt er
[17:47] <tomreyn> hmm, tja.
[17:47] <tomreyn> "file" war ja der meinung es sei grade eingebunden
[17:47] <ryker> komisch, ja
[17:47] <tomreyn> mount | nc termbin.com 9999
[17:48] <ryker> https://termbin.com/7e3n9
[17:49] <tomreyn> scheint wohl zu stimmen
[17:49] <tomreyn> welche ubuntu-version hast du da?
[17:49] <ryker> 20.04.5 LTS
[17:51] <ryker> könnte es sein, dass das problem mit der tatsache zusammenhängt, dass die platte per USB angeschlossen ist? bei dem smarctl-befehl musste ich deswegen "-d sat" hinzufügen
[17:51] <ryker> und soll ich mal sudo umount /dev/sdc probieren?
[17:52] <tomreyn> das wird nicht scahden, aber auch nicht helfen.
[17:53] <ryker> okay, ja, weiterhin: nicht eingehängt
[17:53] <tomreyn> die probleme könnten an der usb sta bridge liegen, oder auch an den apple-datenstrukturen
[17:53] <tomreyn> ich tippe auf letzteres
[17:54] <ryker> ok
[17:54] <tomreyn> kannst du mal versuchen, die ganze sdc zu images, nicht nur die partition?
[17:55] <ryker> ok, moment
[17:55] <ryker> wäre das so richtig? sudo dd if=/dev/sdc of=/media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.img
[17:57] <tomreyn> sudo dd if=/dev/disk/by-id/usb-ST380013_AS_0322052312CC-0:0 of=/media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.img bs=4M status=progress
[17:57] <ryker> ah, alles klar
[17:58] <ryker> ok, jetzt zeigt er im unterschied zu vorhin den kopierstatus an
[17:58] <ryker> aber jetzt kam doch wieder der ein-/ausgabefehler, mom
[17:59] <ryker> https://paste.debian.net/1267925/
[17:59] <le_bot> Title: debian Pastezone (at paste.debian.net)
[17:59] <tomreyn> dmesg | tail -n50 | nc termbin.com 9999
[18:00] <ryker> https://termbin.com/jzldk
[18:00] <tomreyn> das sieht jetzt stark danach aus dass die usb/sata-übersetzung das problem ist
[18:00] <ryker> ah
[18:00] <tomreyn> oder auch ne kaputte disk
[18:01] <ryker> also ich hatte vor ca. 'ner woche auch folgendes mal gemacht: https://michael.mulqueen.me.uk/2018/03/reading-a-macos-harddisk-on-linux/
[18:01] <tomreyn> es schlägt immer am gleichen sektor fehl
[18:01] <le_bot> Title: Reading a macOS (HFS+) Hard Disk on Linux (at michael.mulqueen.me.uk)
[18:02] <ryker> kurzgesagt, ich hab die platte gemountet
[18:02] <ryker> und konnte die dateien darauf einsehen
[18:02] <ryker> hinterher fiel mir ein, dass ich das nicht hätte tun sollen
[18:02] <ryker> weil jeder zugriff auf die platte das problem ja verschlimmern kann
[18:03] <tomreyn> ^ der ansatz ist richtig, wenn man die vermutung hat, dass die platte physischen kaputt ist. 
[18:03] <tomreyn> *physisch
[18:03] <tomreyn> was hier der fall zu sein scheint
[18:03] <tomreyn> aber das wusstest du ja da eigentlich noch nicht
[18:04] <tomreyn> was du jetzt malchen kannst ist zu versuchen möglichst viele daten mit dd_rescue auszulesen
[18:04] <ryker> 1 ordner hab ich dann (leider) auch direkt auf meinen rechner rüberkopiert
[18:04] <ryker> bei einem anderen gab es eine fehlermeldung, dann hörte ich auf
[18:05] <ryker> dd_rescue, das ist dann nochmal was anderes als der dd-befehl von vorhin, oder?
[18:06] <tomreyn> ja, der versucht daten aus defekten sektoren auszulesen
[18:07] <ryker> dafür gibt es aber kein ubuntu-paket mehr, oder?
[18:07] <ryker> ich meine das auf der ubuntuuseres-seite zu gddrescue gelesen zu haben
[18:07] <tomreyn> sudo apt install gddrescue
[18:07] <ryker> gddrescue hab ich ja bereits
[18:08] <tomreyn> dann hast du auch den ddrescue-befehl
[18:08] <ryker> ok, mom
[18:09] <ryker> ok, hier steht, ich soll zunächst mal ddrescue -n QUELLE ZIEL ddrescue.log machen
[18:10] <ryker> mom
[18:10] <tomreyn> sudo ddrescue f -R /dev/sdc /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.img /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.log
[18:10] <ryker> ah, danke
[18:10] <ryker> ohne -n dann, ja?
[18:10] <tomreyn> sudo ddrescue -f -R /dev/sdc /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.img /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.log
[18:10] <tomreyn> sorry, ich hatte ein - unterschlagen
[18:10] <ryker> oki
[18:10] <tomreyn> moment
[18:11] <ryker> ja?
[18:11] <tomreyn> ja, mach mal das -n noch dazu
[18:11] <ryker> okay
[18:12] <dreamon> -f brauchst nur wenn du 1:1 Kopie machst. Bei Image nicht nötig.
[18:12] <tomreyn> oder die ausgabedatei schon existiert (wie es hier der fall ist)
[18:13] <ryker> ist jetzt schon im gange alles
[18:13] <dreamon> stimmt
[18:14] <ryker> ok, das wird nun etwas zeit in anspruch nehmen
[18:15] <ryker> 2% bis jetzt
[18:15] <tomreyn> ryker: das wird jetzt vermutlich ne weile dauern, weil ddrescue nicht lesbare sektoren wiederholt zu lesen versucht.
[18:15] <tomreyn> :)
[18:15] <ryker> ja, das klingt sehr gut
[18:15] <tomreyn> besser wärs wenn sie lesbar wären
[18:15] <tomreyn> aber man kann ja nicht alles haben ;)
[18:15] <ryker> genau
[18:17] <ryker> dass der dd-befehl  nicht funktioniert, liegt also nun sicher an den nicht lesbaren sektoren (und nicht an einem usb/sata-problem), oder?
[18:20] <dreamon> Wenn das Kabel nicht rausgerutscht ist es meist ein Leseproblem. Ich verwende dd sehr sehr selten, weil ddrescue im Vergleich dir hinschreibt wieviele Errors auftreten. Bis zu dem Zeitpunkt der kopie. 
[18:23] <ryker> ok, also bisher gibt es keine(n) bad-sector / bad areas / read errors
[18:24] <dreamon> Was ist mit der Hdd los? Datenverlust, Langsam, oder Klopfen?
[18:26] <ryker> die stammt aus einem alten mac. ich hatte sie gemountet mit hfsplus und versucht, die dateien rüberzuziehen auf meinen hiesigen ubuntu-laptop, aber das führte zu fehlermeldungen
[18:26] <ryker> ich konnte sie auch nicht überprüfen mit smartctl
[18:27] <ryker> ein leistungstest mit 'laufwerke' ergab: g-io-error-quark, 0
[18:28] <ryker> also gleich zu beginn, der leistungstest konnte also gar nicht durchgeführt werden
[18:29] <dreamon> Hab ich auch schon gemacht, bei einer alten Mac HDD, ist aber schon lange her. Kommt immer drauf an wo sie kaputt ist. ddrescue ist ein super Anfang
[18:31] <dreamon> Kann auch sein, das er beim Kopieren hängen bleibt. Oder die Hdd ausgeht. da tomreyn ein log angelegt hat, kannst das öfters anstossen, er macht dann einfach weiter wo er vorher stehen blieb
[18:33] <ryker> klingt super
[18:35] <nooby23> tomreyn: Hallo! Wir haben vor ein paar Tagen schonmal miteinander geschrieben. Hättest du vllt. kurz Zeit, um mir nochmal mit der Crypttab zu helfen? Hier nochmal der aktuelle Stand: https://paste.debian.net/1267921/
[18:35] <le_bot> Title: debian Pastezone (at paste.debian.net)
[18:36] <nooby23> Ich frage mich jetzt, ob ich in der Crypttab einfach '/dev/mapper/vgkubuntu-root    /mnt' eintragen soll.
[18:38] <dreamon> nooby23, Ohne Garantie: Bei mir steht in der /etc/fstab → /dev/mapper/vgxubuntu-root                /               ext4    errors=remount-ro 0       1
[18:39] <nooby23> dreamon: Ja, aber das ist die fstab, nicht die crypttab. ;)
[18:39] <nooby23> So steht es bei mir in der fstab aber auch.
[18:41] <dreamon> nooby23, In der crypttab ich hab home und nvme0n1p3_crypt drin stehen. Ist aber schon lange her als ich das eingerichtet hab
[18:42] <tomreyn> nooby23: in deinem paste sollte die zeile "sudo cryptsetup luksOpen /dev/sda3 mnt" wahrscheinlich eigentlich "sudo cryptsetup luksOpen /dev/sda3 /mnt" heißen
[18:43] <tomreyn> und die zeile "sudo sudo mount /dev/mapper/vgkubuntu-root /mnt" sollte wohl "sudo mount /dev/mapper/vgkubuntu-root /mnt" heißen
[18:44] <nooby23> Ja. :)
[18:44] <tomreyn> äh, nee, nochmal zur ersten zeile, die soll wohl eher "sudo cryptsetup luksOpen /dev/sda3 sda3_crypt" heißen
[18:45] <tomreyn> und dann ist das problem auch schon gelöst
[18:45] <tomreyn> das sda3_crypt wird ja in der crypttab referenziert
[18:47] <tomreyn> grundsätzlich ist es übrigens immer besser als recovery-/live-boot-system die gleiche version wie beim installierten system zu haben.
[18:47] <tomreyn> dein live-system ist ja ein kubuntu 20.10
[18:47] <tomreyn> (aber wird wahrscheinlich trotzdem klappen)
[18:48] <nooby23> Ahhh. Supi, danke!
[18:48] <tomreyn> ryker: wenn du magst kannst du mit    dmesg -w    in einem anderen terminalfenster das kernellog (und hinweise auf defekte sektoren dort) im auge behalten
[18:53] <tomreyn> sektor 262288 der sdc schien vorhion kaputt zu sein https://termbin.com/jzldk
[18:59] <tomreyn> und 261888 und 266304
[18:59] <ryker> ok, da kommt jetzt gigantisch viel text
[18:59] <tomreyn> und 32786
[19:01] <ryker> es gibt sehr viele critical medium errors, angefangen mit:
[19:01] <ryker> [556984.585666] blk_update_request: critical medium error, dev sdc, sector 266304 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[19:02] <ryker> der bisher letzte:
[19:02] <ryker> [760978.716295] blk_update_request: critical medium error, dev sdc, sector 139367840 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[19:02] <ryker> [760978.716304] Buffer I/O error on dev sdc, logical block 17420980, async page read
[19:04] <nooby23> tomreyn: Hat tatsächlich geklappt. Nun erhalte ich folgende Ausgabe: https://paste.debian.net/1267936/
[19:04] <le_bot> Title: debian Pastezone (at paste.debian.net)
[19:05] <nooby23> Wie gehe ich von hier aus am besten weiter vor?
[19:08] <tomreyn> nooby23: das ist nicht gut "grub-install: Achtung: EFI variables cannot be set on this system." - ist aber kein problem falls grub bisher lud
[19:08] <nooby23> Ja, bis vor dem Update hat alles reibungslos funktioniert.
[19:08] <tomreyn> ggf. hast du das live-system nicht im efi-mode gebootet
[19:08] <tomreyn> echo -n 'This system booted via: '; [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS 
[19:09] <nooby23> 'This system booted via: UEFI'
[19:09] <ryker> weitere fehlerhafte sektoren: 139369600, 139500720, 140570496, 143838608, 143838592, 262288, 266304, 262288 (hier besonders viele fehler), 262240
[19:09] <tomreyn> nooby23: na jut dann liegts wohl an deiner speziellen uefi-firmware.
[19:10] <tomreyn> ryker: sorry das zu hören, aber lass es erst mal fertig machen, mach am besten was anderes in der zwischenzeit, das macht sonst nur traurig.
[19:11] <ryker> ok!
[19:13] <nooby23> Hm. 
[19:18] <nooby23> Kann man die Kiste noch irgendwie retten?
[19:18] <tomreyn> nooby23: was geht denn nicht?
[19:19] <nooby23> Nun ja, ich erhalte jetzt noch immer die gleiche Fehlermeldung wie zu Beginn: 'end kernel panic - not syncing: vfs: unable to mount root fs on unknown-block
[19:20] <tomreyn> obwohl du vorhin nochmal die chroot recovery gemacht und diesmal    "sudo cryptsetup luksOpen /dev/sda3 sda3_crypt"    verwendet hattest?
[19:21] <nooby23> Ja. Alles ist fehlerfrei durchgelaufen, bis zu 'grub-install' und 'update-grub' eben. 
[19:24] <tomreyn> hmm, dann würd ich's nochmal mit ner live-iso probieren die auf die installierte kubuntu-version passt
[19:24] <nooby23> Also neue Version, auf die ich das Update durchgeführt habe? (22)
[19:26] <tomreyn> die fehlermeldung weist darauf hin, dass zwar grub gestartet, die /boot-partition gefunden wurde, und die initrd geladen wurde, aber dann das nach / zu mountende dateisystem ("root-dateisystem" / "root-partition") nicht gefunden oder geöffnet werden konnte
[19:27] <tomreyn> ja 22.04 LTS, falls du darauf upgegradet hast
[19:27] <nooby23> Ah, einen Moment. Kann es sein, dass ich bei 'sudo mount /dev/mapper/vgkubuntu-root     /mnt' statt /mnt auch sda3_crypt einsetzen muss?
[19:30] <tomreyn> nee, /dev/mapper/vgkubuntu-root ist eine LVM2 volume group (daher "vg") namens "vgkubuntu", die enthält u.a. dein nach / zu mountendes dateisystem. diese LVM volume group basiert auf dem physischen volume (PV) /dev/mapper/sda3_crypt - was wiederum auf dem entschlüsselten /dev/sdc3 basiert.
[19:31] <tomreyn> lsblk-ausgabe eines vergliechbaren systems: https://i.stack.imgur.com/BbkFi.png
[19:32] <tomreyn> "vgkubuntu" heißt hier "ubuntu--vg"
[19:32] <tomreyn> hab mich eben vertippt - wo ich "/dev/sdc3" schrieb, meinte ich eigentlich "/dev/sda3"
[19:37] <nooby23> Ok. Ich probiere es mal mit der neuen Live USB aus. Bis später evtl. :)
[19:42] <tomreyn> falls nooby23 nochmal wieder kommt, kann man ihm auch vorschlagen, "break" an die "linux"-zeile in grub anzuhängen und dann die einzelnen schritte des einrichtens der bootumgebung aus der initrd nachzuvollziehen.
[19:44] <tomreyn> ach und bios-update mal machen
[20:30] <nooby23> tomreyn: Jetzt habe ich es mit der 22.04. LTS versucht. Gleiches Ergebnis. Ich frage mich, ob vllt. etwas auf meiner Boot-Partition fehlt. Fällt dir hier etwas auf? https://paste.debian.net/1267945/
[20:30] <le_bot> Title: debian Pastezone (at paste.debian.net)
[20:34] <tomreyn> nooby23: nicht wirklich. das 5.15 initrd ist tierisch groß, aber ich glaube das ist normal mit der standardkompression
[20:36] <tomreyn> du kannst mal probieren, "break" an die "linux"-zeile in grub anzuhängen und dann die einzelnen schritte des einrichtens der bootumgebung aus der initrd nachzuvollziehen.
[20:36] <tomreyn> "break" droppt dich beim boot in die initrd-befehlszeile
[20:37] <tomreyn> und bios-update würd ich mal machen, falls das alt ist
[20:37] <tomreyn> journalctl -b | grep DMI: 
[20:41] <tomreyn> nooby23: und mach mal testweise secureboot und tpm im bios aus
[20:50] <nooby23> Ich probier's aus, danke.
[23:16] <ryker> tomreyn sollte eigentlich schon längst fertig sein, aber läuft immer weiter. momentan sieht es so aus: https://paste.debian.net/1267976/
[23:16] <le_bot> Title: debian Pastezone (at paste.debian.net)
[23:18] <ryker> und im kernellog folgt ein critical medium error auf den anderen
[23:20] <itu> hm
[23:31] <ryker> wenn ich das jetzt abbreche, kann ich den prozess dann morgen an genau der selben stelle fortsetzen?
[23:37] <itu> ist nicht notwendig, nachdem er offenbar schon 5 passes gemacht hat ...
[23:37] <itu> oder zumindest anscheinend ...
[23:38] <itu> wie gross ist denn die ausgabedatei?
[23:39] <itu> cat  /media/godwin/d5c220f8-bd51-4075-a8a6-e292e864572e/image_sdc.log   | nc termbin.com 9999  # wär intressant
[23:39] <ryker> 80 gb
[23:40] <ryker> was macht 'cat'?
[23:41] <itu> eine datei ausgeben .....  
[23:42] <itu> das ist so ziemlich das simpleste tool ... das sollte auch jeder newbie kennen  ...
[23:42] <ryker> https://termbin.com/ggmy
[23:48] <itu> ja, das sind halt offenbar kaputte blocks
[23:48] <itu> ob die nochmal gelesen werden können ist sehr fraglich 
[23:49] <ryker> welcher schritt wäre jetzt sinnvoll? noch abwarten?
[23:50] <itu> noch mal ne weile weiterlaufen lassen und schaun ob sich noch was tut
[23:51] <itu> recherchieren obs vielleicht tricks gibt .. temperatuer oder so ... mit den hammer draufklopfen ... etc  
[23:52] <itu> aufgeben und schaun ob überhaupt was wertvolles verloren ist
[23:52] <ryker> du meinst, "physische tricks"?
[23:52] <itu> jo
[23:54] <ryker> ok, sowas hab ich noch nie gemacht..
[23:55] <ryker> ich wollte jetzt erst mal schlafen gehen und dann morgen weiterschauen. kann ich den jetzt laufenden prozess morgen nochmal weiter laufen lassen?
[23:56] <itu> mach bitte noch mal schnell   smartctl -H
[23:58] <ryker> von /dev/sdc, ja?
[23:58] <itu> smartctl -H   /dev/sdc  # ja
[23:58] <itu> smartctl -H   /dev/sdc   | nc termbin.com 9999
[23:59] <ryker> Smartctl open device: /dev/sdc [SAT] failed: Permission denied