LINUX.ORG.RU
Форум — Linux-install  

Superblock last mount time is in the future [part2]


0

0

Продолжение квеста:
http://www.linux.org.ru/view-message.jsp?msgid=4136089
Теперь и на другом компе получил железное воспроизведение сего бага:
Записал для просмотра десяток разных LiveCD с линуксами - и как только
монтирую хомяк с фильмами на HDD для тестового просмотра из LiveCD при очередной загрузке системы с HDD отгребаю:
Superblock last mount time is in the future
с последующим вводом пароля su и зачисткой на 5 минут раздела в 200 гиг...
И так каждый раз - тут мое терпение лопнуло < вырезано цензурой >
Гугление указало еще на большее число жертв сего явления и ряд умных совершенно бесполезых в практике советов.
Ок.
Тут я задал себе простой вопрос тогда:
Зачем порождать эту ошибку (и еще в такой наглой ручной форме устранения)
когда сам факт монтирования раздела на целевой системе уже должен это устранить ?
Тут самый раз глянуть сырцы.
Для начала читаем:
http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.41.9

Fix e2fsck's buggy_init_scritps=1 so that the if the last write and/or last mount times are in the future, they are corrected even if buggy_init_scripts is set. This is needed because otherwise resize2fs will refuse to resize the filesystem, even after running «e2fsck -f». (Addresses Launchpad bug: #373409)

Ага, лекарство хуже самой болезни - это знакомо уже ...
Ладно ...
Нахожу и комментирую фрагмент:

e2fsprogs-1.41.9/e2fsck/super.c
   /*
    * Check to see if the superblock last mount time or last
    * write time is in the future.
    */
goto nafig;
   if (fs->super->s_mtime > (__u32) ctx->now) {
      pctx.num = fs->super->s_mtime;
      problem = PR_0_FUTURE_SB_LAST_MOUNT;
      if (fs->super->s_mtime <= (__u32) ctx->now + ctx->time_fudge)
         problem = PR_0_FUTURE_SB_LAST_MOUNT_FUDGED;
      if (fix_problem(ctx, problem, &pctx)) {
         fs->super->s_mtime = ctx->now;
         ext2fs_mark_super_dirty(fs);
      }
   }
   if (fs->super->s_wtime > (__u32) ctx->now) {
      pctx.num = fs->super->s_wtime;
      problem = PR_0_FUTURE_SB_LAST_WRITE;
      if (fs->super->s_wtime <= (__u32) ctx->now + ctx->time_fudge)
         problem = PR_0_FUTURE_SB_LAST_MOUNT_FUDGED;
      if (fix_problem(ctx, problem, &pctx)) {
         fs->super->s_wtime = ctx->now;
         ext2fs_mark_super_dirty(fs);
      }
   }
nafig:
--------------------------------

собираю пакет
Проверяю на двух компах - и нет пока БОЛЕЕ НИКАКИХ проблем.

А столько времени на издевательства ушло ...





★★★
← OpenBSD USB ADSL EagleIII pppoe
[choose] Дистр на замену Арчу →

такая херня может происходить при запуске разных дистров с разными настройками времени, соответственно, если один дистр считал CMOS и сделал сдвиг (utc) +3 часа по МСК, то при следующем запуске другого дистра он этот сдвиг может не сделать (ибо настройки часового опяса другие) и решить что диск монтировался на +3 часа в будущем, со всеми вытекающими.

Lee_Noox ★★★
()
Ответ на: комментарий от Lee_Noox

Ну это таки понятно.
Но, почему монтирование в родной системе не является самим фактом лечения ... , и как долго будут еще изучать относительные временные явления с fsck ? Ж)))
Т.е, по логике этих господ сбой батарейки часов в BIOS - это хорошее основание для «зашкуривания» всего HDD в аварийном режиме и с рукопашным вводом пароля. Мдя...

зы: Я автору fsck написал о его «исправлении» бага .. Посмотрим.
Пугает другое , что это все разбрелось по дистрам и очень долго теперь обсасывается.

elipse ★★★
() автор топика
15 января 2010 г.

А может проблема в приведении к типу __u32? И кто заполняет fs->super->s_wtime и fs->super->s_mtime. Мне кажется, что ваш костыль стоит на мине.

andreyu ★★★★★
()

И по поводу параметра buggy_init_scritps=1 вопрос - что стоит по умолчанию в конфиге из оригинального (не дистрибутивного) пакета?

andreyu ★★★★★
()
Ответ на: комментарий от andreyu

> Мне кажется, что ваш костыль стоит на мине.

Не понял, я только убрал авторский костыль (goto nafig; ) )- и все.

elipse ★★★
() автор топика
Ответ на: комментарий от andreyu

Ну посмотрел я оригинальный тарбол:
/etc/e2fsck.conf и соответственно buggy_init_scritps=1 ,
(если судить по спекам в самом тарболе ) - не создается дефолтно, так же все и в Debian .

elipse ★★★
() автор топика
Ответ на: комментарий от elipse

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

Т.е, по логике этих господ сбой батарейки часов в BIOS - это хорошее основание для «зашкуривания» всего HDD в аварийном режиме и с рукопашным вводом пароля. Мдя...


мдя...
если бы автор мыслил несколько глубже, а не только критериями своего говнодесктопа, то он бы понял что это очень полезная фича...

anonymous
()
Ответ на: комментарий от anonymous

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

не умничай, венды на этом компе нет вовсе
при сбоях питания, такое происходит тоже

если бы автор мыслил несколько глубже, а не только критериями своего говнодесктопа, то он бы понял что это очень полезная фича...



мдя, не мдя ... но, эта полезная фича достала по самые гланды.

elipse ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← OpenBSD USB ADSL EagleIII pppoe
Linux-install
[choose] Дистр на замену Арчу →