1

Обновился с 13.37  до current и наступил на несколько граблей:
1) При старте выдается предупреждение add_groups: invalid argument.
/etc/group остался старым, там прописано пользователь в wheel, plugdev, audio, bin, daemon, video,cdrom,disk,users.
Только действительно ли есть права вот вопрос. При монтировании разделов диска в KDE предлагается ввести пароль рута, чего раньше не наблюдадось.

2) Перестало работать монтирование самбы в /etc/fstab. В 13.37 работало так:
//host/share    /mnt/share    smbfs    credentials=/home/user/.smbcredentials,uid=1000    0    0
Вместо smbfs cifs не помогает.

2

1) как обновлялись? .new файлы были обработаны? Что говорит
# find /etc -name \*new

Нет ли пользователя с числом групп 16 или более?

3

# slackpkg update
# slackpkg install-new
# slackpkg upgrade-all
# slackpkg clean-system

При обновлении указал создавать new файлы:

# find /etc -name \*new
/etc/rc.d/rc.inet1.conf.new
/etc/rc_keymaps/pixelview_new

Да, у пользователя 20 групп в итоге указано в /etc/group

4

skyfoxss пишет:

пользователя 20 групп в итоге указано в /etc/group

Ок.
Значит, или сократить до 16 (или 15?), или поправить в исходниках и пересобрать пакет shadow.

5

Сократил число групп, предупреждение add_groups исчезло.
Только вот проблема с монтированием самбы осталась.
man mount говорит что smbfs поддерживается, хотя при монтировании из fstab говорит что не знает smbfs.

6 (28.06.2012 21:39:52 отредактировано bormant)

2) теперь про монтирование и самбу. Что говорят:
# mount -t smbfs -o credentials=/home/user/.smbcredentials,uid=1000 //host/share /mnt/share
# mount -t cifs -o credentials=/home/user/.smbcredentials,uid=1000 //host/share /mnt/share
# which mount.smbfs mount.cifs

7 (29.06.2012 11:30:43 отредактировано skyfoxss)

# mount -t smbfs -o credentials=/home/user/.smbcredentials,uid=1000 //host/share /mnt/share
mount: unknown filesystem type 'smbfs'
# mount -t cifs -o credentials=/home/user/.smbcredentials,uid=1000 //host/share /mnt/share
ничего, монтирует нормально
# which mount.smbfs mount.cifs
which: no mount.smbfs in (/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin)
/sbin/mount.cifs
cifs нашел, сейчас он прописан fstab
Могло ли 'smbfs'  устареть, работало же когдато. Или может новая самба виновата или нет какихто пакетов?
slackpkg search samba
[ installed ] - samba-3.6.5-i486-1

Думаю есть еще проблема что DHCP клиент не получает IP в момент монтирования (dhcpcd forked to background...), а каким то чудом получает его потом после запуска иксов. Но и в случае позднего получения IP в KDE должно быть автомонтирование (я так думаю) того что прописано в fstab если ткнули в соответствующую точку входа. А оно не работает.
Оговорка: Если войти из под root в KDE то монтирование cifs из проводника проходит нормально, поэтому собтвено вопрос с add_group и возник. На данный момент пользователь числится в следующих группах:
adm, disk, wheel, floppy,audio, video,cdrom,gdm,plugdev,power,netdev,users
Теоретически, если добавить пользователя в группу root можно добиться

8 (29.06.2012 12:30:26 отредактировано bormant)

1. smbfs vs. cifs
Речь о выкидывании smbfs в пользу cifs шла давно. Начиная с 2.6.25 было указано
CONFIG_SMB_FS: SMB file system support (OBSOLETE, please use CIFS). см.: http://cateee.net/lkddb/web-lkddb/SMB_FS.html

Если в 13.37

$ zgrep "SMB_FS=\|CIFS=" /proc/config.gz
CONFIG_SMB_FS=m
CONFIG_CIFS=m

то в нынешнем -current только:

$ zgrep "SMB_FS=\|CIFS=" /proc/config.gz
CONFIG_CIFS=m

2. dhcp

skyfoxss пишет:

Думаю есть еще проблема что DHCP клиент не получает IP в момент монтирования (dhcpcd forked to background...), а каким то чудом получает его потом после запуска иксов.

Неполучение ip легко проверяется, можно начать с изучения лога. Уход в бэкграунд -- это естественная часть функциональности dhcpcd, он хоть и клиентский, но демон, о на что недвусмысленно намекает окончание имени на "d".
Для ресурсов, зависящих от сети, принято в опции добавлять _netdev, подробнее в man mount.
Меняем в /etc/fstab smbfs на cifs, добавляем _netdev, проверяем, рассказываем.


ps. Уточните, у вас сеть настроена естественным образом в /etc/rc.d/rc.inet1.conf, поднятие сети вписано в /etc/rc.d/rc.local или её поднимает wicd/networkmanager?

9 (29.06.2012 13:18:13 отредактировано skyfoxss)

Сеть поднимает точно не /etc/rc.d/rc.local так как он пуст (одни комментарии).
Все по дефолту, я думаю Патрик не стал запускать NetworkManager по умолчанию.
В /etc/rc.d/rc.inet1 немного изменен вызов dhcp. Старые параметры DHCP убрал (из inet1.conf) чтобы иметь возможность регулировать параметр lease time. А именно прописана строка
/usr/sbin/dhcpcd eth0 -l 1200 -t 35
вместо
/sbin/dhcpcd ${1} -t ${DHCP_TIMEOUT[$i]:-10} ${DHCP_OPTIONS}

