revup Сообщения

revup	# 10 лет, 5 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	Если речь идет о просмотре через браузер, то тут явно надо разбираться с бгмерзким флешплеером. “Эталонный” тест: скачать видео, например, с помощью DownloadHelper'а; проиграть это видео mplayer'ом в консоли; смотреть на предмет наличия сообщения вида ********************************************** Your system is too SLOW to play this! ********************************************** Possible reasons, problems, workarounds: - Most common: broken/buggy _audio_ driver - Try -ao sdl or use the OSS emulation of ALSA. - Experiment with different values for -autosync, 30 is a good start. - Slow video output - Try a different -vo driver (-vo help for a list) or try -framedrop! - Slow CPU - Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts, e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all. - Broken file - Try various combinations of -nobps -ni -forceidx -mc 0. - Slow media (NFS/SMB mounts, DVD, VCD etc) - Try -cache 8192. - Are you using -cache to play a non-interleaved AVI file? - Try -nocache. Read DOCS/HTML/en/video.html for tuning/speedup tips. If none of this helps you, read DOCS/HTML/en/bugreports.html. Вообще, росмотр видео через мплеер и через флешплеер - две большие разницы.

# 10 лет, 5 месяцев назад

Сообщения: 28

Участник с: 29 декабря 2009

Если речь идет о просмотре через браузер, то тут явно надо разбираться с бгмерзким флешплеером.

“Эталонный” тест:

скачать видео, например, с помощью DownloadHelper'а;
проиграть это видео mplayer'ом в консоли;

смотреть на предмет наличия сообщения вида

************************************************
**** Your system is too SLOW to play this! ****
************************************************
Possible reasons, problems, workarounds:
- Most common: broken/buggy _audio_ driver
- Try -ao sdl or use the OSS emulation of ALSA.
- Experiment with different values for -autosync, 30 is a good start.
- Slow video output
- Try a different -vo driver (-vo help for a list) or try -framedrop!
- Slow CPU
- Don't try to play a big DVD/DivX on a slow CPU! Try some of the lavdopts,
e.g. -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all.
- Broken file
- Try various combinations of -nobps -ni -forceidx -mc 0.
- Slow media (NFS/SMB mounts, DVD, VCD etc)
- Try -cache 8192.
- Are you using -cache to play a non-interleaved AVI file?
- Try -nocache.
Read DOCS/HTML/en/video.html for tuning/speedup tips.
If none of this helps you, read DOCS/HTML/en/bugreports.html.

Вообще, росмотр видео через мплеер и через флешплеер - две большие разницы.

revup	# 10 лет, 5 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	2. Видео от nvidia. Не меняется яркость монитора… Хотя я ещё не углублялся в эту проблему но может кто то уже сталкивался? Попробуй smartdimmer

revup	# 11 лет, 4 месяца назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	Разобрался с aufs, все настроил, все работает ))). Спасибо за подсказку. ЕДИНСТЕННОЕ, что так и не нашел - как поступать с корневой ФС при выключнии?? В какой момент ее надо отмонтировать?? И надо ли вообще? Собственно, почему я задался этим вопросом, так это то, что остановка сервисов, обслуживающих nfs, приводит к паузе минут эдак в 2 с сообщениями: rpcbind: rpcbind server localhost not responding: time out И так несколько раз. Естественно, раздражает. Немного размышлений на тему. Как известно, при выключении корневая система перемонтируется в режим read-only: (где-то в глубинах /etc) mount -n -o remount,ro / Эта строчка выполняется последней перед выключением системы посредством вызова halt или reboot. А до этого необходимо выполнить множетсво других задач, среди которых есть отмонтирование сетевых ФС. Понятное дело, что в данном случае корневая ФС попадает под эту категорию. Вот и получается палка о двух концах. Если так посудить, то корень не должен быть отмонтирован до самого выключения, а значит в нашем случае по идее не должны быть остановлены такие службы, как rpcbind (portmap), rpc.statd и другие, не говоря уже о dhcpcd и т.п. С другой стороны, так как корень примонтирован в режиме read-only, то уже после отмонтирования других локальных и сетевых ФС можно уже просто выдернуть питание. Но это кагбэ не Ъ. Также отмечу, что несколько похожый вопрос был поднят здесь, на что один из мейнтейнеров дистра ответил: Thomas Bächler-3 This is known. If you have ideas, they are welcome. У кого какие мысли на этот счет?

