Оно себя одинаково ведёт при
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 клиентов по дампам

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

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

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

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

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

        [ ${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 ничего подозрительного не наблюдается?

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

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

Неполучение 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?

Думаю есть еще проблема что 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 можно добиться

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

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

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

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

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