Puncte:2

Nu se poate repara partiția ext4 după pană de curent, e2fsck continuă să se prăbușească, nu puteți afla ce este în neregulă?

drapel ar

După pană de curent, Ubuntu nu a putut repara ext4 și aruncă aceeași eroare ca mai jos cu e2fsck:

Așa că folosesc cel mai recent SystemRescue LiveCd și încerc să fac manual fsck.

e2fsck /dev/sda2 :

/dev/sda2: jurnal de recuperare
Semnal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x561377ff7000
e2fsck: malloc.c:2539: sysmalloc: Aserțiune `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' a eșuat.
Semnal (6) SIGABRT si_code=SI_TKILL 

tune2fs -l /dev/sda2 :

tune2fs 1.46.4 (18-aug-2021)
Numele volumului sistemului de fișiere: <niciunul>
Ultima montare pe: /
UUID sistemului de fișiere: 787f0a6f-7d49-409d-80b7-5e4416d5a2bb
Numărul magic al sistemului de fișiere: 0xEF53
Revizia sistemului de fișiere #: 1 (dinamic)
Caracteristici ale sistemului de fișiere: has_journal ext_attr resize_inode dir_index fast_commit tip de fișier need_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Steaguri de sistem de fișiere: signed_directory_hash 
Opțiuni de montare implicite: user_xattr acl
Starea sistemului de fișiere: curățați cu erori
Comportamentul erorilor: Continuați
Tipul sistemului de fișiere OS: Linux
Număr de inoduri: 30236672
Număr de blocuri: 120925696
Număr de blocuri rezervate: 6046284
Blocuri gratuite: 16403757
Inoduri gratuite: 29241790
Primul bloc: 0
Dimensiune bloc: 4096
Dimensiunea fragmentului: 4096
Blocuri GDT rezervate: 995
Blocuri pe grup: 32768
Fragmente pe grup: 32768
Inode pe grup: 8192
Blocuri de inoduri per grup: 512
Dimensiunea grupului de blocuri flexibile: 16
Sistem de fișiere creat: Lun 2 Apr 12:16:18 2018
Ultima montare: Luni, 8 noiembrie 10:55:03 2021
Ultima oră de scris: Luni, 8 noiembrie 14:02:43 2021
Număr de monturi: 2
Număr maxim de monturi: -1
Ultima verificare: Luni, 8 noiembrie 10:51:38 2021
Interval de verificare: 0 (<niciun>)
Scrieri pe viață: 13 TB
Uid blocuri rezervate: 0 (rădăcină utilizator)
Blocuri rezervate gid: 0 (rădăcină de grup)
Primul inod: 11
Dimensiunea inodului: 256
Mărimea suplimentară necesară: 28
Dimensiunea suplimentară dorită: 28
Inodul jurnalului: 8
Primul inode orfan: 27918882
Hash implicit al directorului: half_md4
Director Hash Seed: efb4ad95-8a43-42bc-a03b-0849ccae2ef7
Backup jurnal: blocuri inode

mount /dev/sda2 /mnt:

mount: /mnt: nu pot citi superblock pe /dev/sda2.

mke2fs -n /dev/sda2 :

mke2fs 1.46.4 (18-auug-2021)
/dev/sda2 conține un sistem de fișiere ext4
    Ultima montare pe / pe Luni Nov 8 10:55:03 2021
Continua oricum? (y,N) y
Crearea unui sistem de fișiere cu 120925696 blocuri 4k și 30236672 inoduri
UUID sistemului de fișiere: 331dfa9a-1bae-44bf-b4a2-4c75d7a8aab2
Copii de rezervă Superblock stocate pe blocuri: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
    102400000

e2fsck -b 32768 /dev/sda2 :

e2fsck 1.46.4 (18-aug-2021)
Indicatorul Superblock needs_recovery este clar, dar jurnalul are date.
Indicatorul de recuperare nu este setat în superblock de rezervă, deci rulează jurnalul oricum.
/dev/sda2: jurnal de recuperare
Semnal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x55657e320000
e2fsck(+0x35133)[0x55657d929133]
/usr/lib/libpthread.so.0(+0x13870)[0x7fb669365870]
e2fsck(+0x27c10)[0x55657d91bc10]
e2fsck(+0x28480)[0x55657d91c480]
e2fsck(+0x309c4)[0x55657d9249c4]
e2fsck(jbd2_journal_recover+0xd7)[0x55657d9251a7]
e2fsck(e2fsck_run_ext3_journal+0x2d1)[0x55657d91e871]
e2fsck(principal+0x1d75)[0x55657d903de5]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7fb6691adb25]
e2fsck(_start+0x2e)[0x55657d90591e]

e2fsck -b 98304 /dev/sda2:

e2fsck 1.46.4 (18-aug-2021)
Indicatorul Superblock needs_recovery este clar, dar jurnalul are date.
Indicatorul de recuperare nu este setat în superblock de rezervă, deci rulează jurnalul oricum.
/dev/sda2: jurnal de recuperare
Semnal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x563839a50000
e2fsck(+0x35133)[0x563838e06133]
/usr/lib/libpthread.so.0(+0x13870)[0x7f671f521870]
e2fsck(+0x27c10)[0x563838df8c10]
e2fsck(+0x28480)[0x563838df9480]
e2fsck(+0x309c4)[0x563838e019c4]
e2fsck(jbd2_journal_recover+0xd7)[0x563838e021a7]
e2fsck(e2fsck_run_ext3_journal+0x2d1)[0x563838dfb871]
e2fsck(principal+0x1d75)[0x563838de0de5]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7f671f369b25]
e2fsck(_start+0x2e)[0x563838de291e]

e2fsck -C0 -p -f -v /dev/sda2 :

/dev/sda2: jurnal de recuperare
Semnal (11) SIGSEGV si_code=SEGV_MAPERR fault addr=0x555ae23f5000
e2fsck(+0x35133)[0x555ae03cd133]
/usr/lib/libpthread.so.0(+0x13870)[0x7efe927b8870]
e2fsck(+0x27c10)[0x555ae03bfc10]
e2fsck(+0x28480)[0x555ae03c0480]
e2fsck(+0x309c4)[0x555ae03c89c4]
e2fsck(jbd2_journal_recover+0xd7)[0x555ae03c91a7]
e2fsck(e2fsck_run_ext3_journal+0x2d1)[0x555ae03c2871]
e2fsck(principal+0x1d75)[0x555ae03a7de5]
/usr/lib/libc.so.6(__libc_start_main+0xd5)[0x7efe92600b25]
e2fsck(_start+0x2e)[0x555ae03a991e]

smartctl -H /dev/sda2:

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.70-1-lts] (build local)
Drepturi de autor (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== ÎNCEPEREA SECȚIUNII DE CITIRE DE DATE INTELIGENTE ===
Rezultatul testului de autoevaluare a sănătății generale SMART: A TRUS
sudodus avatar
drapel jp
Există date unice importante pe unitate, pe care trebuie să le recuperați? Sau ați fi fericit dacă puteți goli tabelul de partiții, creați unul nou, creați partiții și sisteme de fișiere și restaurați datele din backup?
drapel ar
Da, am câteva date importante. Dar sunt doar interesat, ce este în neregulă și de ce fsck/e2fsck continuă să se prăbușească.
sudodus avatar
drapel jp
Nu pot spune ce este în neregulă, dar există instrumente de la https://cgsecurity.org, care ar putea funcționa, când fsck/e2fsck continuă să se prăbușească. Dacă date sunt foarte importante, clonați întreaga unitate pe o altă unitate de cel puțin aceeași dimensiune și efectuați lucrări de recuperare a copiei clonate. Încercați mai întâi `testdisk`, iar dacă nu funcționează, `photorec`, care poate recupera datele fără niciun sistem de fișiere, atâta timp cât datele fișierului sunt încă acolo. Dar este multă muncă, iar numele fișierelor și structura directoarelor se pierd.
drapel ar
Fișierele par „intact” pe partiție, folosind testdisk, așa că poate încerc să copiez de acolo.
sudodus avatar
drapel jp
Anunțați-ne rezultatul. Noroc :-)
Puncte:1
drapel ar

Am creat o problemă pe github și un tip drăguț (harshadjs) m-a ajutat să remediez această problemă, scriind patch-uri pentru aplicație. Se pare că a fost ceva în neregulă e2fsprogs și fast_commit caracteristică în ext4. Se poate urmări aici.

Concluzia este că nu vă încurcați cu caracteristicile sistemului de fișiere, când sursa de alimentare este instabilă și nu știți cum să o remediați singur.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.