OpenSUSE 11.1 - новая версия, новые грабли...

Обсуждение технических вопросов по продуктам Novell под Linux, а также *nix систем

OpenSUSE 11.1 - новая версия, новые грабли...

Сообщение Константин Ошмян » 13 фев 2009, 19:35

Поставил месяц назад OpenSUSE 11.1, уже успел наступить на несколько граблей. Если первые неприятности успешно разрешились (найдены обходные пути), то с последними пока не разобрался. Итак, по порядку.

1. Ставил на не первой молодости машинку (Pentium III/866, 640MB RAM, 2x500GB PATA HDD). Далал программную зеркалку (/dev/md0 = /dev/sd[ab]1 - под своп, /dev/md1 = /dev/sd[ab]2 - под корневую файловую систему, без дальнейшей разбивки). Вроде всё установилось, но после перезагрузки ничего не поднялось. :(
Код: Выделить всё
Booting from local disk...
GRUB Loading stage 1.5.

GRUB loading, please wait...
Error 18
Поиск по сообщениям об ошибке от GRUB-a выводил на одну и ту же рекомендацию: делайте /boot отдельной небольшой файловой системой. Странно, мне казалось, что GRUB давно уже умеет обходить эту проблему... И ранее на этом же компьютере в точно такой же конфигурации, но с дисками по 250 ГБ, было всё нормально. Ну да ладно.

2. Вторая попытка: разбиваем немного по-другому.
Код: Выделить всё
/dev/sd[ab]1 -> /dev/md2 -> /boot
/dev/sd[ab]2 -> /dev/md0 -> /
/dev/sd[ab]3 -> -------- -> swap (без зеркала)
/dev/sd[ab]4 -> /dev/md1 -> /home
Проставилось снова всё отлично, но после перезагрузки снова до конца загрузиться не удалось. На этот раз GRUB успешно отработал, ядро нашёл и стартанул, однако загрузка ядра остановилась на сообщениях такого вида:
Код: Выделить всё
md: md0 stopped
md: bind <sdb2>
md: bind <sda2>
raid1: raid set md0 active with 2 out of 2 mirrors
md0: bitmap initialization from disk: read 11/11 pages, set 0 bits
created bitmap (160 pages) for device md0
mdadm: /dev/md/0 hashem started with 2 drives
Trying manual resume from /dev/disk/by-id/длинный_идентификатор_диска-part3
Invoking userspace resume from /dev/disk/by-id/длинный_идентификатор_диска-part3
resume: libgcrypt version: 1.4.1
Trying manual resume from /dev/disk/by-id/длинный_идентификатор_диска-part3
Invoking in-kernel resume from /dev/disk/by-id/длинный_идентификатор_диска-part3
PM: starting manual resume from disk
Waiting for device /dev/md0 to appear: ok
invalid root file system -- exiting to /bin/sh
$
К счастью, данная ошибка уже была описана здесь и здесь, и приведённый workaround мне помог:
1) прямо в ответ на приглашение "$ " нажать "Ctrl-D" (или "exit"+<Enter>) для выхода из текущего шелла, система продолжает загружаться нормально;
2) зайдя root-ом, отредактировать файл /lib/mkinitrd/scripts/boot-md.sh таким образом, чтобы он заканчивался так (обратить внимание на последние три строчки перед заключительным "fi", при необходимости - добавить):
Код: Выделить всё
        if [ "$md_dev" ] ; then
            /sbin/mdadm $mdconf --auto=md $md_dev || /sbin/mdadm -Ac partitions $mdarg --auto=md $md_dev
        fi
        sleep 1
        echo change > /sys/block/md$md_minor/uevent
        wait_for_events
fi
3) запустить команду mkinitrd (без операндов), после чего перегрузиться.
Любопытно, что когда я ставил систему на другой компьютер чуть более новой конфигурации (уже с SATA-дисками), эта проблема не возникала.

