На иксы, как понимаю.  Возможно, имеет прямое отношение к bug #22928.

Если убрать на загруженном клиенте /etc/X11/xorg.conf в сторонку, что получается?

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

извините, а причем здесь X server? перевесте это но то что создает xorg.conf

(In reply to comment #2)
> А как убрать, если под root на клиенте не войдёшь
Пожалуйста, подтверди получение и осознание ссылки:
http://www.altlinux.org/LTSP/TroubleShooting#root_login

(In reply to comment #3)
> извините, а причем здесь X server?
Извини, надо было чётче сразу написать (это по мотивам переписки почтой):
- есть ли эта видеокарта в *.xinf или что там надо? (а это к zerg@, видимо)
- работает ли она с драйвером nvidia нормально?
- заводятся ли с ней иксы без xorg.conf нормально?

> перевесте это но то что создает xorg.conf
Его создаёт ltsp-x11-autosetup, форкнутый от alterator-x11-0.13.8-alt0.M40.8 (далее того потащили на hal, сломались COM-мыши и пр.)

На скору руку можно попробовать сделать костыль -- если X-сервер высыпался при первой попытке старта, убрать xorg.conf.

Совсем без xorg.conf придётся также переделывать выставление разрешения (может быть актуально для CRT-дисплеев, на которых автоматом становится e.g. 1024x768@75, а лучше бы 800x600@85) -- к чему готовился, но чего до сих пор удалось избежать.

> Пожалуйста, подтверди получение и осознание ссылки:
http://www.altlinux.org/LTSP/TroubleShooting#root_login

Прочёл и осознал. Установил пароль root, вошёл. При попытке изменения — Readonly file system. При перемонтировании в rw — Device or resource busy. Какие есть ещё варианты?

(In reply to comment #5)
> Прочёл и осознал. Установил пароль root, вошёл. При попытке изменения —
> Readonly file system.
Это при попытке отредактировать /etc/X11/xorg.conf?

> При перемонтировании в rw — Device or resource busy.
> Какие есть ещё варианты?
См. вывод mount -- там стопка файлов точечно монтируется как rw tmpfs.  Т.е. править на месте либо удалять (либо размонтировать).

> Это при попытке отредактировать /etc/X11/xorg.conf?
Нет, переместить или удалить

> Т.е. править на месте либо удалять (либо размонтировать).
Вот и не выходит удалять.

(In reply to comment #7)
> > Т.е. править на месте либо удалять (либо размонтировать).
> Вот и не выходит удалять.
umount /etc/X11/xorg.conf (впрочем, boyarsh@ напомнил -- там hal нет и автоподъём без конфига, видимо, не получится)

И ещё -- если руками заменить vesa на nvidia, взлетаем?

(В ответ на комментарий №9)
> И ещё -- если руками заменить vesa на nvidia, взлетаем?

Если руками поменять с vesa на nvidia - то всё отлично, Х-ы стартуют, выставляется правильное разрешение, отсутствует баг с амароком.

Я тормоз -- дай-ка кусок lspci -vvvnn про эту карту, ну или перепиши PCI ID (на всякий с subid, не помню, что там в базе использовалось).  Кажется, база тоже форкалась...

Created attachment 4264 [details]
Вывод lspci на терминале

Так, теперь по порядку.  Ничего про PCI ID в этом форкнутом пакете нет.
Происходит вот что:

ltsp-x11-autosetup =>
 /usr/bin/x11_autosetup =>
  /usr/bin/video_autosetup =>
   /usr/lib/ltsp-x11-autosetup/vcscan => /usr/bin/systool
   /usr/lib/ltsp-x11-autosetup/vcdrv => /usr/share/hwdatabase/videoaliases/*.xinf

То есть "при чём тут X-сервер" -- ни при чём, а вот .xinf в xorg-drv-nv* должны содержать запись для того, что выдаст на этом тонком клиенте:

systool -b pci $(lspci -Dm | grep VGA | cut -f1 -d" ") -A modalias

2 cas: вытащишь?
2 shrek, zerg: добавите?

PS: на всякий -- nVidia Corporation ION VGA [10de:087d] [1b0a:0074]

$fgrep ION /usr/share/hwdatabase/videoaliases/*.xinf
/usr/share/hwdatabase/videoaliases/nvidia-190.42.xinf:alias pcivideo:v000010DEd0000087Dsv*sd*bc*sc*i* nvidia # ION
/usr/share/hwdatabase/videoaliases/nvidia-190.53.xinf:alias pcivideo:v000010DEd0000087Dsv*sd*bc*sc*i* nvidia # ION

Прошу mike@ и boyarsh@ обсудить статус этой ошибки, учитывая замечание zerg@

Должно быть достаточно проверить, присутствует ли kernel-modules-nvidia для текущего ядра на момент настройки при условии, что настройка производиться правильно и сервис x11presetdrv уже отработал до нее.

(В ответ на комментарий №16)
> Должно быть достаточно проверить, присутствует ли kernel-modules-nvidia для
Да, только очень уж он старый -- 185
Думаю, что в этом и дело.

(В ответ на комментарий №17)
* Птн Сен 25 2009 Sergey V Turchin <zerg@altlinux.org> 185.18.36-alt70
- add 0x087D to .xinf (ALT#21688)

Если 185.18.36 более старый, то достаточно обновить его

(В ответ на комментарий №18)
> его
nvidia_glx_185.18.36

Если обновление потянет другие nvidia_glx_ -- ничего страшного. Используются те, для которых модули для текущего ядра есть.

Наблюдаю nvidia_glx_185.18.31-185.18.31-alt68 (сообразно kernel-modules-nvidia-tmc-tc-185.18.31-alt3.132635.6) -- сейчас попробую вспомнить, как там kernel-modules обновлять...

В бранчах 5.1/p5 на сегодня есть:
nvidia_glx_185.18.14-185.18.14-alt67.i586.rpm
nvidia_glx_185.18.31-185.18.31-alt68.i586.rpm
nvidia_glx_185.18.36-185.18.36-alt72.i586.rpm

В сизиф отправлен
kernel-modules-nvidia-tmc-tc-185.18.36-alt4.132635.8 (task #21559)

Если уж собирать новую версию модуля ядра, то на сегодня это 190.53 (в 195.36.08 нашли баги, поэтому ее пока не надо в дистрибутивы)

kernel-modules-nvidia-tmc-tc-185.18.36-alt4.132635.8

(In reply to comment #23)
> Если уж собирать новую версию модуля ядра, то на сегодня это 190.53
Хорошо, всё равно сегодня собрал 2.6.27-tmc-tc-alt9.

Завтра должно приехать в сизиф: kernel-modules-nvidia-tmc-tc-190.53-alt1.132635.9.

Просьба проверить.

(В ответ на комментарий №26)
> Завтра должно приехать в сизиф:
> kernel-modules-nvidia-tmc-tc-190.53-alt1.132635.9.
> 
> Просьба проверить.

Михаил, хорошо бы одновременно собрать для 5.1, иначе много времени потеряем

kernel-*-tmc-tc в 5.1/p5 ещё копируется.  Предыдущие сборки так и попадали. :)

*** Bug 22928 has been marked as a duplicate of this bug. ***

(In reply to comment #23)
> Если уж собирать новую версию модуля ядра, то на сегодня это 190.53
Не знаю, как та 185, а с этой у меня на [Quadro NVS 210S/GeForce 6150LE] [10de:0245] в домашнем десктопе на 21" CRT по логам -- поднялись, вот только картинка отсутствует (в tty1 нормально переключаюсь, killall X => рестарт в то же).

Впопыхах забыл вытащить лог, а тестировать там сложно -- три интерфейса и мнения бутрома с initrd о том, с кого грузимся -- различаются; один раз успел переключить ;-)

Поскольку /lib/modules/`uname -r`/nVidia/ тоже r/o, что бы с этим делать для старых карт -- тоже не соображу.

(В ответ на комментарий №30)
> Поскольку /lib/modules/`uname -r`/nVidia/ тоже r/o, что бы с этим делать для
> старых карт -- тоже не соображу.
Зачем с ним что-то делать и для насколько старых?

(В ответ на комментарий №30)
> Не знаю, как та 185
С тех пор
http://www.nvidia.com/object/linux_display_amd64_190.42.html
http://www.nvidia.com/object/linux_display_amd64_190.53.html
было

(In reply to comment #31)
> > Поскольку /lib/modules/`uname -r`/nVidia/ тоже r/o, что бы с этим делать для
> > старых карт -- тоже не соображу.
> Зачем с ним что-то делать
Чтоб переключалка заработала -- сейчас-то симлинк указывает строго туда, куда на NFS.  Хотя это можно руками на сервере подогнать, конечно...

> и для насколько старых?
Те, что в поддержке как legacy -- e.g. TNT2 или MX440.

(В ответ на комментарий №33)
> (In reply to comment #31)
> > > Поскольку /lib/modules/`uname -r`/nVidia/ тоже r/o, что бы с этим делать для
> > > старых карт -- тоже не соображу.
> > Зачем с ним что-то делать
> Чтоб переключалка заработала -- сейчас-то симлинк указывает строго туда, куда
> на NFS.  Хотя это можно руками на сервере подогнать, конечно...

А добавить в /etc/default/ltsp-client-setup в copy_dirs="..." этот /lib/modules/`uname -r`/nVidia ?

(В ответ на комментарий №33)
> Те, что в поддержке как legacy -- e.g. TNT2 или MX440.
TNT2 не будет работать. 71.86.13 не работает с xorg из p5

(В ответ на комментарий №35)
> 71.86.13 не работает с xorg из p5
Хотя, могу ошибаться, т.к. я на более старом пробовал и уже давно, но вряд ли

(In reply to comment #34)
> А добавить в /etc/default/ltsp-client-setup в copy_dirs="..." этот
> /lib/modules/`uname -r`/nVidia ?
Этого мало: на ro /lib/modules/`uname -r`/modules.dep.temp обламывается
x11presetdrv -> /usr/libexec/X11/drvpre.d/nvidia -> depmod -a
(2 zerg: а там depmod -A не хватило бы, кстати?  и стоит ли обламываться при неудаче depmod или unlink старого симлинка nvidia.ko?)

(In reply to comment #36)
> > 71.86.13 не работает с xorg из p5
> Хотя, могу ошибаться, т.к. я на более старом пробовал и уже давно, но вряд ли
Постараюсь проверить завтра на свежую голову, сегодня уже слабо.  Вообще livecd туда ткну, чтоб не накладывалось местной специфики. :)

PS: пока заведение старых нвидий задокументировано методом сноса nvidia:
http://www.altlinux.org/LTSP/TroubleShooting#.D0.A1.D1.82.D0.B0.D1.80.D1.8B.D0.B5_NVIDIA

Created attachment 4303 [details]
TNT2 + nvidia 71.86 + xorg-1.7 == nope

Благодаря соседке удалось протестировать [RIVA TNT2/TNT2 Pro] [10de:0028]; результат на nvidia отрицательный, на nv (после рукоприкладства по сносу nvidia) -- положительный, до nuovo не дошло (не хватает dri).

Похоже, с нвидиевскими драйверами ничего сделать не светит:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543248#15

Выдержки из приложенного:

NVRM: loading NVIDIA Linux x86 Kernel Module  71.86.11  Thu Jun 25 18:30:16 PDT 2009

(II) Loading /usr/lib/X11/modules/drivers/nvidia_drv.so
dlopen: /usr/lib/X11/modules/drivers/nvidia_drv.so: undefined symbol: AllocateScreenPrivateIndex
(EE) Failed to load /usr/lib/X11/modules/drivers/nvidia_drv.so

TNT/TNT2 только nouveau, но для этого нужны xorg-server-1.8/mesa-7.8 и kernel-image-std-ng

Думаю, мы медленно спустимся с горы и планово сделаем это за лето, ну до 2011.
Но никак не за завтра.

"планово" читать как "лопата"

(В ответ на комментарий №39)
> 71.86.11
Этой версии уже лет 100. Ее вообще смысла проверять не было. Я писал про 71.86.13, но маловероятно, что там что-то изменилось в плане xorg, но вообще, они могут и исправить когда-нибудь.

Если что, 195.36.15 можно в дистрибутивы (уже в 5.1)

(еле откопал, пусть будет блокер на ltsp bug #15333)