проблемы с add_groups в Slackware current

Обновился с 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 не помогает.

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

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

# 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

"skyfoxss" написал:

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

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

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

# 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 можно добиться

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...), а каким то чудом получает его потом после запуска иксов.

Сеть поднимает точно не /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 который ему дает неверный адрес. Интересно, что потом после старта иксов этот адрес меняется на правильный.

Можно было чуть изящнее. Дописать в /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 ничего подозрительного не наблюдается?

Еще про 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 сервер надо уговаривать как женщину...

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

Если в /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

bormant написал:

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

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

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

# 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" ?

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 клиентов по дампам

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

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.