Ce s-a întâmplat:
Am folosit un program cu un selector de fișiere GUI foarte prost și, în timp ce încercam să traversez sistemul de fișiere, am apăsat accidental butonul „înapoi” de pe partea laterală a mouse-ului, care aparent a acționat ca un clic obișnuit din stânga al mouse-ului care m-a determinat să mișc un folder sus în sistemul de fișiere într-un alt folder. Am mutat fie un folder de la rădăcină într-un alt subdosar de rădăcină (de exemplu, mutat /A în /B) sau un folder dintr-un subdosar de la rădăcină într-un sub-subdosar (de exemplu, mutat /A/B în /A/C). Îmi amintesc, de asemenea, că această greșeală s-a întâmplat probabil lângă sau în /usr pliant.
Problemă:
Imediat după această greșeală, toate pictogramele din Gnome au dispărut (deși aplicațiile pe care le-am deschis păreau să funcționeze bine) și, pe măsură ce am încercat să deschid un shell pentru a încerca să-mi anulez greșeala, nu s-a mai deschis (animația de clic a fost redată, dar nicio fereastră deschisă). Am repornit sistemul și după un perete de text care a fost prea rapid pentru mine să-l citesc (era un perete de text tipic în stilul unei liste de verificare) am fost întâmpinat cu un text alb pe fundal negru, care citi:
/dev/nvme0n1p5: jurnal de recuperare
/dev/nvme0n1p5: curat, 897720/12004096 fișiere, 21338613/51200000
Am așteptat ceva timp, dar nu s-a întâmplat nimic după aceea.
Ce am încercat până acum (folosind shell-ul rădăcină de recuperare Grub):
Mi-am comparat / folderul cu cel menționat pe site-ul oficial Ubuntu: https://help.ubuntu.com/lts/installation-guide/armhf/apcs02.html. Dosarul meu rădăcină este un superset al tuturor folderelor menționate pe site-ul respectiv. Mai exact, acesta contine:
bin, boot, cdrom, dev, etc, acasă, lib, lib32, lib64, libx32, lost+found, mass-media, mnt, opt, proc, root, rula, sbin, snap, srv, swapfile, sys, tmp, usr, var
Ale mele /usr folderul contine: bin, jocuri, includ, lib, lib32, lin64, libexec, libx32, local, sbin, src
Am încercat să aflu ce foldere au fost editate aproximativ în același timp cu eroarea. Pentru asta am executat ls -l și, din păcate, niciun folder nu părea să aibă un timp care să se potrivească cu cel al greșelii.
Am citit pe net, majoritatea oamenilor recomandă să deschidă cumva (modul Grub Recovery sau prin Live-CD) un shell rădăcină și apoi să facă: fsck -f /. Postările respective încearcă să repare și jurnal de recuperare problemă, dar a lor a fost cauzată de ex. o întrerupere de curent care provoacă coruperea fișierelor. M-am abținut să încerc asta, deoarece nu cred că sistemul de fișiere de bază este stricat, doar am mutat un folder în locul greșit.
Întrebare:
Cum să procedez? Dacă aș putea afla ce folder am mutat, mi-aș putea întoarce cu ușurință greșeala
Actualizare 1:
Informatii despre sistem:
Distro: Ubuntu 20.4.?. Din păcate, alergând lsb_release în modul de recuperare dă a ModuleNotFound eroare, cu traceback care se termină în apt_pkg.Eroare: E: Eroare la citirea tabelului CPU, așa că nu vă pot spune care versiune exactă.
Nucleu: 5.4.0-81-generic
am fugit fsck -f /dev/nvme0n1p5 de pe o unitate USB, așa cum s-a sugerat, care a produs următoarea ieșire:
ubuntu@ubuntu:~$ sudo fsck -f /dev/nvme0n1p5
fsck de la util-linux 2.34
e2fsck 1.45.5 (07-ian-2020)
Pasul 1: Verificarea inodurilor, blocurilor și dimensiunilor
Pasul 2: Verificarea structurii directoarelor
Pasul 3: Verificarea conectivității directorului
Pasul 4: Verificarea numărului de referințe
Pasul 5: Verificarea informațiilor rezumate ale grupului
/dev/nvme0n1p5: 897720/12804096 fișiere (0,4% necontigue), 21338886/51200000 blocuri
Rețineți că numărul de fișiere și blocuri verificate este exact același cu cel din imprimarea pe care o primesc doar când pornesc direct în Ubuntu
