[11:45] <nooby23> Guten Tag! Ich habe nach dem Upgrade auf die neue Ubuntu-Version ein Problem beim Hochfahren und wollte fragen, ob Sie mir vielleicht helfen können. Es erscheint die Fehlermeldung: "Not Syncing: VFS: Unable to Mount Root FS on Unknown-Block(0,0)" Normalerweise wird das Problem gelöst, indem man das System mit einem älteren Kernel bootet und dann ein Update von initramfs  durchführt, aber ich erhalte die gleiche 
[11:45] <nooby23> Fehlermeldung auch beim Start mit besagtem älteren Kernel und kann derzeit nur mit einer Live USB an meinem Rechner arbeiten. 
[11:46] <nooby23> Lässt sich das Problem dennoch lösen?
[11:49] <tomreyn> hi nooby23
[11:50] <tomreyn> wir sagen hier am liebsten "du". gib mir mnen moment, muss mal eben drüber lesen
[11:53] <nooby23> Ok
[11:53] <tomreyn> hmm, also diese fehlermeldung kann mehre ursachen haben. mitunter sieht man die dann wenn alte festplatten ihren geist aufgeben. wenn sie regelmäßig auftritt dann ist eher das dateisystem, auf dem das verzeichnis /boot liegt, voll gelaufen. so dass kernel und initrd nicht korrekt installiert / generiert / geschrieben werden konnten
[11:54] <tomreyn> das würde ich mal prüfen
[11:55] <tomreyn> du wist vermutlich nicht drum rum kommen, dass du eine live usb/cdrom recovery des systems machen musst, um das system zu fixen.
[11:56] <tomreyn> https://help.ubuntu.com/community/LiveCdRecovery
[11:56] <le_bot> Title: LiveCdRecovery - Community Help Wiki (at help.ubuntu.com)
[11:57] <tomreyn> oder auf deutsch: https://wiki.ubuntuusers.de/GRUB_2/Reparatur/#Reparatur-mittels-Desktop-CD
[11:57] <le_bot> Title: Reparatur › GRUB 2 › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[11:57] <nooby23> Die Problematik mit dem vollen Boot-Verzeichnis ist mir bekannt, deshalb hatte ich vor dem Update auch etliche ältere Kernel per apt-get remove entfernt. Jetzt sind auf der Boot-Partition von 700MB noch knapp 350MB frei. Müsste das nicht eigentlich ausreichen?
[11:58] <nooby23> Es sind auch nur noch zwei Kernel drinnen, viel mehr kann ich also gar nicht entfernen.
[11:59] <tomreyn> das müsste reichen, ja. wenn denn einer der installierten kernel + initrds nicht kaputt ist.
[11:59] <tomreyn> welche ubuntu-version hast du denn da?
[12:00] <nooby23> Ich habe das Update von 20.4 auf die neuste Version durchgeführt (22.x).
[12:06] <tomreyn> nooby23: mit neueren ubuntu-versionen brauchen die kernel und initrd's leider immer mehr platz. man kann aber eine größere boot-partition erstellen oder ein anderes komprimierungsverfahren für die initrd nehmen, das kann beides helfen
[12:06] <tomreyn> letzteres konfiguriert man in /etc/initramfs-tools/initramfs.conf
[12:07] <tomreyn> in beiden fällen musst du aber erst mal die recovery durchführen
[12:10] <nooby23> Ja, aber ich würde nur ungerne eine ganze Neuinstallation durchführen. Das Problem scheint ja an sich nur eine falsche Konfiguration o.ä. zu sein. :/
[12:12] <nooby23> Hm. Auf 
[12:12] <nooby23> sudo mount /dev/sda3 /mnt 
[12:12] <nooby23> mount: /mnt: unknown filesystem type 'crypto_LUKS'.
[12:12] <tomreyn> eine ubuntu-neuinstallation ist nicht nötig, aber ein erneutes generieren der initrd ist wahrscheinlich nötig.
[12:13] <tomreyn> die meldung mit dem hinweis auf "crypto_LUKS" weist darauf hin, dass du ein verschlüsseltes root-dateisystem hast (das dateisystem, das nach "/" eingebunden wird)
[12:14] <nooby23> Entschuldigung. Auf sudo mount /dev/sda3 /mnt erhalte ich die Fehlermeldung mount: /mnt: unknown filesystem type 'crypto_LUKS'. Meine Festplatte ist prizipielle verschlüsselt, aber ich habe sie bereits über Nautilus entschlüsselt. Muss ich da noch etwas anderes beim einbinden beachten?
[12:14] <tomreyn> du wist es mit dem befehl    cryptsetup luksOpen    aktivierne müssen
[12:15] <tomreyn> wenn du schon über nautilus entschlüsselt hast dann solltest du statt dessen das entsprechende dateisystem das darin enthalten ist mounten
[12:15] <tomreyn> irgendwas unterhalb von /dev/mapper
[12:16] <tomreyn> wobei das dann per default auch noch lvm-strukturen enthält, die du ggf. auch noch aktivieren musst, falls gnome das nicht schon gemacht hat.
[12:24] <nooby23> Tatsächlich, das Dateisystem befindet sich in /dev/mapper. Nun ist es also gemountet. Dito die Boot-Parition, die hatte ich separat angelegt. Sind nun auch die Bedinungen für den Wechsel in die chroot-Umgebung geschaffen? Ich bin im Moment bei Punkt drei des zweiten Links, den du gepostet hast.
[12:24] <tomreyn> nooby23: kannst du sagen was du alles wohin gemountet hast?
[12:25] <tomreyn> nur das was nicht in auf ubuntuusers aufgelistet ist
[12:26] <tomreyn> ich wollte sagen: nur das was nicht auf dem ubuntuusers wiki aufgelistet ist
[12:27] <nooby23> "Hauptpartition" und Boot-Partition in /media/kubuntu.
[12:28] <nooby23> Ich bin an einem Kubuntu Live USB.
[12:29] <tomreyn> na dann müsste das klappen
[12:30] <tomreyn>  /media/kubuntu sind allerdings schon einhängepunkte, da müsstest du dann nen bind mount machen
[12:38] <nooby23> Bis 3.3 hat es schon einmal funktioniert. Nun bin ich bei Punkt 3.4: sudo cp /proc/mounts  /mnt/etc/mtab. Hier erhalte ich die Fehlermeldung "invalid argument". Die beiden Dateien (mounts & mtab) existieren aber, beide auch in den richtigen Ordnern. 
[12:39] <nooby23> Könnte es vielleicht an fehlendem Schreibzugriff liegen?
[12:41] <tomreyn> das verzeichnis /mnt/etc/ sollte eigentlich schriebbar gemountet sein, es sei denn etwas anderes wurde gesagt
[12:41] <tomreyn> der befehl "mount" zeigt wir, was derzeit in welchem modus (schriebbar/nur lesen) gemountet ist
[12:43] <tomreyn> hinweise dazu, wie die verschlüsselten dateisysteme gemountet werden müssen sind in der zweiten "extperten-info"-box auf dieser seite zu fnden
[12:44] <tomreyn> mehr dazu auch in der ersten experten-box hier: https://wiki.ubuntuusers.de/chroot/Live-CD/#Einrichtung
[12:44] <le_bot> Title: Live-CD › chroot › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[12:45] <tomreyn> nooby23: ^ das hat ein paar mehr details
[12:48] <tomreyn> ich würde empfehlen, nichts mit nautilus zu mounten sondern das ausschließlich über den terminal zu machen
[12:51] <nooby23> Hm, laut Terminal müsste ich rw haben, also Lese- und Schreibzugriff. Oder sehe ich das falsch? Ausschnitt hier: https://pastebin.com/aUdUQn90
[12:51] <le_bot> Title: /dev/mapper/vgkubuntu-root on /media/kubuntu/38559ef6-7e11-4b53-b9b9-a83875e6364 - Pastebin.com (at pastebin.com)
[12:55] <tomreyn> nooby23: ja, /media/kubuntu/38559ef6-7e11-4b53-b9b9-a83875e63643 ist schreibbar gemountet. nicht gemountet sind bisher /dev/pts und /run
[12:55] <tomreyn> nooby23: ich würde empfehlen nochmal neu anzufangen (reboot) und streng nach der anleitung zu gehen, ohne nautilus-mounts zu verwenden
[12:56] <tomreyn> falls nautilus schon was nach /media gemountet hat, das dann erst entmounten bevor du beginnst
[12:59] <nooby23> Ok ich probiere es noch einmal. Bis später.
[14:25] <Daniel64> Hallo, ist hier vielleicht jemand der einen Tipp bzgl. der Einrichtung evon User Units geben kann?
[14:40] <nooby23> tomreyn: Hallo, ich bin es noch einmal. Habe den Rechner herunergefahren und das Live USB neu gestartet. Zunächst habe ich die Festplatte mit "sudo cryptsetup luksOpen /dev/sda3 mnt" und dem Paswort entschlüsselt. Auch danach bin ich der Anleitung gefolgt. Leider hänge ich aber wieder am gleichen Punkt. :/
[14:41] <nooby23> Siehe auch: https://pastebin.com/2DsgS4pQ
[14:41] <le_bot> Title: kubuntu@kubuntu:/dev/mapper$ sudo mount /dev/mapper/vgkubuntu-root /mnt %im nä - Pastebin.com (at pastebin.com)
[16:02] <strohalm> ist /mnt und /mnt/etc sauber gemountet und da was drin?
[16:06] <nooby23> Ich habe zumindest keine Fehlermeldung erhalten. Was ich mich jetzt frage ist, ob mein Rechner doch mit UEFI läuft. Der Ordner /sys/firmware/efi existiert auf der Festplatte, also wird es wahrscheinlich schon so sein, oder? Wie kann ich das überprüfen?
[16:07] <strohalm> zeigt efibootmgr was
[16:08] <nooby23> Ja, siehe https://pastebin.com/K2y58ANz.
[16:09] <strohalm> ja ich würd sagen das ist efi
[16:09] <nooby23> Aber auf dem Rechner läuft ja gerade ein Live USB.
[16:09] <strohalm> hast du keien efi partition?
[16:10] <nooby23> In der KDE-Partitionsverwaltung steht davon nichts.
[16:16] <nooby23> Lt. https://wiki.ubuntuusers.de/GRUB_2/Reparatur/ müsste die dann mit sudo mount /dev/sdXY /mnt/boot/efi eingehängt werden. Wäre sdXY dann hier die vgkubuntu-root?
[16:16] <le_bot> Title: Reparatur › GRUB 2 › Wiki › ubuntuusers.de (at wiki.ubuntuusers.de)
[16:18] <strohalm> ne, ne efi partition ist immer außerhalb des vom cryptvolume/lvm
[16:18] <nooby23> Also das ist ja der eigentlich der Einhängepunkt, aber sda3 geht schonmal nicht: mount: /mnt/boot/efi: unknown filesystem type 'crypto_LUKS'.
[16:18] <strohalm> die hat auch so lustige GPT Flags wie esp 
[16:23] <tomreyn> nooby23: die meldung "unknown filesystem type 'crypto_LUKS'" hattest du vorhin auch. diese meldung weist darauf hin, dass diese partition ien verschlüsseltes dateisystem enthält -> cryptsetup luksOpen /dev/sda3      verwenden, dann die in LVM2 logical volumes eingebetteten dateisysteme von /dev/mapper/vg... mounten
[16:24] <tomreyn> nooby23: wichtig ist, dass du das live-system im gleichen modus (uefi oder klassischer bios boot) bootest wie das installierte system.
[16:26] <tomreyn> wenn es auf der festplatten-/ssd-installation keine (unverschlüsselte) partition mit nem efi-dateisystem drin gibt (meistens ~ 200-500 *mega*bytes groß, also sehr klein), dann wurde das offenbar bisher im klassichen bios-modus gebootet
[16:27] <nooby23> So habe ich das ja auch gemacht, s.o. Entschlüsselt wie in der Anleitung vorgegeben und dann die weiteren Schritte, bis zu dieser cp-Sache. 
[16:27] <nooby23> Oder habe ich etwas übersehen?
[16:31] <tomreyn> nooby23: https://pastebin.com/2DsgS4pQ sieht eigentlich gut aus. die fehlermeldung stellt mich vor ein rätsel
[16:31] <le_bot> Title: kubuntu@kubuntu:/dev/mapper$ sudo mount /dev/mapper/vgkubuntu-root /mnt %im nä - Pastebin.com (at pastebin.com)
[16:32] <tomreyn> zeigt denn /mnt/etc/ an, was es sollte, also den inhalt eines üblichen /etc-verzeichnisses (kannst du mit dem des live-systems vergleichen, sollte so ähnlich sein)
[16:33] <tomreyn>    ls -l /mnt/etc/     meinte ich
[16:36] <nooby23> Nein, die merkwürdigerweise leer. :/
[16:37] <tomreyn> und    ls -l /    ?
[16:37] <nooby23> total 0
[16:37] <tomreyn> äääh    ls -l /mnt    meinte ich
[16:38] <nooby23> bash: ls-l/mnt: No such file or directory
[16:38] <tomreyn> scheint als ob du ein paar leerzeichen verloren hast
[16:39] <tomreyn> sind in /mnt nur die von dir rein gemounteten dateisysteme drin oder auch die üblichen wie /var und /usr und /lib ?
[16:40] <nooby23> Sorry
[16:40] <nooby23> https://pastebin.com/pyXMe5YE
[16:40] <le_bot> Title: kubuntu@kubuntu:/mnt/mnt$ ls -l /mnttotal 92lrwxrwxrwx 1 root root 7 F - Pastebin.com (at pastebin.com)
[16:40] <nooby23> Sind da.
[16:42] <tomreyn> nooby23: das etc-unterverzeichnis dort sscheint aber nicht leer zu sein
[16:43] <tomreyn> sicher, dass da nichts drin ist?
[16:44] <tomreyn> moment, wieso hast du /mnt/mnt?
[16:46] <tomreyn> das arbeitsverzeichnis in dem du dich befandest, als du das gepostet hattest war /mnt/mnt: https://pastebin.com/pyXMe5YE
[16:46] <le_bot> Title: kubuntu@kubuntu:/mnt/mnt$ ls -l /mnttotal 92lrwxrwxrwx 1 root root 7 F - Pastebin.com (at pastebin.com)
[16:53] <nooby23> Ah, entschuldige, das war ein Irrtum.
[16:53] <nooby23> Ja, das etc-Verzeichnis ist nicht leer. Die Datei mtab ist auch drin.
[16:53] <nooby23> lrwxrwxrwx  1 root root       19 Feb  7  2020 mtab -> ../proc/self/mounts
[16:57] <tomreyn> hmm, ich bin unsicher ob das so sein soll, aber könnte funktionieren. jedenfalls viel besser als eben
[16:58] <nooby23> Also einfach mit dem nächsten Schritt weiter?
[16:58] <tomreyn> ah, jetzt versteh ich dann auch die fehlermeldung.
[16:59] <tomreyn> ja, den fehler wegen mtab kannst du einfach ignorieren denke ich
[17:00] <nooby23> Was ist denn der Grund für die Fehlermeldung? 
[17:01] <tomreyn> dass am ziel der kopie bereits eine symbolische Verküpfung existiert, die nach ../proc/self/mounts verweist.
[17:02] <nooby23> Ah, ok.
[17:02] <tomreyn> ...was zu dem zeitpunkt an der stelle noch nicht existiert
[17:02] <nooby23> Ich probier's nochmal, bis gleich.
[17:19] <nooby23> Sodele. Jetzt bin ich beim Befehl "grub-install /dev/sdX". 
[17:20] <nooby23> Frage: Muss da wirklich /dev/mapper/vgkubuntu-root rein, nicht /mnt/boot/grub? 
[17:21] <tomreyn> vermutlich weder noch sondern /dev/sdc
[17:22] <tomreyn> bzw. an sich brauchst du das ziel gar nicht angeben wenn du da ne efi-installation hast
[17:22] <nooby23> Ich hab keine EFI, glaube ich. 
[17:22] <tomreyn> ist denn /mnt/boot/efi gemountet und da ist ein EFI-unterverzeichnis drin?
[17:23] <tomreyn> ah legacy bios, okay, und das livesystem hast du auch ohne efi gebootet?
[17:23] <tomreyn> echo -n 'This system booted via: '; [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS 
[17:25] <nooby23> Ja, es gibt ein EFI-Verzeichnis in /mnt/boot/efi, aber das ist leer.
[17:25] <nooby23> Ne, das Livesystem mit uefi. Kann man das auch ohne starten?
[17:27] <tomreyn> wenn deine systemfirmware es kann, ja
[17:28] <tomreyn> ein leeres /mnt/boot/efi, das bereits existierte, weist aber darauf hin, dass dein installiertes system doch mit efi gebootet wird und du noch die efi-partition finden und dorthin mounten musst
[17:28] <nooby23> Hm. Und wie finde ich die?
[17:31] <tomreyn> es wird eine der 200-500 MB großen partitionen auf dev/sdc sein
[17:31] <tomreyn> es wird eine der 200-500 MB großen partitionen auf /dev/sdc sein
[17:31] <tomreyn> von denen gibt es vermutlich maximal zwei
[17:32] <tomreyn> außerdem ist es vermutlich die einzige partition, die ein fat-dateisystem enthält
[17:35] <nooby23> Ok, ich probier's aus. Bis gleich.
[17:54] <nooby23> Es hat nicht funktioniert, noch immer die gleiche Fehlermeldung. Scheinbar ist der symbolische Link die Schwachstelle.
[17:55] <nooby23> Kann ich den einfach entfernen und es dann nochmal probieren?
[17:56] <tomreyn> du kannst den entfernen (rm) und dann cen cp-befehl ausführen
[17:56] <tomreyn> *den
[18:05] <nooby23> Dieses mal ist alles ohne Fehlermeldung durchgegangen, aber es kommt noch immer die gleiche Fehlermeldung. :/
[18:07] <tomreyn> nooby23: sobald du im chroot bist solltest du auch die initrd neu generieren, hattest du das gemacht?
[18:08] <tomreyn> sudo update-initramfs -k all -c
[18:08] <nooby23> Oha, das habe ich nicht. Wann mache ich das? Nach all den anderen Schritten, bevor ich den chroot verlasse?
[18:09] <tomreyn> nach schritt 3, also sobald du im chroot bist
[18:10] <tomreyn> dann nochmal gucken ob /boot richtig aussieht (initrds und kernel drin, jeweils ähnliche dateigröße)
[18:11] <tomreyn> dann noch schauen ob die /etc/crypttab richtig aussieht (existiert das target-device und ist das in der tat die root-partition?)
[18:11] <tomreyn> dann noch die /etc/fstab prüfen (alle dateisysteme drin, pfade / UUIDs korrekt?) und dann nochmal update-grub ausführen
[18:12] <nooby23> Tatsächlich, hier kommt die Fehlermeldung:
[18:12] <nooby23> update-initramfs: Generating /boot/initrd.img-5.4.0-137-generic
[18:12] <nooby23> cryptsetup: WARNING: target 'mnt' not found in /etc/crypttab
[18:13] <nooby23> Die Datei enthält nur eine Zeile: sda3_crypt UUID=d1f7746e-2101-4553-bfbd-697d740522ad none luks,discard
[18:18] <nooby23> Das gucke ich mir morgen an. Genug für heute. ;) Vielen vielen lieben Dank schonmal für die großartige Hilfe. Bis hierhin hätte ich es sonst nicht geschafft. :)
[18:18] <nooby23> Schönes (Rest-)Wochende noch!