revup

# 11 лет, 4 месяца назад

Темы: 4

Сообщения: 28

Участник с: 29 декабря 2009

Разобрался с aufs, все настроил, все работает ))). Спасибо за подсказку.
ЕДИНСТЕННОЕ, что так и не нашел - как поступать с корневой ФС при выключнии?? В какой момент ее надо отмонтировать?? И надо ли вообще?
Собственно, почему я задался этим вопросом, так это то, что остановка сервисов, обслуживающих nfs, приводит к паузе минут эдак в 2 с сообщениями:

rpcbind: rpcbind server localhost not responding: time out

И так несколько раз. Естественно, раздражает.

Немного размышлений на тему.
Как известно, при выключении корневая система перемонтируется в режим read-only:
(где-то в глубинах /etc)

mount -n -o remount,ro /

Эта строчка выполняется последней перед выключением системы посредством вызова halt или reboot. А до этого необходимо выполнить множетсво других задач, среди которых есть отмонтирование сетевых ФС. Понятное дело, что в данном случае корневая ФС попадает под эту категорию. Вот и получается палка о двух концах.

Если так посудить, то корень не должен быть отмонтирован до самого выключения, а значит в нашем случае по идее не должны быть остановлены такие службы, как rpcbind (portmap), rpc.statd и другие, не говоря уже о dhcpcd и т.п. С другой стороны, так как корень примонтирован в режиме read-only, то уже после отмонтирования других локальных и сетевых ФС можно уже просто выдернуть питание. Но это кагбэ не Ъ.

Также отмечу, что несколько похожый вопрос был поднят здесь, на что один из мейнтейнеров дистра ответил:

Thomas Bächler-3
This is known. If you have ideas, they are welcome.

У кого какие мысли на этот счет?

revup	# 11 лет, 5 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	Ай, хрен с ней, с этой NFSv4… Я тут немного подразобрался. Вообще с удаленным монтированием корня не все так просто. Загрузиться с удаленной машины и примонтировать корень не составляет особого труда. С моей точки зрения гораздо важнее понять, что делать дальше. Если в режиме rw, несмотря на все его недостатки, получается более-менее корректная работа (для меня нерешенным остался вопрос, как же все-таки корректно отмонтировать такой корень при выключении??), то для ro-корня я не нашел короткого обхода. Сама по себе работа с корнем в режиме read-only является нетривиальной задачей. Суть проблемы состоит в том, что некоторые части корня обязаны быть доступны для записи. В частности, это требуется для каталогов /etc и /var. Последний не содержит в себе файлов, необходимых для корректной загрузки системы и его можно примонтировать чуть позднее (наравне с /home), чего нельзя сказать о первом. Вот и получается замкнутый круг вида “драйвер для CD-ROM'а находится на прилагаемом диске”. Возможный обход - использование unionfs/aufs (например, как это описано здесь), как это делается на многих live-cd/usb. В общем, как тут на ваш взгляд лучше всего поступить?

revup

# 11 лет, 5 месяцев назад

Темы: 4

Сообщения: 28

Участник с: 29 декабря 2009

Ай, хрен с ней, с этой NFSv4… Я тут немного подразобрался.
Вообще с удаленным монтированием корня не все так просто. Загрузиться с удаленной машины и примонтировать корень не составляет особого труда. С моей точки зрения гораздо важнее понять, что делать дальше. Если в режиме rw, несмотря на все его недостатки, получается более-менее корректная работа (для меня нерешенным остался вопрос, как же все-таки корректно отмонтировать такой корень при выключении??), то для ro-корня я не нашел короткого обхода.

