Как можно избежать сообщений «Запускать fsck вручную», позволяя экспериментировать с изменениями системного времени?

18

Я работаю с системой, где мы хотим, чтобы пользователи могли поиграть с датой и временем, если они хотят, и где перезагрузки могут произойти произвольно. Это нормально, за исключением одного: если есть большой скачок времени назад, при перезагрузке появляется следующая ошибка:

Checking filesystems
IMAGE2: Superblock last mount time (Tue Mar  1 17:32:48 2011,
        now = Thu Feb 24 17:34:29 2011) is in the future.

IMAGE2: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

… И затем загрузка зависает в ожидании ввода пользовательской консоли, и даже после получения доступа к консоли требуется пароль root для продолжения.

Это явно не идеально. Есть ли способ пропустить проверку или принудительно выполнить проверку при перезагрузке?

Google предоставил только справку, которая требует запуска fsck вручную, если / когда это произошло, а это не то, что мне нужно. Запуск fsck вручную после установки времени не работает, так как файловая система все еще монтируется в этот момент, и простое полное отключение fsck не является идеальным.

Я использую RedHat 6.

Обновление : решение, с которым я сейчас работаю, - это взломать fstab, чтобы отключить проверку fsck при перезагрузке. Я попытался отредактировать время последнего монтирования на дисках с помощью debugfs, который отлично работает для дисков ext3, но, по-видимому, не всегда работает на ext4.

— я и
источник

15

Я собирался предложить взлом, e2fsckчтобы отключить определенные проверки для последнего времени монтирования или последнего времени записи в будущем. Они определены в problem.c / problem.h и используются в super.c . Но в поисках, я обнаружил , что E2fsprogs 1.41.10 добавляет новую опцию /etc/e2fsck.confпод названием broken_system_clock . Кажется, это именно то, что вам нужно, и, поскольку вы используете Red Hat Enterprise Linux 6, у вас должен быть 1.41.12, который включает эту опцию. Со страницы руководства:

   broken_system_clock
          The e2fsck(8) program has some hueristics that assume  that  the
          system clock is correct.  In addition, many system programs make
          similar assumptions.  For example, the UUID library  depends  on
          time  not going backwards in order for it to be able to make its
          guarantees about issuing universally unique ID’s.  Systems  with
          broken  system clocks, are well, broken.  However, broken system
          clocks, particularly in embedded systems, do exist.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

Да, на странице руководства не может быть написано "эвристика". К сожалению. Но, по-видимому, код работает в любом случае. :)

— mattdm
источник

Это выглядит фантастически, за исключением того, что справочная страница подразумевает, что она влияет только на ext2 и ext3, и я использую комбинацию ext3 и ext4. Тем не менее, я сейчас попробую, как будто это работает, это именно то, что я ищу.

— me_and

1

Оно работает! В том числе и на ext4. Спасибо!

— me_and

1

Я сомневаюсь, что есть способ удалить эту проверку специально, за исключением модификации исходного кода. Игнорирование всех ошибок из fsck звучит опасно, что если возникнет какая-то другая проблема?

Поэтому я предложу следующий обходной путь: измените загрузочные сценарии, чтобы установить системную дату на какое-то время в будущем (скажем, 2038-01-18 на 32-разрядной машине) непосредственно перед запуском fsck, и прочитайте ее обратно с аппаратного обеспечения. часы после этого ( hwclock --hctosysс дополнительными параметрами по мере необходимости в зависимости от вашего оборудования и использования GMT в аппаратных часах.)

— Жиль "ТАК - перестань быть злым"
источник

Не будет ли это означать, что в следующий раз появится окно, в котором мы снова сможем устранить ту же ошибку? т. е. время последнего монтирования - 2038-01-18, поэтому, если текущее время также установлено, есть условие гонки, при котором мы (насколько это касается системы) пытаемся смонтировать перед последним монтированием снова.

— me_and

@ me_and: Да, я боюсь, что мой kludge не поможет против злоумышленников. Если вы против этого, патч для fsck выглядит лучшим вариантом.

— Жиль "ТАК - перестань быть злым"

0

Это звучит так, как будто его следует запускать на виртуальной машине, где вы можете иметь больше контроля (или просто вернуться к снимку).

— jamespo
источник

Запуск в виртуальной машине на самом деле не вариант для нас, и в любом случае просто возврат к снимку означает, что мы удаляем все остальные состояния, которые пользователь мог установить.

— me_and

0

Вот решение, которое отлично сработало для меня:

Создайте /etc/e2fsck.conf:

[problems]

# Superblock last mount time is in the future (PR_0_FUTURE_SB_LAST_MOUNT).
0x000031 = {
preen_ok = true
preen_nomessage = true
}

# Superblock last write time is in the future (PR_0_FUTURE_SB_LAST_WRITE).
0x000032 = {
preen_ok = true
preen_nomessage = true
}

Подробнее об этом исправлении здесь:

http://stillstup.blogspot.com/2010/02/superblock-last-mount-time-is-in-future.html

— GoinOff
источник