3. А вот с последней проблемой пока не разобрался. Заключается она в том, что компьютер время от времени (чёткой закономерности пока не выявлено) впадает в какое-то полуспящее состояние. Выглядит это так: экран полностью пустой (чёрный), на клавиатуру не реагирует (включая всякие "волшебные" клавиши типа Ctrl-Alt-Del, Alt-F2 или Ctrl-Alt-F1; даже на банальные CapsLock/ScrollLock/NumLock лампочки на клавиатуре не загораются), но при этом по сети пингуется отлично, хотя с другой стороны - подключиться ни по одному протоколу не даёт (Samba/SSH/HTTP), причём попытки установить соединение вроде бы проходят успешно, долго висят, после чего сбрасываются по тайм-ауту (как будто на первый пакет ответ пришёл, а на последующие - нет, хотя точно сниффером не смотрел). После грубой перезагрузки (кнопкой Reset) успешно загружается, что характерно - диски при этом не перезеркаливает (что было бы при Reset-е после простого подвисания).

Такое ощущение, будто система уходит "спать", но как-то не вполне корректно - т.к. непонятно, как её "разбудить". Всякие энергосберегающие вещи в BIOS Setup-е я поотключал (что нашёл), но это не помогло. Не понимаю, где ещё смотреть, т.к. в файле /var/log/messages совершенно ничего не видно: просто в какой-то момент сообщения обрываются, а дальше продолжаются уже только после перезагрузки. Поначалу грешил на сам компьютер ("железо"), но после того как ситуация повторилась точь-в-точь на другом компьютере (другой аппаратной конфигурации), решил поспрашивать тут - может, кто чего присоветует.

Ядро 2.6.27.7-9-pae, default runlevel = 3 (с сетью, но без графики), основная служба - Samba (как файл-свалка для нескольких компьютеров Windows XP Professional). До этого на одном из этих компьютеров работал OpenSUSE 10.3, на другом - ещё 9.3, ни разу таких проблем не наблюдалось. Очень надеюсь на коллективный разум. :)

Upd: уточнил текст сообщений.
Последний раз редактировалось Константин Ошмян 16 фев 2009, 01:13, всего редактировалось 2 раз(а).
Аватара пользователя
Константин Ошмян
 
Сообщения: 991
Зарегистрирован: 13 авг 2002, 21:36
Откуда: Рига

Сообщение Dimerson » 13 фев 2009, 20:01

чесслово - всю жизнь юзал аппаратные раиды (на серверах SCSI сейчас SAS, на станциях - лучшее что можно это раид на ICH7,8,9+ со всякими платками на марвелл или SiI тараканов масса) и софтраидных траблов не видел .

а про замирающий комп - было бы интересно выяснить это св-во SLES или нет ? То есть если нет замудренных сервисов поставить чтонить отличное от SLES (или слес версии пораньше) на выбор и понаблюдать.
Аватара пользователя
Dimerson
 
Сообщения: 2951
Зарегистрирован: 15 сен 2002, 14:39
Откуда: Регион 70

Сообщение Константин Ошмян » 13 фев 2009, 21:03

Dimerson писал(а):чесслово - всю жизнь юзал аппаратные раиды
Дык, на порядочные серверы - порядочное железо. А на домашний "мини" - какой смысл? Впрочем, это уже немного не по теме.
Dimerson писал(а):а про замирающий комп - было бы интересно выяснить это св-во SLES или нет ? То есть если нет замудренных сервисов поставить чтонить отличное от SLES (или слес версии пораньше) на выбор и понаблюдать.
Дык про то и говорю, что с предыдущими версиями такого не наблюдал. Были версии: 9.3, 10.1, 10.3 (на, фактически, том же "железе", только диски менялись на более объёмные). Поискал немного по словам "suspend" и "hibernate" - нашёл кучу ссылок на то, что, во-первых, в ядре 2.6.27 (которое ставится в OpenSUSE 11.1) среди прочих изменений - куча вещей, относящихся к ACPI и этим режимам, во-вторых - много заметок на тему "как правильно настроить ноутбук, чтобы он уходил в Suspend/Hibernate по нажатию кнопки и закрыванию экрана, если оно почему-то не уходит само". Но у меня не ноутбуки, да и рекомендации подкрутить что-то в графической оболочке Gnome или KDE мне не подходят - как я уже говорил, у меня рабочий runlevel - 3, т.е. без графики вообще.
Аватара пользователя
Константин Ошмян
 
