Словил NETDEV WATCHDOG: eth5: transmit timed out,

Гугл завален информацией:

http://www.google.ru/search?q=BUG%3A+soft+lockup+detected+on+CPU+e1000&ie=utf...

Дистр/ядро то какие?

Гугл завален информацией:

Спасибо. Почитаем. Гуглил, конечно, но все не тО попадалось (не учёл, что е1000 надо в поиск. запрос добавить).

Дистр/ядро то какие?

Fedora Core 6, 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 i686 i386 GNU/Linux

Обновляйтесь, даже у меня 2.6.26, а у вас какой-то имперский хлам, а не ядро ;)

>Fedora Core 6

лицеваяпальма.rpm 700GB

Обновляйтесь, даже у меня 2.6.26, а у вас какой-то имперский хлам, а не ядро ;)

Судя по всему, дело не в ядре, а в сетевых, или их драйверах.
Учитавшись гугла, обнаружил аналогичные проблемы на всех более «свежих» ядрах и почти никаких решений.. Кроме разве что вот этого.

Fedora Core 6

лицеваяпальма.rpm 700GB

What is it? Яка така пальма? :)

Кстати этот е1000 ещё со времени 2.4.* гонит, я вместо него какой-то другой подгружал - работало.

Судя по всему, дело не в ядре, а в сетевых, или их драйверах.

А драйвера, как правило, в ядре.

А драйвера, как правило, в ядре.

Да неужели?! ;)
README из последнего драйвера е1000

This file describes the e1000 Linux* Base Driver for Intel Network Connection. This driver supports kernel versions 2.4.x and 2.6.x. This driver includes support for Itanium(R)2-based systems.

This driver is only supported as a loadable module at this time. Intel is not supplying patches against the kernel source to allow for static linking of the driver.

Дак вы драйвер то, что-ли отдельно качали, то что включён в ядро не устроил?

Обновляйтесь, даже у меня 2.6.26, а у вас какой-то имперский хлам, а не ядро ;)

Не так просто оказывается навернуть ядро на Fedora..
Попытался собрать 2.6.34, make rpm обматюгало:

include/linux/compiler-gcc4.h:8:4: error: #error Your version of gcc miscompiles the __weak directive
make[3]: *** [kernel/bounds.s] Error 1
make[2]: *** [prepare0] Error 2
ошибка: Неверный код возврата из /var/tmp/rpm-tmp.33036 (%build)


Ошибки сборки пакетов:
    Неверный код возврата из /var/tmp/rpm-tmp.33036 (%build)
make[1]: *** [rpm] Ошибка 1
make: *** [rpm] Ошибка 2

Дак вы драйвер то, что-ли отдельно качали, то что включён в ядро не устроил?

Именно так.

Если у вас несколько лет всё работало (в том числе и eth5), а потом случился этот самый завис, то может просто дело в железе. Чистота залог здоровья :) И в целом, ИМХО, одно завсание за 2-3 года вполне допустимо.

Не вижу страшного в сборке gcc, компильте его и ставьте в отдельный chroot, туда исходиники ядра и совсем немного других программ для его компиляции. Ну и исходники iptables можно туда же. iptables ручками завернёте в rpm, аналогично поступите с ядром, если это вам недо.

Не вижу страшного в сборке gcc, компильте его и ставьте в отдельный chroot, туда исходиники ядра и совсем немного других программ для его компиляции. Ну и исходники iptables можно туда же. iptables ручками завернёте в rpm, аналогично поступите с ядром, если это вам недо.

С chroot понятно, но к сожалению, не до конца.. Ну например, соберу я все в chroot и..? Как потом все это добро инсталлировать? Тоже в chroot? Или запускать тоже в chroot дире надо будет? Что-то я тут совсем запутался.. :(
Может ссылочку на подходящий мануал покажете?
P.S. Возникла возможно сумашедшая идея - а нельзя ли установить на эту машину (удаленно) совсем другую ОС (CentOS, например) не прекращая работы текущей? «Лишний» хард на ней имеется.
Или сиё есть полный бред?

Мануал, посоветовать не могу, поищите сами, мне сложно определить их толковость, для меня многие вещи кажутся сами собой разумеющимися.

Инсталятор, наверно, запустить так, чтобы он поставил всю систему в chroot не получится, да и вам, вроде только ядро собрать надо было, зачем вам тащить весь CentOS.

ИМХО, скидайте chroot из имеющихся пакетов, примерно так:

mkdir -p /mnt/chroot/var/lib/rpm

rpm -U --root /mnt/chroot/ basesystem...rpm

и другие пакеты, gcc, libc, bash, система сама будет говорить, какие этим пакетам нужны другие пакеты. Понятно, что в /mnt/chroot подмонтирован нужный диск, хотя можно и на этом, если место есть. Как поставите туда bash, уже можно будет делать команду:

chroot /mnt/chroot /bin/bash

И все действия в этом шелле буду относится только к chroot, там собирайте gcc, причём попробуёте взять готовый src.rpm пакет. Там (в чруте) собираете ядро и iptables, а rpm копируете себе в основную систему и там его инсталите.

Chroot не повлияет на основную систему, можете попробовать там скрестить rpm от различных дистров, можно вобще все rpm ставить от CentOS, главное не запутаться и случайно не установить rpm в основную систему, а не в chroot. Хотя если наставить новых rpm, можно в результате компиляции получить rpm, зависящий от них и он потом может не установится в вашу fc6.

Но я ещё раз спрашиваю, вы уверены, что это не аппаратная проблема, допустим, если линк длинный, в сетёвку могла придти помеха (наводка от молнии).

Спасибо за «инструктаж». :) Попробую сначала ядро и iptables осилить.

