Як я можу уникнути повідомлень "Запустити 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.

… І тоді завантажувач зависає, чекаючи введення консолі користувача, і навіть після отримання доступу до консолі потрібен кореневий пароль для продовження.

Це, очевидно, менше, ніж ідеально. Чи є якийсь спосіб пропустити чек або змусити його перевіритись автоматично при перезавантаженні?

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: Так, боюся, мій хитрості не допоможе проти зловмисних користувачів. Якщо це проти чого, виправлення fsck виглядає найкращим варіантом.

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

0

Це здається, що його слід запускати у віртуальній машині, де ви можете мати більше контролю (або просто повернутися до знімка).

— джамеспо
джерело

Запуск у віртуальній машині дійсно не є для нас варіантом, і в будь-якому випадку просто повернення до знімка означає, що ми видаляємо всі інші стани, які користувач може створити.

— 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
джерело