При изменении размера раздела внутри gparted live ядро столкнулось с GPF, что заставило меня перезагрузить машину. (dmesg здесьhttps://pastebin.com/LGqXA3p9). Так уж получилось, что перемещаемый раздел находился на массиве md RAID5 и не имел никакого отношения к загрузке системы, а это значит, что я снова в рабочем состоянии и могу еще немного поковыряться.
Запуск dumpef2s выдает «dumpe2fs: Corrupt extend header while reading journal super block», а fsck.ext4 сообщает «Superblock has an invalid journal (inode 8)». Я еще не очистил его. testdisk видит только новый раздел и ни одного из файлов; Photorec будет больше хлопот, чем пользы. Testdisk показывает только наполовину перемещенный файл и ничего больше.
Последнее сообщение от инструмента resize2fs было "node 279256 / 593596231", которое я не уверен, как интерпретировать. Есть ли способ получить доступ к неперемещенным данным файловой системы?
решение1
После того, как я покопался под поверхностью, мне повезло — (фирменный) инструмент под названием r-studio нашел суперблок файловой системы — e2image еще не перезаписал исходную файловую систему. Вооружившись номерами секторов, я смог просто воссоздать старый раздел, не обнаружив никакой потери данных. Я пытался выполнить grep по всему тому в поисках UUID, который у меня все еще был, что было примерно тем же подходом, но сделано вручную по сравнению с вышеупомянутым инструментом. Излишне говорить, что я сделал резервные копии метаданных файловой системы с помощью e2image и буду выяснять, почему gparted не сработал.