Инсталятор, наверно, запустить так, чтобы он поставил всю систему в chroot не получится, да и вам, вроде только ядро собрать надо было, зачем вам тащить весь CentOS

Я имел ввиду полностью перейти на более свежую ОС, неспешно собрать ее на другом харде, сконфигурить нужное, а потом «одним махом на неё перепрыгнуть», перекинув загрузку на новый хард.
Хотя, может в этом действительно нет смысла.

Но я ещё раз спрашиваю, вы уверены, что это не аппаратная проблема, допустим, если линк длинный, в сетёвку могла придти помеха (наводка от молнии).

Линк 3м. до порта D-Link DGS-3100, так-что помеха исключается. И скорее всего последний тоже не виновен.
Почти на все 100% уверен, что это софтовая проблема роутера. Эту злочастную eth5 мне так и не удалось подружить с скриптом шейпера, который до перехода на vlan (на «голом» eth) работал как часы, а с vlan-ом через 30-40 сек. загонял машину в kernel panic (что-то с прерываниями связано).
С ней вообще сплошная мистика. Если на обоих портах поднять vlan-ы, то работает это только в таком виде - в одном порту 1G линк, во втором 100М. Если включить 2 гиговых линка, то оба порта как бы «переходят» на 100М (желтые светодиоды «зеленееют») и все перестает работать, ifconfig показывает миллионные числа ошибок..

Ну вот и первые ласточки... :(

bash-3.1# rpmbuild -bp gcc41.spec
ошибка: Неверная пара владелец/группа: /usr/src/redhat/SOURCES/gcc-4.1.2-20070503.tar.bz2

Нашел. Забыл group в /etc скопировать. :)
Теперь пошел гемор с зависимостями gcc.. Ужос..

Вроде все пакеты зависимостей для gcc установил, но rpmbuild -bb gcc41.spec после почти часа работы вывалил следующее