Сама по себе работа с корнем в режиме read-only является нетривиальной задачей. Суть проблемы состоит в том, что некоторые части корня обязаны быть доступны для записи. В частности, это требуется для каталогов /etc и /var. Последний не содержит в себе файлов, необходимых для корректной загрузки системы и его можно примонтировать чуть позднее (наравне с /home), чего нельзя сказать о первом. Вот и получается замкнутый круг вида “драйвер для CD-ROM'а находится на прилагаемом диске”.

Возможный обход - использование unionfs/aufs (например, как это описано здесь), как это делается на многих live-cd/usb.

В общем, как тут на ваш взгляд лучше всего поступить?

revup	# 11 лет, 9 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	Честно говоря, не очень изящный способ, уж слишком искусственный. Надо как-нибудь добиться того, чтоб корень корректно отмонтировался при завершении работы.

revup	# 11 лет, 9 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	_AND_ …Впрочем, я на это успешно забил - по NFSv3 все работает прекрасно. А у меня вот не работает ((. Точнее работает, но совсем не прекрасно. А именно, во время завершения работы система останавливается на этапе отмонтирования корня со словами umount.nfs: resource / is busy и дальше ни в какую. Но это если корень монтируется в режиме rw. В режиме ro много мата при загрузке, но при выключении все проходит гладко. Мои экспорты я указал выше. Подскажи идейку, че не так? И приведи пример своих настроек. Кстати, кому уж так хочется получить корень под NFSv4 могу посоветовать попробовать его перемонтировать из NFSv3 в уже загруженной системе. У меня получилось примонтировать “новый v4” корень, однако отмонтировать “старый v3” - нет, с той же ошибкой: umount.nfs: resource / is busy. Возможно, к корню надо применять более изощренные приемы перемонтирования, чем к обычным каталогам. К примеру, здесь описано как это делает initrd. Можно попытаться сделать по аналогии. Но мне кажется, легче с NFSv3 разобраться.

revup

# 11 лет, 9 месяцев назад

Темы: 4

Сообщения: 28

Участник с: 29 декабря 2009

_AND_
…Впрочем, я на это успешно забил - по NFSv3 все работает прекрасно.

