После нечистого выключения на устройстве с SD-картой я вынул SD-карту fsckв корневую файловую систему. Это привело к различиям в следующем:
e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2
Здесь я отвечал «нет» оба раза, но нет последовательности да / нет, которая не сразу приводит к одному и тому же результату.
Файловая система может быть смонтирована, и при случайном осмотре все в порядке; он также отлично работает на устройстве, и это корневая файловая система (на самом деле она оказалась не совсем хорошей, см. комментарии; tldr некоторые безвозвратно поврежденные каталоги).
Я ddсделал раздел (8 ГБ) в файл, и попытался fsck на этом. Что интересно:
e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108)
Setting free inodes count to 406127 (was 408580)
Setting free blocks count to 1305622 (was 1347486)
plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)
Последующее, fsckпрошедшее очистку, изображение может быть смонтировано, а fsck -fпосле этого также проходит.
Но файловая система на карте, из которой был создан необработанный образ блочной копии, все еще имеет ту же проблему - за исключением того, systemd-fsckчто во время загрузки регистрирует файловую систему как «чистую». Впоследствии, однако, правильное завершение работы, извлечение карты и повторная попытка fsckиз другого окна представляет ту же ошибку.
Всякий раз, когда оригинал монтируется на другом компьютере, примечания системного журнала:
kernel: EXT4-fs (sdc2): 4 orphan inodes deleted
kernel: EXT4-fs (sdc2): recovery complete
Так как у меня есть все резервные копии, я готов попробовать что угодно здесь. Я мог бы просто забыть об этом и перезаписать раздел из по-видимому фиксированного образа, но это не кажется очень удовлетворительным решением, так как это означает, что fsck загадочно потерпел неудачу в решении незначительной проблемы.
Я подозреваю, что это превратится в вопрос «запрос официальной документации», касающийся таких вещей, как необходимость в recovery_flag (или просто вопрос «Что это значит?»), Поэтому любые предложения в этом направлении приветствуются.
apt upgrade). После этого он регистрирует нормальную загрузку - и systemd-fsck говорит «clean» (я это отредактирую), но попытка fsck вне этого контекста все равно не удалась.Ответы:
Я просто столкнулся с этой же проблемой. После устранения проблемы с
e2fsckсопровождающим, мы поняли, что SD-карта сломалась. Он принимал записи без ошибок, но фактически не записывал данные на карту. SD-карта была эффективно только для чтения.Кажется, карта перешла в какой-то безотказный режим, где данные еще можно было прочитать, но ничего не записать.
Это
e2fsckсообщениеunable to set superblock flagsозначает, что оно попыталось записать в суперблок, чтобы пометить журнал как обработанный, что произошло без ошибок, но когда он снова начал читать суперблок, он все же указал, что журнал необходимо воспроизвести. Другими словами, изменения, записанные в суперблок, не были сохранены на носителе данных.Я использую карту с этой проблемой - Samsung Evo 16GB microSD, о которой я упомяну на всякий случай, если это обычная проблема с этими картами.
Я смог проверить это с помощью
ddзаписи 4096 байт/dev/zeroна карту в блоке 0, затем я прочитал обратно с карты и вместо того, чтобы получить все нули, как я должен, я все еще получил исходный неизмененный суперблок ext4.Сейчас я нахожусь в процессе переноса данных на новую карту, а затем выясняю, могу ли я получить замену у Samsung, который, похоже, предлагает 10-летнюю гарантию на SD-карты.
ОБНОВЛЕНИЕ: Samsung заменил 16-ГБ карту на 32 ГБ в той же серии Evo, так что, думаю, я не могу жаловаться слишком много!
источник
Я знаю, что это старая ветка, но я решила, что предложу немного понимания.
Кажется, именно так SD-карты умирают естественной смертью. Количество циклов чтения / записи, которые могут выдержать SD-карты, значительно ниже, чем у большинства других носителей, считающихся «чтение / запись». Когда это будет исчерпано, карта перейдет в режим только для чтения, но не проинформирует вас об этом. Многие будут думать, что они пишут на карту благодаря кэшированию ОС и т. Д., Но ничто не мешает.
Отличный способ убить SD-карту - это смонтировать ее как раздел подкачки или что-то очень интенсивное для чтения / записи. Вы будете удивлены, как быстро вы сможете убить карту таким образом. Я обнаружил, что запуск knoppix с SD-карты или USB-накопителя продлится всего месяц или два, в зависимости от качества карты и интенсивности использования knoppix. (С тех пор я перешел на запуск knoppix с USB-накопителя, который прослужил пару лет).
источник