Slackware 14.1 и Internet LAN

Всем спасибо! Победа! Помогло то, что прописал в rc.local то, что в посте выше:)

а ошибки какие есть при загрузке? и бредовая идея по поводу биоса, может она у тебя там отключена?:)

загрузка и выгрузка... обалдеть, будем знать

Не, все норм было, даже ошибок не было. Чего он от простых комманд не работал? Только через файл.

Победа! Помогло то, что прописал в rc.local то, что в посте выше:)

Для подъема сетевых устройств rc.local обычно поздновато.

Именно для случаев, когда нужно что-то вручную подрихтовать до подъема сетевой подсистемы ядра, штатно предназначен /etc/rc.d/rc.netdevice (сам файл в поставке отсутствует, нужно создать и дать атрибут исполнения). Вызывается он из /etc/rc.d/rc.modules, который, в свою очередь, зовется из /etc/rc.d/rc.S (есть смысл глянуть на порядок вызова в зависимости от версий, дабы не смущаться в случае чего), который зовется на начальном уровне исполнения, см:

grep -F /rc.d/rc.S /etc/inittab

Кстати, вполне может оказаться достаточно

modprobe broadcom

Я таки думаю модуль нужно компилировать, его нет это факт

Тут думать не надо, тут достаточно «трясти» (q) или «спросить у попугая» (q):

# find /lib/modules/$(uname -r) -name tg3.ko
/lib/modules/3.10.17/kernel/drivers/net/ethernet/broadcom/tg3.ko

# modinfo tg3 | less

При помощи modinfo легко узнать, поддерживает ли драйвер железку с конкретными VID:PID, а сами VID:PID легко узнать из вывода lspci -nn:

# lspci | grep Ether
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57786 Gigabit Ethernet PCIe (rev 01)

# lspci -knns 2:0.0

так у ТС были в ядре вшиты модули tg и broadcom если при подгрузке ошибку выдавало или нет? и я понимаю что tg3 модуль мог и не быть в ядре, но broadcom то должен был быть

Не хочу из-за всякой фигни новый тред создавать, пожалуюсь здесь. Написал CGI приложение для тестирования, водрузил его на Slax liveUSB, прихожу в офис, гружусь с фрешки, поднимаю апач, клиенты тестируются, я довольный ухожу домой. Но в прошлый раз что-то пошло не так. Присваиваю интерфейсу адрес через ifconfig, он через 10-30 секунд сбрасывается. Думал на конфликт ip адресов, попробовал заведомо свободные, да и работают в субботу 1.5 человека, все ПК выключены. Мне почему-то кажется, что это кеды со своим network manager'ом портят мне жизнь, при загрузке в консольном режиме, всё было нормально, но я только один раз проверил, больше времени не было. Короче, нужна помощь телепатов.

так у ТС были в ядре вшиты модули tg и broadcom

Не давал он повода для подобных выводов.

По поводу вшиты или нет ответ можно дать вполне однозначный: нет.

В Slackware поставляются с точки зрения полноты модулей 2 вида ядер:
установочно-ремонтное — -huge- и основное рабочее — -generic-, их конфиги:
http://slackware.osuosl.org/slackware64-14.1/source/k/config-x86_64/config-hu...
http://slackware.osuosl.org/slackware64-14.1/source/k/config-x86_64/config-ge...

За сборку модуля drivers/net/phy/broadcom.ko
отвечает параметр CONFIG_BROADCOM_PHY
(см. Makefile в соответствующем каталоге исходников ядра).

За сборку модуля drivers/net/ethernet/broadcom/tg3.ko
отвечает параметр CONFIG_TIGON3
(см. Makefile в соответствующем каталоге исходников ядра).

В конфигах стоковых ядер оба драйвера собираются модулями:

$ wget \
http://slackware.osuosl.org/slackware64-14.1/source/k/config-x86_64/config-huge-3.10.17.x64 \
http://slackware.osuosl.org/slackware64-14.1/source/k/config-x86_64/config-generic-3.10.17.x64

$ grep "CONFIG_BROADCOM_PHY\|CONFIG_TIGON3" config-*-3.10.17.*
config-generic-3.10.17.x64:CONFIG_TIGON3=m
config-generic-3.10.17.x64:CONFIG_BROADCOM_PHY=m
config-huge-3.10.17.x64:CONFIG_TIGON3=m
config-huge-3.10.17.x64:CONFIG_BROADCOM_PHY=m

Присваиваю интерфейсу адрес через ifconfig, он через 10-30 секунд сбрасывается.
Мне почему-то кажется, что это кеды со своим network manager'ом портят мне жизнь

Слово «кеды» тут лишнее, поскольку NetworkManager — это отдельный демон, управлять которым можно в том числе и KDE-шным аплетом, а также при помощи nmcli, nm-tool, nm-applet-а.

Для обслуживаемых интерфейсов он действительно запускает клиента dhcp при соответствующей настройке в нём параметров интерфейса.

Варианты: 1) настроить NM на выдачу интерфейсу нужного статического адреса; 2) настройками NM убрать у него управление этим интерфейсом; 3) остановить NM