А у меня вот не работает ((. Точнее работает, но совсем не прекрасно. А именно, во время завершения работы система останавливается на этапе отмонтирования корня со словами

umount.nfs: resource / is busy

и дальше ни в какую.
Но это если корень монтируется в режиме rw. В режиме ro много мата при загрузке, но при выключении все проходит гладко. Мои экспорты я указал выше.
Подскажи идейку, че не так? И приведи пример своих настроек.

Кстати, кому уж так хочется получить корень под NFSv4 могу посоветовать попробовать его перемонтировать из NFSv3 в уже загруженной системе. У меня получилось примонтировать “новый v4” корень, однако отмонтировать “старый v3” - нет, с той же ошибкой: umount.nfs: resource / is busy.

Возможно, к корню надо применять более изощренные приемы перемонтирования, чем к обычным каталогам. К примеру, здесь описано как это делает initrd. Можно попытаться сделать по аналогии. Но мне кажется, легче с NFSv3 разобраться.

revup	# 11 лет, 9 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	Версия явы ни при чем. ls -al откуда запускаешь в студию и echo $CLASSPATH. Поясню. Ява русским по-английски пишет ... Exception in thread "main" java.lang.NoClassDefFoundError: autohaven ... что означает, что она не может найти где находится класс. Вероятно, игрушка запакована в jar архив. Тогда необходимо сказать яве, что класс main находится в архиве. Еще одна возможная причина ошибки - отсутствие в переменной CLASSPATH текущего каталога (“.”).

revup

# 11 лет, 9 месяцев назад

Темы: 4

Сообщения: 28

Участник с: 29 декабря 2009

Версия явы ни при чем. ls -al откуда запускаешь в студию и echo $CLASSPATH.
Поясню. Ява русским по-английски пишет

...
Exception in thread "main" java.lang.NoClassDefFoundError: autohaven
...

что означает, что она не может найти где находится класс.
Вероятно, игрушка запакована в jar архив. Тогда необходимо сказать яве, что класс main находится в архиве. Еще одна возможная причина ошибки - отсутствие в переменной CLASSPATH текущего каталога (“.”).

revup	# 11 лет, 9 месяцев назад (отредактировано 11 лет, 5 месяцев назад)
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	По-видимому, никак. Сам сейчас над этой проблемой думаю. Похоже, что ядро не может монтировать по сети nfs4. В доках к ядру про nfs4 ни слова. Кроме того, как я заметил, именование путей при монтировании nfs4 и nfs отличаются. А именно, в nfs принято асолютное именование (необходим полный путь к каталогу на сервере), в то время как nfs4 требуется именно относительный путь (коренем является та директория, у которой fsid=0 (вроде как то так??)) К примеру, на сервере: $ cat /etc/exports ... /export (rw,no_subtree_check,no_root_squash,fsid=0) /export/diskless (rw,no_subtree_check,no_root_squash,nohide) /export/diskless/192.168.1.101 (rw,no_subtree_check,no_root_squash,nohide) На клиенте: $ sudo mount -t nfs 192.168.1.99:/export/diskless/192.168.1.101 /mnt/ $ sudo mount -t nfs4 192.168.1.99:/diskless/192.168.1.101 /mnt/ Эти команды монтируют один и тот же* каталог, но версии nfs различны. В то же время $ sudo mount -t nfs4 192.168.1.99:/export/diskless/192.168.1.101 /mnt/disk_1GB/ mount.nfs4: mounting 192.168.1.99:/export/diskless/192.168.1.101 failed, reason given by server: No such file or directory Получается, что у v3 и v4 еще и разные способы именования каталогов. Теперь про сетевую загрузку. На сервере имеем $ cat pxelinux.cfg/default ... KERNEL /boot/vmlinuz26 APPEND initrd=/boot/kernel26.img nfsroot=192.168.1.99:/diskless/192.168.1.101 ip=dhcp Отмечу, что сетевой адрес в формате для nfs4. Параметры root=/dev/nfs и rootfstype=nfs ни на что не влияют (а про последний в доках к ядру даже нет упоминания). Загрузка останавливается с ошибкой на этапе монтирования корня, вываливаясь в “спасительную” консоль. Попытавшись из этой консоли что-нибдуь примонтировать, я пришел к следущим результатам: без проблем монтируeтся $ nfsmount 192.168.1.99:/export/diskless/192.168.1.101 /test_dir $ mount ... 192.168.1.99:/export/diskless/192.168.1.101 on /test_dir type nfs (...,vers=3,...) Однако, $ mount -t nfs4 192.168.1.99:/diskless/192.168.1.101 /test_dir mount: mounting 192.168.1.99:/diskless/192.168.1.101 on /test_dir failed: Invalid argument $ nfsmount 192.168.1.99:/diskless/192.168.1.101 /test_dir mount call failed - server replied: Permission denied В заключение отмечу, что при $ cat pxelinux.cfg/default ... KERNEL /boot/vmlinuz26 APPEND initrd=/boot/kernel26.img nfsroot=192.168.1.99:/export/diskless/192.168.1.101 ip=dhcp все загружается без проблем и монтируется через nfs v3. Подытоживая все вышесказанное, прихожу к выводу, что на текущий момент средствами initrd примонтировать корневую файловую систему через nfs4 невозможно. P.S. Надеюсь, конечно, что это поспешный вывод и изрядное ковыряние в initrd сможет разрешить указанную проблему. P.P.S. Фигушки, не решит)) Оно вроде и понятно: NFSv4 требует запуещенного idmapd, а значит и примонтировать вообще что-либо на незагруженной системе не получится.

revup

# 11 лет, 9 месяцев назад (отредактировано 11 лет, 5 месяцев назад)

Темы: 4

Сообщения: 28

Участник с: 29 декабря 2009

