fsck проверяет систему при каждой загрузке

[rig]

Похоже, что произошло это после того как ubuntu (8.04) обновила linux-image-2.6.24-19-generic 2.6.24-19.33 до версии linux-image-2.6.24-19-generic_2.6.24-19.34 или возможно после того как монтировал внешний диск с файловой системой через команду  "mount -t ntfs-3g /dev/sda1 /media/disk-1 -o force". Что именно вызвало трабл не знаю, так как и то и другое действия произошли в один день и между ними перезагрузок не было.
Трабл заключается в следующем, при включении компьютера, каждый раз (!!!), запускается fsck. Из-за этого загрузка затягивается на продолжительное время. Думал, в начале, что перезаписался fstab, но дата модификации стоит 22 апреля 2008 г., а глюк начался только вчера вечером. Вот, кстати, сам fstab:

Код: [Выделить]

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# /dev/hda2
UUID=0afd6f15-6f12-461a-995c-94a5f4f7283b /               ext3    relatime,errors=remount-ro 0       1
# /dev/hda5
UUID=e7954330-a958-4d1d-8cb1-d85633392114 /home           ext3    relatime        0       2
# /dev/hda6
UUID=53C6-51D5  /pochta         vfat    utf8,umask=007,gid=46 0       1
# /dev/hda7
UUID=cc240b7e-a44f-4abb-b19b-3d93dfae66ce none            swap    sw              0       0
/dev/hdc        /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0
в нём мне не понятно, почему наряду с "/dev/hda2" и у  "/pochta" значение "pass" = "1" ? Но так как все же дата модификации стоит давнешняя, то решил: коли уж загружалось все нормально раньше с этими параметрами, то и сейчас это врядли должно повлиять на загрузку...

вот содержание файла checkroot

Код: [Выделить]

Log of fsck -C3 -a -t ext3 /dev/hda2
Thu Jun 26 09:51:47 2008

fsck 1.40.8 (13-Mar-2008)
/dev/hda2: clean, 148596/1220608 files, 1046330/4881751 blocks

Thu Jun 26 09:51:47 2008
----------------
содержание файла checkfs

Код: [Выделить]

Log of fsck -C3 -R -A -a
Thu Jun 26 09:51:47 2008

fsck 1.40.8 (13-Mar-2008)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
/dev/hda6: 297736 files, 1128874/1646008 clusters
/dev/hda5: clean, 63390/2449408 files, 1818300/9765504 blocks

Thu Jun 26 09:54:27 2008
----------------
файл e2fsck.conf

Код: [Выделить]

[options]
buggy_init_scripts = 1
Вот не понятно, что могло послужить причиной трабла и как лечить?

[Vit.Ok]

я просто в фстабе выставил везде "0" и у меня он никого не проверяет и загрузка происходит быстро (для корня и хома последнею цифру поставил 0), а если комп бутнуть через рессет на системнике, то Ubuntu сама подчисстит файловую систему, т.е. смысла в проверке не вижу.

[rig]

как мне кажется, если поставить везде нули, то это уже борьба со следствием. Ведь, если верить дате модификации файла, как я писал выше, то он здесь не причем. Т.е. трабла вылезла откуда-то из другого места, хотелось бы понять от куда она вообще взялась. Как-то можно узнать это?

[rig]

Не ужели ни кто не сталкивался? 

[Kwah]

А если загрузиться с предыдущим ядром?

[rig]

На самом деле я вообще ни не успользую ядро 2.6.24-19, потому-что так и не смог подружить с ним драйвер для Wii-Fi карты (в menu.lst, я просто закоментировал строки с этим ядром). Я загружаюсь со старым ядром kernel 2.6.24-16-generic.

Но для чистоты эксперемента, пробовал загрузиться с версией 2.6.24-19. Результат тот же, обе попытки подряд - опять запускается fsck.

P/S:
На сколько я понял при обновлении linux-image-2.6.24-19-generic 2.6.24-19.33 на linux-image-2.6.24-19-generic_2.6.24-19.34, версия linux-image-2.6.24-19-generic 2.6.24-19.33 проапгрейдилась до linux-image-2.6.24-19-generic_2.6.24-19.34. Т.е. версии linux-image-2.6.24-19-generic_2.6.24-19.33 на компе уже нет?

[rig]

а как можно узнать расписание, по которому должна запускаться fsck? Курил маны по tune2fs и e2fsck, но ответ не нашёл...

[rig]

или как-то по другому узнать, что заставляет fsck запускаться при загрузке компа?

[Kwah]

а как можно узнать расписание, по которому должна запускаться fsck? Курил маны по tune2fs и e2fsck, но ответ не нашёл...

Плохо курил man tune2fs параметры -c и -i

[mazut]

у тебя стоит /dev/hda2 проверять первым  1

и /dev/hda6 тоже первым, может тут собака порылась?

[rig]

Плохо курил man tune2fs параметры -c и -i

Эти параметры как раз выкурил в первую очередь:

-c max-mount-counts
              Adjust  the  number of mounts after which the filesystem will be
              checked by e2fsck( 8 ).  If max-mount-counts is 0 or -1, the  num
              ber  of  times  the filesystem is mounted will be disregarded by
              e2fsck( 8 ) and the kernel.

              Staggering the mount-counts at which  filesystems  are  forcibly
              checked  will  avoid  all  filesystems being checked at one time
              when using journaled filesystems.

              You should  strongly  consider  the  consequences  of  disabling
              mount-count-dependent   checking  entirely.   Bad  disk  drives,
              cables, memory, and kernel bugs could all corrupt  a  filesystem
              without  marking  the  filesystem dirty or in error.  If you are
              using journaling on your filesystem, your filesystem will  never
              be marked dirty, so it will not normally be checked.  A filesys
              tem error detected by the kernel will still force an fsck on the
              next reboot, but it may already be too late to prevent data loss
              at that point.

              See also the -i option for time-dependent checking.

       -C mount-count
              Set the number of times the filesystem has been mounted.  If set
              to  a  greater  value than the max-mount-counts parameter set by
              the -c option, e2fsck( 8 ) will check the filesystem at  the  next
              reboot.

 -i  interval-between-checks[d|m|w]
              Adjust the maximal time between two filesystem checks.  No post
              fix or d result in days, m in months, and w in weeks.   A  value
              of zero will disable the time-dependent checking.

но как понял, там можно только устанавливать значения, а как те, что уже установлены посмотреть?

[Kwah]

Блин, -l (list)

[rig]

у тебя стоит /dev/hda2 проверять первым  1

и /dev/hda6 тоже первым, может тут собака порылась?

да, очевидно она действительно порылась, но не совсем в этом месте... У меня тоже были подозрения на этот счет (см. первый пост), но так-как дата модификации файла fstab давнешняя, то естественно от него это не могло напрямую зависеть (ну только если какая прога не изменила дату модификации, что мало вероятно). Я пришёл к следующему выводу:
дело в том, что где-то в тот же период времени, как всё вышеописанное случилось, я переписал около 30 Гб с внешнего диска на котором находилась убитая Windows, на свой раздел "/pochta" ( /dev/hda6 ) отформатированый в fat32. Теперь думаю, что какие-то названия файлов оказались не понятными для fsck и видя "ошибку", он каждый раз, при перезагрузке стал запускаться заново.

[rig]

Блин, -l (list)

Буду благодарен, если подскажите как употребить это. спасибо.

[mazut]

#umount /dev/hda6
#tune2fs -l /dev/hda6