Bagaimana saya bisa menghindari pesan “Jalankan fsck secara manual” sambil membiarkan percobaan dengan perubahan waktu sistem?

18

Saya bekerja dengan sistem di mana kami ingin memungkinkan pengguna untuk bermain-main dengan tanggal dan waktu jika mereka mau, dan di mana reboot dapat terjadi secara sewenang-wenang. Ini baik-baik saja, kecuali untuk satu hal: jika ada banyak waktu melompat mundur, kesalahan berikut muncul saat reboot:

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.

... dan kemudian boot hang menunggu input konsol pengguna, dan bahkan setelah akses konsol diperoleh, memerlukan kata sandi root untuk melanjutkan.

Ini jelas kurang ideal. Apakah ada cara untuk melewati pemeriksaan atau memaksa pemeriksaan terjadi secara otomatis saat reboot?

Google hanya menyediakan bantuan yang mengharuskan menjalankan fsck secara manual jika / saat ini terkena, yang bukan yang saya cari. Menjalankan fsck secara manual setelah mengatur waktu tidak berfungsi karena sistem file masih terpasang pada saat itu, dan hanya menonaktifkan fsck sepenuhnya kurang dari ideal.

Saya menggunakan RedHat 6.

Pembaruan : Solusi yang saat ini saya gunakan adalah meretas fstab untuk menonaktifkan pemeriksaan fsck saat reboot. Saya telah mencoba mengedit waktu pemasangan terakhir pada disk yang digunakan debugfs, yang berfungsi dengan baik untuk drive ext3, tetapi tampaknya gagal secara tidak konsisten pada ext4.

boot rhel date fsck saya dan
sumber

Jawaban:

15

Saya akan menyarankan peretasan e2fsckuntuk menonaktifkan pemeriksaan khusus untuk waktu pemasangan terakhir atau waktu penulisan terakhir di masa mendatang. Ini didefinisikan di problem.c / problem.h , dan digunakan di super.c . Tetapi dalam mencari, saya menemukan bahwa E2fsprogs 1.41.10 menambahkan opsi baru untuk /etc/e2fsck.confdisebut broken_system_clock . Ini tampaknya persis apa yang Anda butuhkan, dan karena Anda menggunakan Red Hat Enterprise Linux 6, Anda harus memiliki 1.41.12, yang mencakup opsi ini. Dari halaman manual:

   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.

Ya, halaman manual tidak dapat mengeja "heuristik". Ups. Tetapi agaknya kodenya tetap bekerja. :)

mattdm
sumber
Itu terlihat fantastis, kecuali bahwa halaman manual menunjukkan itu hanya mempengaruhi ext2 dan ext3, dan saya menggunakan kombinasi ext3 dan ext4. Tetap saja, saya akan mencobanya sekarang, seolah-olah itu berhasil, itulah yang saya cari.
me_and
1
Berhasil! Termasuk di ext4. Terima kasih!
me_and
1

Saya ragu ada cara untuk menghapus pemeriksaan ini secara khusus, singkat dengan memodifikasi kode sumber. Mengabaikan semua kesalahan dari fsck kedengarannya berbahaya, bagaimana jika ada masalah lain?

Oleh karena itu saya akan menyarankan solusi berikut: ubah skrip boot untuk mengatur tanggal sistem ke beberapa waktu di masa depan (katakanlah 2038-01-18 pada mesin 32-bit) sesaat sebelum menjalankan fsck, dan membacanya kembali dari perangkat keras jam setelahnya ( hwclock --hctosys, dengan lebih banyak opsi yang diperlukan tergantung pada perangkat keras Anda dan penggunaan GMT di jam perangkat keras.)

Gilles 'SANGAT berhenti menjadi jahat'
sumber
Apakah ini tidak berarti lain kali bahwa akan ada jendela di mana kita bisa mengenai bug yang sama lagi? yaitu waktu pemasangan terakhir adalah 2038-01-18, jadi jika waktu saat ini diatur untuk itu juga, ada kondisi lomba di mana kita (sejauh yang menyangkut sistem) mencoba memasang sebelum pemasangan terakhir lagi.
me_and
@me_and: Ya, saya khawatir kludge saya tidak akan membantu melawan pengguna jahat. Jika itu yang Anda hadapi, menambal fsck tampaknya menjadi pilihan terbaik.
Gilles 'SO- berhenti bersikap jahat'
0

Ini terdengar seperti itu harus dijalankan di mesin virtual, di mana Anda dapat memiliki lebih banyak kontrol (atau kembali ke snapshot).

jamespo
sumber
Berjalan di VM benar-benar bukan pilihan bagi kita, dan dalam hal apa pun kembali ke snapshot berarti kita menghapus semua keadaan lain yang mungkin telah diatur pengguna.
me_and
0

Berikut adalah solusi yang bekerja sangat baik untuk saya:

Buat /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
}

Lebih lanjut tentang perbaikan ini di sini:

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

GoinOff
sumber