По-видимому, никак. Сам сейчас над этой проблемой думаю.
Похоже, что ядро не может монтировать по сети nfs4. В доках к ядру про nfs4 ни слова.
Кроме того, как я заметил, именование путей при монтировании nfs4 и nfs отличаются. А именно, в nfs принято асолютное именование (необходим полный путь к каталогу на сервере), в то время как nfs4 требуется именно относительный путь (коренем является та директория, у которой fsid=0 (вроде как то так??))
К примеру, на сервере:

$ cat /etc/exports
...
/export                         *(rw,no_subtree_check,no_root_squash,fsid=0)
/export/diskless                *(rw,no_subtree_check,no_root_squash,nohide)
/export/diskless/192.168.1.101  *(rw,no_subtree_check,no_root_squash,nohide)

На клиенте:

$ sudo mount -t nfs 192.168.1.99:/export/diskless/192.168.1.101 /mnt/
$ sudo mount -t nfs4 192.168.1.99:/diskless/192.168.1.101 /mnt/

Эти команды монтируют один и тот же каталог, но версии nfs различны. В то же время

$ sudo mount -t nfs4 192.168.1.99:/export/diskless/192.168.1.101 /mnt/disk_1GB/
mount.nfs4: mounting 192.168.1.99:/export/diskless/192.168.1.101 failed, reason given by server:
  No such file or directory

Получается, что у v3 и v4 еще и разные способы именования каталогов.

Теперь про сетевую загрузку.
На сервере имеем

$ cat pxelinux.cfg/default
...
KERNEL /boot/vmlinuz26
APPEND initrd=/boot/kernel26.img nfsroot=192.168.1.99:/diskless/192.168.1.101 ip=dhcp

Отмечу, что сетевой адрес в формате для nfs4. Параметры root=/dev/nfs и rootfstype=nfs ни на что не влияют (а про последний в доках к ядру даже нет упоминания).
Загрузка останавливается с ошибкой на этапе монтирования корня, вываливаясь в “спасительную” консоль. Попытавшись из этой консоли что-нибдуь примонтировать, я пришел к следущим результатам:
без проблем монтируeтся

$ nfsmount 192.168.1.99:/export/diskless/192.168.1.101 /test_dir
$ mount
...
192.168.1.99:/export/diskless/192.168.1.101 on /test_dir type nfs (...,vers=3,...)

Однако,

$ mount -t nfs4 192.168.1.99:/diskless/192.168.1.101 /test_dir
mount: mounting 192.168.1.99:/diskless/192.168.1.101 on /test_dir failed: Invalid argument
$ nfsmount 192.168.1.99:/diskless/192.168.1.101 /test_dir
mount call failed - server replied: Permission denied

В заключение отмечу, что при

$ cat pxelinux.cfg/default
...
KERNEL /boot/vmlinuz26
APPEND initrd=/boot/kernel26.img nfsroot=192.168.1.99:/export/diskless/192.168.1.101 ip=dhcp

все загружается без проблем и монтируется через nfs v3.

Подытоживая все вышесказанное, прихожу к выводу, что на текущий момент средствами initrd примонтировать корневую файловую систему через nfs4 невозможно.

P.S. Надеюсь, конечно, что это поспешный вывод и изрядное ковыряние в initrd сможет разрешить указанную проблему.
P.P.S. Фигушки, не решит)) Оно вроде и понятно: NFSv4 требует запуещенного idmapd, а значит и примонтировать вообще что-либо на незагруженной системе не получится.

revup	# 12 лет, 5 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	Мда, печально.. Nebulosa А если в PKGBUILD убрать зависимость avahi и скомпилировать как нужно, затем повесить игнорирование на этот пакет, работает и ладно. На самом деле, новая версия может и не собраться. Тут даже получается не только в libcups дело. Это авахи тянет за собой dbus, который в свою очередь НЕПОНЯТНЫМ образом зависит от dbus-core>=1.2.24 и libx11. Dbus - хрен с ним, он вроде как нужен пресловутому авахи - в дебиане, как было замечно, именно так. Кстати, дебиановский dbus, насколько я углядел, не тянет за собой граф. пакетов. Получается, сразу в 2х местах накручено: и авахи у либкапса, и дбас у либх11 Amigo Значит надо настучать Andreas Radke в бубе^W багтрекер. Если для работы cups не требуется avahi… С багтракером придется немного подождать, у меня ща нет времени с этим разбираться. Где же ты, система мечты)))