Сообщения: 991
Зарегистрирован: 13 авг 2002, 21:36
Откуда: Рига

Сообщение Константин Ошмян » 16 фев 2009, 02:04

Блин, ситуация с "засыпаниями" довольно неприятная и весьма напрягает. Сначала это случилось на компьютере, обслуживающем (в качестве файл-сервера) небольшую сетку на 5 машин. Там всё работало прекрасно более трёх лет на базе версии OpenSUSE 9.3 и работало бы и дальше, если бы не авария по питанию, пробившая дешёвый UPS: сгорели блок питания, системная плата и один из двух зазеркаленных дисков. :? Поскольку пришлось менять, фактически, весь комп (живыми остались только процессор, один диск и корпус), то выяснилось, что прежнее ядро Линукса не поддерживает новые аппаратные компоненты (в частности - встроенную сетевушку). В результате самым простым решением показалось просто проапгрейдить поверху на текущую версию (11.1). В общем-то, всё прекрасно заработало, кроме вот этого глюка.

Я сначала грешил на то, что криво проапгрейдилось (даже переустановил заново начисто), потом - на компьютер/UPS/рабочее место/новые проблемы с питанием. Затем понял, что это тут ни при чём, когда те же симптомы (один в один) повторились на моём домашнем компе после чистой установки той же версии OpenSUSE 11.1 на новые PATA-диски (см. первое сообщение, до этого стояла 10.3).

Сегодня понаблюдал за ситуацией чуть подробнее, с соседней машины половил пакеты Wireshark-ом. Результат такой: спокойно работает PING, нормально отвечаются ARP-запросы. На TCP-шные соединения на открытые порты (ssh, samba) приходит первый ответный пакет (с флагами SYN и ACK), после чего не приходит больше ничего. На неоткрытые порты (Telnet, Ftp, Http) либо не приходит ничего, либо сразу приходит отлуп (RST).

