[Решено]live windows сломал суперблок

История простая как 2 рубля. Загрузился в live win 8 c usb hdd. Запустил acronis true image 2014. Выбрал ssd на котором установлен Arch Linux по этому гайду. Установка прошла без проблем, и я на всякий решил забэкапить, чтобы не ждать по новой загрузку пакетов. Когда попытался запустить резервирование, акронис выдал предуперждение, что файловая система повреждена и он типа может бэкапить только посекторно. Видимо fs уже тогда была повреждена, но как? В общем, я согласился на посекторное и после перезагрузки(к сожалению не сфотал) получил сообщение об ошибке. По тексту понял, что что-то сучилось с суперблоком. Исправил командой
fsck /dev/sda3
. sda3 это "/". По всему экрану бежали цифры. Во время проверки раза 2-3 пришлось зажимать игрек. Что-то там исправилось и все заработало. Сижу и думаю, ставить заново или забить. Не думал, что загрузка из под винды убъёт ext4. Почему задумался? Просто получил вывод команды
$sudo mkdir /mnt/usb
, в которой говорилось, что раздел доступен только для чтения. А затем и на эту
#mkdir /mnt/usb
команду такой же вывод. В итоге пришлось монтировать в /home/usb.
Конечно, после того как я увидел в abuot thunar сообщение о том, что надо бы установить пакет gvfs и все заработало автоматом. Но почему не удалось создать каталог из под рута я так и не понял.

[Решение] Как я уже написал, суперблок легко чинится на месте командой fsck /dev/yourdisk. Чтобы этого не произошло, можно отключить некоторые "Filesystem features(особенности файловой системы)". Это metadata_сsum(контрольня сумма метаданных) и 64bit(поддержка 64-битных файловых систем). Я не знаю что там такого происходит при монтировании ext4 раздела в лайв виндоуз, но видимо таблица раздела немного перестраивается. Немудренно, т.к. под контрольную сумму выделяется определенное пространство и это реализовано только в ext4. Даже в вики есть пометка, что данная особенность реализована для пользователей, желающих использовать только эту fs. Поэтому здесь имеем расхождение в совместимости. Но опять же есть компромис, в отказе от этой, не сказать что прямо необходимой фичи. )
Привет! Я когда-то с этим уже сталкивался. После каждой загрузки с лайф-флешки, у меня косячились все ext разделы.
Решение проблемы нашел вот ТУТ

"The problem is related to ext2fsd which obviously does not support the 64bit feature and/or metadata_csum feature. It is sufficient to have ext2fsd installed to corrupt your ext4 partitions. No need for them to be mounted in Windows.
You can check if these features are enabled with the following command:

sudo tune2fs -l /dev/[sdXX]

where [sdXX] stands for the ext4-partition in question."


Решение в отключении этих фич: sudo tune2fs -O "^metadata_csum,^64bit" /dev/sdXX
Давайте жить дружно! :-)
Привет, спасибо! :) А что дают эти фичи? Интересно узнать, чего я лишусь отключив их? Крутил крутил эту статью и так и не въехал в чем суть.
ХЗ. Пусть гуру подскажут.
Я отключил без видимых для себя потерь. EXT разделы больше не косячатся.
Давайте жить дружно! :-)
Ну в роде я примерно понял. Это нечто для надежности ходьбы данных. Но как оно работает и где можно потестить не нашел.
Mutagen
Но как оно работает и где можно потестить не нашел.
Я не погружаюсь до такой степени во всю эту хрень. Конечно, если не работает - я разберусь. ))) Но, у меня 2 системы было всегда. Где проще и быстрее (и еще некоторые моменты, важные для меня), там я и делаю. Если все маны прочитать - глаз моих не хватит, и самое главное, времени.
Давайте жить дружно! :-)
О-о... Может не надо ничего делать, если "ХЗ"? Даже если это советуют в интернете.

fsck для ext4 использует e2fsck.

$ info e2fsck.conf

accept_time_fudge
Unfortunately, due to Windows' unfortunate design decision to configure the hardware clock to tick localtime,
instead of the more proper and less error-prone UTC time, many users end up in the situation where the system
clock is incorrectly set at the time when e2fsck is run.
Historically this was usually due to some distributions having buggy init scripts and/or installers that didn't
correctly detect this case and take appropriate countermeasures. Unfortunately, this is occasionally true even
today, usually due to a buggy or misconfigured virtualization manager or the installer not having access to a
network time server during the installation process. So by default, we allow the superblock times to be fudged
by up to 24 hours. This can be disabled by setting accept_time_fudge to the boolean value of false. This set‐
ting defaults to true.

/etc/e2fsck.conf

[options]

accept_time_fudge = false

Логично? Пробуйте...
Решение может быть еще проще: всегда проверять hardware clock в процессе перезагрузки после работы в windows. Время не должно быть раньше, чем время завершения работы в Linux. И тогда внесение изменения в конфигурацию не требуется. А live win 8 установила свое время в случае ТС с acronis true imagе. И так как время оказалось раньше, чем завершение работы Linux, возникли проблемы с суперблоком. Поэтому в live win 8 время надо гнать вперед на разницу между hardware clock и localtime. А еще лучше - live lin, а не live win. )
zsx
accept_time_fudge = false
не помогло
zsx
Решение может быть еще проще
первое решение ИМХО проще некуда. Создать файл с одной строкой. Что может быть проще?
zsx
всегда проверять hardware clock в процессе перезагрузки
а как это сделать?
 
Зарегистрироваться или войдите чтобы оставить сообщение.