Не удаляется, даже от рута по rm -rf, ошибка типа rm: невозможно удалить '/var/lib/pacman/local/_hren/files': Неправильное сообщение

vall
Любой дистр лайв-образ накатить на флэшку
Намного удобнее поместить в корень этот образ ... и при необходимости грузиться прямо с него ...
У меня лежит на всякий случай 2 образа - archlinux-2020.02.01-x86_64.iso (заменил на новый только вчера) и systemrescuecd-6.0.0.iso
Ошибки не исчезают с опытом - они просто умнеют
Если уже эксперементировать
Если оно нормально переименовалось в _hren может прокатит и
mv /var/lib/pacman/local/_hren /tmp/_hren
?
debugfs -R 'imap /var/lib/pacman/local/_hren/mtree' /dev/sda2
debugfs 1.45.5 (07-Jan-2020)
Inode 420626 is part of block group 51
про образ диска в корень и в груб - спасибо за ценную мысль, как-то опять не додумывался.
нет, в тмп пробовал сразу - не катит, при том, что tmp не в ОЗУ. Перемещается свободно, но не везде (раньше думал, что только внутри /var, но нет, в root тоже пошел.
vs220
Если оно нормально переименовалось в _hren может прокатит и
mv /var/lib/pacman/local/_hren /tmp/_hren
У меня сложилось впечатление, что сама директория /var/lib/pacman/local/_hren нормальная и имеет нормальный свой inode, а вот 2 файла, находящиеся в ней, имеют повреждения/ошибки в системе журналирования файловой системы (не возможно даже получить номер inode этих файлов), а потому вряд ли получится произвести какие либо операции с этими файлами, требующие определенных записей в системе журналирования - ни изменить их содержание, ни переместить их в другое место - для этого требуется найти их записи в системе журналирования и изменить на новые.
Ошибки не исчезают с опытом - они просто умнеют
Конечно бяка в файлах, иначе бы и cd не пускало. Но опыта по работе в системе журналирования у меня нет, ткните пожалуйста носом в инструкцию, желательно на русском.
Пока писал предыдущий пост, пришел ответ wau
wau
debugfs -R 'imap /var/lib/pacman/local/_hren/mtree' /dev/sda2
debugfs 1.45.5 (07-Jan-2020)
Inode 420626 is part of block group 51
В выводе нет строчки, которая определяет расположение блока inode ... в котором записана информация о файле (дата создания/изменения и др.) ... а значит система не может найти данный блок и выполнить соответсвующие действия.
Пример нормального вывода
sudo debugfs -R 'imap /home/vasek/wm' /dev/sda3
debugfs 1.45.5 (07-Jan-2020)
Inode 656780 is part of block group 80
        located at block 2621560, offset 0x0b00
То есть действительно файловая система повреждена.
Можно попробовать посмотреть далее, покажет ли блоки
sudo extundelete –inode 420626 /dev/sda2
не бойся жми y ….
Ошибки не исчезают с опытом - они просто умнеют
extundelete --inode 420626 /dev/sda2
NOTICE: Extended attributes are not restored.
WARNING: EXT3_FEATURE_INCOMPAT_RECOVER is set.
The partition should be unmounted to undelete any files without further data loss.
If the partition is not currently mounted, this message indicates
it was improperly unmounted, and you should run fsck before continuing.
If you decide to continue, extundelete may overwrite some of the deleted
files and make recovering those files impossible. You should unmount the
file system and check it with fsck before using extundelete.
Would you like to continue? (y/n)
y
Loading filesystem metadata ... 158 groups loaded.
Group: 51
extundelete: Inode checksum does not match inode while reading inode.
extundelete: Inode checksum does not match inode while printing inode.
wau
ткните пожалуйста носом в инструкцию, желательно на русском.
Тут одной инструкции нет, нужно просто читать о структуре inode и расположение файла на диске ... собранного в одном месте этого ничего нет. В основном знают те, кто занимается ручным восстановлением файлов.
В части решения проблемы - ничего конкретного сказать не могу - есть надежда, что исправит ситуацию fsck
Ошибки не исчезают с опытом - они просто умнеют
 
Зарегистрироваться или войдите чтобы оставить сообщение.