На клавиатуре индикатор NumLock был включен, так его состояние не менялось - нажимай хоть что угодно. Самбовские сетевые диски поотваливались, висящее SSH-соединение - нет, но тоже было "мёртвое" (окончательно отвалилось только при перезагрузке Linux-машины). Список работающих процессов:
Код: Выделить всё
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Feb12 ?        00:00:02 init [3]
root         2     0  0 Feb12 ?        00:00:00 [kthreadd]
root         3     2  0 Feb12 ?        00:00:00 [migration/0]
root         4     2  0 Feb12 ?        00:00:00 [ksoftirqd/0]
root         5     2  0 Feb12 ?        00:00:00 [events/0]
root         6     2  0 Feb12 ?        00:00:00 [khelper]
root         7     2  0 Feb12 ?        00:00:00 [kintegrityd/0]
root         8     2  0 Feb12 ?        00:00:00 [kblockd/0]
root         9     2  0 Feb12 ?        00:00:00 [kacpid]
root        10     2  0 Feb12 ?        00:00:00 [kacpi_notify]
root        11     2  0 Feb12 ?        00:00:00 [cqueue]
root        12     2  0 Feb12 ?        00:00:00 [kseriod]
root        13     2  0 Feb12 ?        00:00:00 [kondemand/0]
root        14     2  0 Feb12 ?        00:00:00 [pdflush]
root        15     2  0 Feb12 ?        00:00:00 [pdflush]
root        16     2  0 Feb12 ?        00:00:00 [kswapd0]
root        17     2  0 Feb12 ?        00:00:00 [aio/0]
root        18     2  0 Feb12 ?        00:00:00 [kpsmoused]
root        54     2  0 Feb12 ?        00:00:00 [ata/0]
root        55     2  0 Feb12 ?        00:00:00 [ata_aux]
root        57     2  0 Feb12 ?        00:00:00 [scsi_eh_0]
root        58     2  0 Feb12 ?        00:00:00 [scsi_eh_1]
root       192     2  0 Feb12 ?        00:00:00 [ksuspend_usbd]
root       193     2  0 Feb12 ?        00:00:00 [khubd]
root       523     2  0 Feb12 ?        00:00:11 [md0_raid1]
root       557     2  0 Feb12 ?        00:00:00 [kjournald]
root       627     1  0 Feb12 ?        00:00:00 /sbin/udevd --daemon
root       980     2  0 Feb12 ?        00:00:00 [kgameportd]
root      1271     2  0 Feb12 ?        00:00:00 [kauditd]
root      1295     2  0 Feb12 ?        00:00:00 [kstriped]
root      1305     2  0 Feb12 ?        00:00:08 [md1_raid1]
root      1314     2  0 Feb12 ?        00:00:00 [md2_raid1]
root      1355     2  0 Feb12 ?        00:00:00 [kjournald]
root      1366     2  0 Feb12 ?        00:00:00 [kjournald]
root      1846     1  0 Feb12 ?        00:00:00 /sbin/klogd -c 1 -x
root      1850     1  0 Feb12 ?        00:00:00 /sbin/syslog-ng
root      1860     1  0 Feb12 ?        00:00:00 /sbin/acpid
102       1874     1  0 Feb12 ?        00:00:00 /bin/dbus-daemon --system
106       2011     1  0 Feb12 ?        00:00:01 /usr/sbin/hald --daemon=yes
root      2023     1  0 Feb12 ?        00:00:00 /usr/sbin/console-kit-daemon
root      2192  2011  0 Feb12 ?        00:00:00 hald-runner
root      2301  2192  0 Feb12 ?        00:00:00 hald-addon-input: Listening on /dev/input/event0 /dev/input/event4 /dev/input/event3 /dev/input/event2
root      2385  2192  0 Feb12 ?        00:00:00 hald-addon-storage: no polling on /dev/fd0 because it is explicitly disabled
106       2389  2192  0 Feb12 ?        00:00:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
root      2391  2192  0 Feb12 ?        00:00:00 hald-addon-storage: polling /dev/sr0 (every 2 sec)
root      2497     1  0 Feb12 ?        00:00:00 /usr/sbin/nmbd -D -s /etc/samba/smb.conf
root      2576     1  0 Feb12 ?        00:00:00 /sbin/rpcbind
root      2811     1  0 Feb12 ?        00:00:00 /sbin/auditd -s disable
root      2814  2811  0 Feb12 ?        00:00:00 /sbin/audispd
avahi     2819     1  0 Feb12 ?        00:00:00 avahi-daemon: running [chortos.local]
dnsmasq   2895     1  0 Feb12 ?        00:00:00 /usr/sbin/dnsmasq -u dnsmasq
root      2974     1  0 Feb12 ?        00:00:00 /usr/sbin/cupsd
root      3105     1  0 Feb12 ?        00:00:00 /usr/sbin/nscd
ntp       3141     1  0 Feb12 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -i /var/lib/ntp -c /etc/ntp.conf
root      3190     1  0 Feb12 ?        00:00:00 /usr/sbin/smartd
root      3233     1  0 Feb12 ?        00:00:00 /usr/lib/postfix/master
postfix   3255  3233  0 Feb12 ?        00:00:00 pickup -l -t fifo -u
postfix   3256  3233  0 Feb12 ?        00:00:00 qmgr -l -t fifo -u
root      3261     1  0 Feb12 ?        00:00:00 /usr/sbin/cron
root      3289     1  0 Feb12 ?        00:00:00 /usr/sbin/smbd -D -s /etc/samba/smb.conf
root      3314     1  0 Feb12 ?        00:00:00 /usr/sbin/sshd -o PidFile=/var/run/sshd.init.pid
root      3321  3289  0 Feb12 ?        00:00:00 /usr/sbin/smbd -D -s /etc/samba/smb.conf
root      3547     1  0 Feb12 tty1     00:00:00 /sbin/mingetty --noclear tty1
root      3549     1  0 Feb12 ?        00:00:00 login -- root
root      3551     1  0 Feb12 tty3     00:00:00 /sbin/mingetty tty3
root      3552     1  0 Feb12 tty4     00:00:00 /sbin/mingetty tty4
root      3553     1  0 Feb12 tty5     00:00:00 /sbin/mingetty tty5
root      3556     1  0 Feb12 tty6     00:00:00 /sbin/mingetty tty6
root      3628  3549  0 00:04 tty2     00:00:00 -bash
root      3825  3628  0 00:17 tty2     00:00:00 ps -ef
Может, какой-то из демонов глючит? Или какой-то из процессов ядра? По крайней мере, "с лёту" мне найти причину такого поведения не удалось.
Аватара пользователя
Константин Ошмян
 