....cut...
make[6]: Leaving directory `/usr/src/redhat/BUILD/gcc-4.1.2-20070503/obj-i386-redhat-linux/gcc/ada'
mv -f libgna*.so rts
make[5]: Leaving directory `/usr/src/redhat/BUILD/gcc-4.1.2-20070503/obj-i386-redhat-linux/gcc/ada'
make[4]: Leaving directory `/usr/src/redhat/BUILD/gcc-4.1.2-20070503/obj-i386-redhat-linux/gcc/ada'
make[3]: Leaving directory `/usr/src/redhat/BUILD/gcc-4.1.2-20070503/obj-i386-redhat-linux/i386-redhat-linux/libada'
make[2]: Leaving directory `/usr/src/redhat/BUILD/gcc-4.1.2-20070503/obj-i386-redhat-linux'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/usr/src/redhat/BUILD/gcc-4.1.2-20070503/obj-i386-redhat-linux'
make: *** [profiledbootstrap] Error 2
ошибка: Неверный код возврата из /var/tmp/rpm-tmp.92679 (%build)


Ошибки сборки пакетов:
    Неверный код возврата из /var/tmp/rpm-tmp.92679 (%build)

То, что вы привели «make[6]: Leaving directory», это уже хвост ошибки. Сам текст ошибки где то раньше, там должно быть error или что-то ещё.

Откуда вы брали src.rpm?

С двухпортовыми e1000 дела не имел и vlan на e1000 не поднимал (у нас все vlan только внутри цисок, а e1000 однопортовые), поэтом конкретно по данному багу не помогу.

Я имел ввиду полностью перейти на более свежую ОС, неспешно собрать ее на другом харде, сконфигурить нужное, а потом «одним махом на неё перепрыгнуть», перекинув загрузку на новый хард.

Моя практика показывает, что лучше это делать на отдельной машине (или виртуальной машине). Там всё сконфигурировать, потестировать, что все нужные демоны работают и понимают конфиги, что в ядре включены все нужные опции и потом добавить в загрузку нужные модули и переставлять винт или перекопировать все файлы. Если ставить в виртуалку и копировать файлы, то сначала проверить ядро+модули (все ли железяки находятся), а потом копировать.

Устанавливать всё в chroot можно, но тогда толком не протестировать службы. Демон хоть и в chroot'e, а порты (tcp/ip) общие, поэтому в демон в chroot'е и демон в основной системе с одинаковым конфигом одновременно не заработают. И с ядром, аналогичная ситуация :)

Вообщем, забил я на это мутное дело и попробовал пойти другим путем - нашел архивный репозитарий федоры (http://forums.fedoraforum.org/showthread.php?t=221471), сделал с него апдейт gcc и.. Ядро собралось.
Что собственно и требовалось. :)
Осталось несколько вопросов: возможно ли как-то собрать iptables и драйвер e1000 для этого ядра, не загружаясь в него?
И еще - вот Вы пишете

Моя практика показывает, что лучше это делать на отдельной машине (или виртуальной машине). Там всё сконфигурировать, потестировать, что все нужные демоны работают и понимают конфиги, что в ядре включены все нужные опции и потом добавить в загрузку нужные модули и переставлять винт или перекопировать все файлы.

Интересно, а чем лучше сборка на другой машине, соотв. на другом железе?
По вашему выходит, что я сейчас, имея на другой машине (на том же Intel, только «посвежее») уже установленный и отлаженный CentOS, просто скопировать содержимое на другой хард «старой» машины и все? И этот «чужак» имеет шанс запуститься на неродном железе?

Относительно e1000 не скажу, но у iptables простой Makefile, там видно, что для сборки с произвольным ядром нужно установить переменные KERNEL_DIR и KBUILD_OUTPUT. То есть немного подправить spec-файл и всё соберётся. Единственная проблема, что в системе не смогут одновременно существовать страные и новые iptables, то есть для нового ядра нужно установить новые, если с ним взлететь не получится, то откатываясь на старое, нужно установить старые.

В принципе, архитектура машины, на которой собирается ядро не так важна, можно спокойно компилировать на одной машине ядра для другой. Вобще есть мнение, что на сервере не должно быть ничего лишнего, в том числе и компилятора, всё собирать на другой машине.

По вашему выходит, что я сейчас, имея на другой машине (на том же Intel, только «посвежее») уже установленный и отлаженный CentOS, просто скопировать содержимое на другой хард «старой» машины и все? И этот «чужак» имеет шанс запуститься на неродном железе?

Не совсем так, нужно убедиться, что присутсвуют все нужные драйвера (модули) и нужные из них засунуты в initrd. То есть ядро должно поддерживать железяки и старого и нового сервера, и если допустим, на старом диск подключен через аппаратный RAID, то в initrd должен быть этот модуль.

Понятно, что всегда есть шанс что-то пропустить, но обсуждаемом подходе можно только не угадать наличие драйверов для отельных устройств, что вполне быстро можно добавить (докомпиляция модуля не требует полной пересборки ядра), зато протестировать что все остальные опции ядра включены. Допустим, некоторые из используемых вами правил iptables могут быть уже выкинуты из ядра...

Относительно e1000 не скажу, но у iptables простой Makefile, там видно, что для сборки с произвольным ядром нужно установить переменные KERNEL_DIR и KBUILD_OUTPUT. То есть немного подправить spec-файл и всё соберётся

Что-то не нашел я в дистре iptables ничего похожего на KERNEL_DIR и KBUILD_OUTPUT.
Ни в iptables.spec, ни в Makefile. Единственно что-то похожее есть в секции %build парамтры ./configure в iptables.spec

--with-kernel=/usr --with-kbuild=/usr --with-ksource=/usr

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

хм, а взять новое железо, которое затем будет как дубликат, поднять там свежий дистр, потестить на тестовом стенде.

Ну как бы оно так и сделано.. Но.. Вот это

и поставить его как холодный/горячий резерв.

ну никак не катит.. :(
Новая машина планируется в-основном в качестве бордера, а старая - в качестве рутера для локального сегмента, DNS, DHCP, TFTP, ну и еще по мелочи.
Фактически сейчас «старая» машина выполняет все озвученные ф-ции и ей уже иногда становится как-то не по себе, особенно когда локальные торрентоводы начинают «гонять кино»..
Вот поэтому вариант «отправить старушку на пенсию» не катит и приходится выпендриваться с обновлениями ядра и драйверов сетевых...

Я вам написал про старый iptables, в CentOS был 1.3.7, и даже ещё в iptables-1.4.0 не было файла «configure», а были KERNEL_DIR. Причём старые iptables дейстивтельно использовали эти переменные.

А новые iptables (я только вылез из танка) имеют configure параметры --with-kernel= --with-kbuild= --with-ksource=, но им совершенно побоку, что там указано. Они лезут в /usr/include/linux. И мне даже не понятно, можно ли со старыми kernel-headers скомпилить новые iptables для нового ядра.