# /etc/rc.d/rc.networkmanager stop       # только остановить
# chmod a-x /etc/rc.d/rc.networkmanager  # отключить автозапуск

а можно вопрос, а он вообще нужен NetworkManager и для чего если нужен? точнее спрошу - необходим ли он?

Спасибо агрономное. Получается, что dhcpcd я тоже зря рубил, да?

а он вообще нужен NetworkManager и для чего если нужен?

Зависит от личных предпочтений и способа использования системы. Граничные случаи, пожалуй, могут быть таковы:
 — стационарный компьютер, подключающийся к одной и той же сети/сетям, достаточно единожды настроить (от root-а) параметры доступа.
 — ноутбук в руках пользователя, которому нельзя давать root-а, но нужно позволить ему подключаться к заранее неизвестным сетям, тот же Wi-Fi в кафе или где-то ещё, то нужен сервис, запущенный с достаточными для смены сетевых настроек привилегиями, который может получить у пользователя настройки и применить их. Вот такой прослойкой и выступает NM.

Другим вариантом подобной прослойки является wicd (входит в поставку).

А что говорит?

lspci -s 02:00.0 -v | grep driver

что dhcpcd я тоже зря рубил, да?

что значит рубил? Убивал? Зависит от...

Клиент DHCP, используемый в NM, задается в настройках последнего, см. /etc/NetworkManager/NetworkManager.conf, секция [main], параметр dhcp. Если там dhcpcd (может быть также dhclient, подробнее в man NetworkManager.conf), то NM будет для обслуживания конкретного интерфейса запускать экземпляр dhcpcd. Если NM не отслеживает, жив ли запущенный им экземпляр dhcpcd, то не зря. Но если правильно путаю, он отслеживает и перезапускает его, в логах это точно видно...

lspci умеет правильно интерпретировать односимвольные параметры, поэтому можно писать lspci -vs 2:0.0. А чтобы не выгрепывать нужное, достаточно сразу попросить только необходимое:lspci -ks 2:0.0.

Спасибо, очень полезная информация.

Cпасибо за ответы, я спросил потому как nm так и не смог в своё время завести для сети (плюнул, удалил и в конфиге прописал что нужно), зато с wicd впоследствии всё заработало без приключений.

Скажем так, в 14.1 это один из штатных вариантов настройки сети, из предлагаемых штатным же # netconfig, настраивать стало намного проще :-) Правда на нужность его в системе это не повлияло от слова совсем ;-)

Можно еще обновить NM, в последних версиях он научился уважать ручные настройки.

а можно ещё вопрос к Гуру?:) я понимаю что тема избита, bash: в терминале можно научить выводить в строке текущее местодостижение cd /каталог ? или вообще не стоит с этим заморачиваться, привыкнуть и все?

добавь в ~/.bash_profile

[ `id -un` = root ] && PS1="(\w)\n\u@\h# " || PS1="(\w)\n\u@\h$ "

то есть строка вместо строки в терминале:

bash-4.2#

root:/текущий_каталог

спасибо, но наверное в .bashrc её впендюрить нужно, работает:)

bash: в терминале

Пару слов про то, почему так.

bash имеет 2 режима запуска: как регистрирующая оболочка (login shell) или нет. В первом случае при старте исполняются профильные сценарии (/etc/profile, зовущий в свою очередь сценарии из /etc/profile.d/*.sh, затем ~/.bash_profile, ~/.bash_login и ~/.profile), во втором — ~/.bashrc, подробнее см. в man bash.

За содержимое приглашения отвечают переменные PS*, конкретно за начальное приглашение — PS1, поддерживается вывод различной информации при помощи ключей, подробнее см. man bash.

В Slackware в профильных сценариях есть установка значения PS1, недавно вынесена в отдельный файл в profile.d/, до этого была в /etc/profile. Файлов ~/.bashrc по умолчанию нет.

Терминал обычно запускает bash в режиме нерегистрирующей оболочки.

Возможных решений больше одного: вписать задание PS1 в ~/.bashrc или в вызываемый из него файл, либо указать терминалу запускать bash в режиме регистрирующей оболочки (ключ -l в команде запуска bash или галка в настройках, зависит от терминала).

установка значения PS1, недавно вынесена в отдельный файл в profile.d/, до этого была в /etc/profile

Тут я неправ, спутал с добавлением в PATH текущего каталога для не-рута, см. /etc/profile.d/z-dot-in-non-root-path.sh.

Но поскольку сценарии в /etc/profile.d/ выполняются в самом конце /etc/profile, никто не мешает нам сделать задание вида строки в одном месте, например, в /etc/profile.d/prompt.sh

#!/bin/sh
PS1='\u@\h:\w\$ '
export PS1

# chmod a+x /etc/profile.d/prompt.sh

if [ -x /etc/profile.d/prompt.sh ]; then
  . /etc/profile.d/prompt.sh
fi

Если что-то преднастроенное должно копироваться в профиль новых пользователей, см. /etc/skel.