Сообщения: 991
Зарегистрирован: 13 авг 2002, 21:36
Откуда: Рига

Сообщение Константин Ошмян » 18 фев 2009, 18:30

Кажется, разобрался я с этой проблемой. Сначала пытался долго искать в сторону всяческих энергосберегающих технологий - ознакомился с интереснейшей дискуссией о неверном умолчабельном значении какого-то параметра (в результате которого в какой-то бете OpenSUSE 11.1 десктоп уходил в suspend, не предупреждая пользователя), почитал про технологии Suspend to disk и Suspend to RAM, а также про весь пакет Pm-utils в целом. Понял, что всё это - не мой случай: во-первых, в окончательный suspend (хоть to disk, хоть to RAM) компьютер так и не уходил (питание оставалось, на пинги отвечал); во-вторых - никаких записей в логах о попытке уйти спать не было (ни в /var/log/messages, ни в /var/log/pm-чего-то-там - такого файла не было вообще). Больше было похоже на какую-то ошибку ядра при обработке событий, имеющих отношение к ACPI - вроде, пытаемся уйти "спать", но по какой-то причине это не получается. Но новых ядер через штатные обновления ставить пока не предлагается, и это меня смущало сильнее всего (неужели, будь такой баг, на него "наступил" бы один я?).

Оказалось достаточно близко к этому. Вот он, этот коварный баг, существующий в ядре версии 2.6.27.7 и исправленный в версии 2.6.27.10:
Bugzilla писал(а):There's a bug in linux kernel 2.6.27.7 that is used in SuSE 11.1 that creates unkillable, runaway processes when file monitoring is enabled. This is especially critical when trying to run an IMAP service (which needs file monitoring for efficiency reasons) on SuSE 11.1 since it will force the entire server to be hard reset several times a week and makes SuSE 11.1 unsuitable as an IMAP server
Т.е. баг проявляется не всегда, а в случаях, когда используются программы, которые для повышения эффективности используют какой-то механизм слежения за файлами ("when file monitoring is enabled"). Среди таких - служба IMAP, какой-то неведомый мне, но часто упоминаемый dovecot, да сервер Samba (как раз мой случай!). При этом на Samba-овском форуме эта тема тоже всплывала: при внимательном рассмотрении видно, что перед зависанием компьютера в самбовских логах появляются сообщения вида
Код: Выделить всё
[2009/02/17 17:45:20,  1] smbd/notify_inotify.c:watch_destructor(351)
  inotify_rm_watch returned Invalid argument
[2009/02/17 17:45:23,  1] smbd/notify_inotify.c:watch_destructor(351)
  inotify_rm_watch returned Invalid argument
[2009/02/17 17:45:24,  1] smbd/notify_inotify.c:watch_destructor(351)
  inotify_rm_watch returned Invalid argument
(как раз мой случай). И "самбист" Volker Lendecke открытым текстом даёт следующую рекомендацию:
Try

notify:inotify = false