revup

# 12 лет, 5 месяцев назад

Темы: 4

Сообщения: 28

Участник с: 29 декабря 2009

Мда, печально..

Nebulosa
А если в PKGBUILD убрать зависимость avahi и скомпилировать как нужно, затем повесить игнорирование на этот пакет, работает и ладно.

На самом деле, новая версия может и не собраться.

Тут даже получается не только в libcups дело. Это авахи тянет за собой dbus, который в свою очередь НЕПОНЯТНЫМ образом зависит от dbus-core>=1.2.24 и libx11. Dbus - хрен с ним, он вроде как нужен пресловутому авахи - в дебиане, как было замечно, именно так. Кстати, дебиановский dbus, насколько я углядел, не тянет за собой граф. пакетов.

Получается, сразу в 2х местах накручено: и авахи у либкапса, и дбас у либх11

Amigo
Значит надо настучать Andreas Radke в бубе^W багтрекер. Если для работы cups не требуется avahi…

С багтракером придется немного подождать, у меня ща нет времени с этим разбираться.

Где же ты, система мечты)))

revup	# 12 лет, 5 месяцев назад
Темы: 4 Сообщения: 28 Участник с: 29 декабря 2009	Сегодня попытался обновиться pacman -Syu помимо всего прочего, в списке обновляемых пакетов откуда-то НЕОЖИДАННО появились dbus-core-1.2.24-1 xcb-proto-1.6-1 xproto-7.0.16-1 libxdmcp-1.0.3-1 libxau-1.0.5-1 libxcb-1.5-1 kbproto-1.0.4-1 libx11-1.3.3-1 dbus-1.2.24-1 avahi-0.6.25-3 libcups-1.4.2-5 Больше всего пугает наличие dbus, libx11 и прочие, связанные с графическим интерфесом. Дело в том, что на этой машине не то, что монитора и клавиатуры, даже видеокарты нет - она управляется удаленно. Оказалось, что последний пакет libcups имеет в зависимостях avahi - вот он то и тянет за собой все остальное. Ладно, наличие libcups (при условии отсутствия принтера в принципе) я еще потеплю, как необходимость для samba. Но зачем еще понадобилсь вышеуказанные пакеты, я не пойму. Не объясните, что за непонятные зависимости, или я просто чего-то не понимаю?? PS. конечно, ясно, что эти пакеты ничего не весят и можно “просто не парится”, но рас уж арч есть то, что мы из него делаем, так почему же не сделать все проще?

revup

# 12 лет, 5 месяцев назад

Темы: 4

Сообщения: 28

Участник с: 29 декабря 2009

Сегодня попытался обновиться pacman -Syu помимо всего прочего, в списке обновляемых пакетов откуда-то НЕОЖИДАННО появились

dbus-core-1.2.24-1  xcb-proto-1.6-1  xproto-7.0.16-1  libxdmcp-1.0.3-1  libxau-1.0.5-1  libxcb-1.5-1 
kbproto-1.0.4-1 libx11-1.3.3-1  dbus-1.2.24-1  avahi-0.6.25-3  libcups-1.4.2-5

Больше всего пугает наличие dbus, libx11 и прочие, связанные с графическим интерфесом. Дело в том, что на этой машине не то, что монитора и клавиатуры, даже видеокарты нет - она управляется удаленно.
Оказалось, что последний пакет libcups имеет в зависимостях avahi - вот он то и тянет за собой все остальное.
Ладно, наличие libcups (при условии отсутствия принтера в принципе) я еще потеплю, как необходимость для samba. Но зачем еще понадобилсь вышеуказанные пакеты, я не пойму.

Не объясните, что за непонятные зависимости, или я просто чего-то не понимаю??

PS. конечно, ясно, что эти пакеты ничего не весят и можно “просто не парится”, но рас уж арч есть то, что мы из него делаем, так почему же не сделать все проще?