Но даже в этом случае (35 секунд таймаут) DHCP сервер не дает IP.
35 секунд думает, потом включает IPv4LL который ему дает неверный адрес. Интересно, что потом после старта иксов этот адрес меняется на правильный.

10 (29.06.2012 14:27:46 отредактировано bormant)

Можно было чуть изящнее. Дописать в /etc/rc.d/rc.inet1 рядом с установкой прочих опций что-то вроде:

        [ ${DHCP_LEASE[$i]} ] && DHCP_OPTIONS="$DHCP_OPTIONS -l ${DHCP_LEASE[$i]}"

а в /etc/rc.d/rc.inet1.conf добавить:

DHCP_LEASE[0]="1200"

Но это косметика, на суть проблемы не влияет...

IPv4LL можно запретить, но на суть проблемы это тоже не повлияет:

DHCP_NOIPV4LL[0]="yes"

А вот на что действительно стоит обратить внимание -- это использование для сетевой карты правильного драйвера и причины, по которым к моменту запуска клиента dhcp невозможно получить ответ сервера dhcp. Возможно, кто-то мешает получить настройки, например, демон wicd/networkmanager.


ps. Что выдаст, если загрузиться в 3 уровень, залогиниться root-ом и выполнить

# killall dhcpcd
# dhcpcd -l 1200 eth0

В /var/log/messages ничего подозрительного не наблюдается?

11

Еще про dhcpcd.
Выяснилось что клиент получает IP только со второго запуска.
А именно первый раз запускаем из rc.inet1:

#dhcpcd eth0 -l 1200 -t 30
  c любыми параметрами, ждет положенный таймаут (висит на broadcasting for a lease) +8 секунд для IPV4LL
В этот момент получен неверный IP от IPV4LL, при незагруженных иксах сеть не доступна. 

Затем второй раз:
#dhcpcd  eth0 --release
dhcpcd eth0 -l 1200 -t 30
Не висит, получает IP сразу, сеть доступна.
Чем объяснить такое поведение? Видимо dhcp сервер надо уговаривать как женщину...

12 (29.06.2012 15:18:27 отредактировано bormant)

Кривоватый драйвер сетевой карты?

Если в /etc/rc.d/rc.inet1.conf добавить
DEBUG_ETH_UP="yes"
ничего подозрительного не появится в выводе?

Оно себя одинаково ведёт при
killall dhcpcd; dhcpcd eth0
и
/etc/rc.d/rc.inet1 eth0_restart
? Если затыкается только во втором случае, возможно, где-то не хватает таймаута между ifconfig и dhcpcd... Тут только метод проб и ошибок, к сожалению.


Кривоватый сервер DHCP? Тут бы посмотреть, пакет от клиента уходит? До сервера доходит?


ps. Как вариант, выгрузить драйвер сетевой карты и руками пройти путь от загрузки драйвера сетевой карты до получения адреса по dhcp и посмотреть, как оно.

# modprobe имя_драйвера
# ifconfig hw ether 00:11:22:33:44:55  # если нужен какой-то конкретный MAC
# dhcpcd --debug eth0

13

bormant пишет:

Кривоватый сервер DHCP? Тут бы посмотреть, пакет от клиента уходит? До сервера доходит?

Не кривой, но под windows :-)
А с windows dhcp на этой же машине проблем нет. Дискримминация.
С другой стороны Windows XP уже 12 лет не менялась, значит проблема все таки в linux.
А чем смотреть, wireshark?

14 (29.06.2012 16:48:47 отредактировано bormant)

Сначала на клиенте стоит глянуть дамп запросов:

# tcpdump -lenx -i eth0 -s 1500 port bootps or port bootpc

или сам факт

# tcpdump -len -i eth0 port bootps or port bootpc

Идентифицировать по MAC.

В природе есть ещё dhcpdump, но его нет в комплекте, нужно собирать/ставить самому.

Так с ручным подъемом как дела? А если до dhcpcd выдать "ifconfig eth0 up" ?

15

bormant пишет:

Оно себя одинаково ведёт при
killall dhcpcd; dhcpcd eth0
и
/etc/rc.d/rc.inet1 eth0_restart
?

Второй метод нормально поднимает сеть. А вот если сделать killall и заново запустить dhcpcd то снова затык.
В принципе можно пока остановиться на достигнутом
#dhcpcd eth0 $DHCP_OPTIONS
#dhcpcd --release eth0
#dhcpcd eth0 $DHCP_OPTIONS
Cо второго раза понимает.

Если будет время можно будет изучить работу DHCP клиентов по дампам

16

Ещё пара вопросов:
1) в 13.37 у dhcpcd подобное поведение было?
2) 13.37 была с обновлением до dhcpcd-5.2.12 или со стоковым dhcpcd-5.2.11 ?

17 (29.06.2012 21:27:43 отредактировано skyfoxss)

1)В 13.37 была такая проблема что не получает IP, для временного решения dhcpcd пришлось выставить таймаут 30 секунд, тогда работало. dhclient тоже получал IP только с таймаутом 25-30 секунд. Новый dhcpcd не хотел работать даже с большим таймаутом.
2) со стоковым, не обновлял
PS. Попробовал dhclient - получает IP с некоторым временем ожидания (20с)
dhclient -v eth0
Listening on LPF/eth0/48:5b:39:ad:90:7f
Sending on   LPF/eth0/48:5b:39:ad:90:7f
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPOFFER from 106.109.8.68
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 106.109.8.68
bound to 106.109.8.182 -- renewal in 20195 seconds.