in [global]. If that helps, your kernel has a broken inotify implementation.
Как раз именно в ядре версии 2.6.27.7 эта реализация inotify в результате вышеупомянутого бага и есть "broken". :? И более правильная рекомендация - это не бороться с последствиями, а устранить причину, т.е. обновить ядро. Как же это проще всего сделать, если через штатный механизм обновлений оно пока недоступно, а пересобирать его самому, мягко говоря, не всякий захочет? Ответ тоже на форуме, где описывается именно моя ситуация. После нескольких загадочных упоминаний какой-то "фабрики" (в стиле: "When will 2.6.27.10 leave factory and be available as an update?" или "я взял текущую версию ядра from factory и теперь всё ОК") некто Harald на 5-й странице обсуждения приводит следующую пошаговую инструкцию:
For me, the factory kernel 2.6.27.10 led to a stable system.
It was really easy to install:
  • YaST->Repositories: Add html: http://download.opensuse.org/factory/repo/oss/
  • YaST->Install Software->search: kernel -> select kernel-2.6.27-10
  • Yast->Boot: surprise->the new kernel was added as an alternate boot kernel to the GRUB configuration
  • Reboot -> that's all
Всё оказалось просто: factory - это репозиторий, куда складываются самые свежие сборки; надо только знать его адрес и добавить вручную в список доступных репозиториев (впоследствии его можно за-disable-ить, не удаляя насовсем). По состоянию на вчера (когда я пробовал указанные инструкции на домашнем компьютере) там лежало ядро 2.6.27.13-3. На втором компьютере, где у меня была данная проблема, я пока что ядро не обновлял, а решил попробовать первый рецепт (с добавлением параметра в конфиг Самбы). Посмотрим, что будет; но я практически уверен, что это именно мой случай - уж больно симптомы совпадают (и большое спасибо Ken Yap, который открыл на форуме последнюю тему и добил-таки решение). 8)

У меня, кстати, подозрения, что и проблема номер 2 (см. исходное письмо) вполне могла быть связана именно с этим же багом ядра.
Аватара пользователя
Константин Ошмян
 
Сообщения: 991
Зарегистрирован: 13 авг 2002, 21:36
Откуда: Рига

Подводя итог...

Сообщение Константин Ошмян » 04 мар 2009, 11:35

...можно сказать, то это таки было оно. На обоих "проблемных" компьютерах зависаний больше не происходило (напомню, что на одном из них я подкрутил конфиг Самбы, а на другом - обновил ядро с "фабрики"). Недавно через штатный механизм обновлений стало доступно ядро версии 2.6.27.19-3.2 (докучавший мне баг, напомню, появился в версии 2.6.27.7 и был исправлен в версии 2.6.27.10). Обновление через Yast проходит совершенно гладко и проблемы с зависанием решает.
Аватара пользователя
Константин Ошмян
 
Сообщения: 991
Зарегистрирован: 13 авг 2002, 21:36
Откуда: Рига

Сообщение Loader » 26 авг 2009, 13:58

2 Константин Ошмян

Спасибо тебе добрый человек!!!

Я уже 2 недели воюю с этим 11.1 дистром и не могу понять в чем дело. Суть примерно таже, что описана в п.3. Источник - самба (т.к. восновном вис когда начинались какието манипуляции с ней), но по логам не мог долго понять что может быть и тут наткнулся гуглом на этот пост.... И главное причина смены 10.3 стал вылет одного из винтов и необходимость перебить рейд. По софту не было никаких проблем. Сначала 11.1 ставился на обычную машину ПК-класса, чтобы минимизировать время простоя, там этот трабл и проявился, но я почему-то не нашев ничего толкового в логах решил что проблема гдето с хардом... И честно говоря был редкий ступор, когда тоже вылезло на серваке.... :shock:

Больше всего поражает тот факт что спустя пол года обновления не включены в загрузочный образ, аналогично как не проставилось при Обновлении Системы с yast2? Или я что-то не то выкачивал....

Вобщем надеюсь что сейчас заработает нормально.... :idea:
Loader
 
Сообщения: 1
Зарегистрирован: 26 авг 2009, 13:46


Вернуться в *nix

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13

cron