Собираем
информацию
по крупицам

Linux: как перестать удивляться, и начать работать

Lenny -> Squeeze. Что еще может отвалиться?
06-02-2011
01:08:27

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

 

В прошлой статье о переезде с Debian Lenny на Squeeze мы узнали, что при апдейте системы может перестать работать:

 

  • Загрузка с GRUB
  • Старт опрерационки на LCD мониторе
  • Перестаёт работать компиляция графических драйверов nVidia
  • Отваливается вывод звука через SBLive! 5.1 

 

Что еще может перестать работать? У меня возникло много мелких неполадок, которые решались достаточно просто, а некоторые до сих пор не решены (например, перестал работать планшет Wacom). Но было две проблемы, на решение которых ушел почти месяц времени. Вот они:

 

  • Перестает работать буфер обмена в KDE
  • Новое ядро не видит привод CD/DVD-Rom 

 

Случайно зашедших сюда пользователей Windows и MacOS наверно передёрнуло от того, что такие вещи могут случаться. Но опытные пользователи линукса знают, что в свободной операционке это обычное дело. Они всегда готовы потратить свое личное время и угробить здоровье недосыпанием, чтобы разобраться, как же привести систему в божеский вид. Уподобимся же и мы красноглазам, и разберемся, как исправлять эти досадные недоделки.

 

 

Восстановление правильной работы буфера обмена в KDE4

 

Парадоксально, но факт: толпы линксоидов не замечает, как глючит буфер обмена в их любимом Squeeze. Тут сразу возникает вопрос: а что они вообще делают за компьютером? Смотрят кино, слушают музыку и лазают в интернете? По всей видимости, только этим и занимаются. Но мы стремимся использовать компьютер по прямому назначению, поэтому сразу замечаем проблемы с буфером, и понимаем, что так работать нельзя.

 

 

В чем же состоит проблема? Все просто: данные в буфере обмена исчезают, когда закрывается программа, из которой эти данные были получены. Это касается любых данных, даже обычного текста. Точнее, данные не теряются, а становятся временно недоступными. Чтобы сделать операцию Paste, нужно в Klipper активировать последнюю скопированную строку.

 

 

Это безобразие происходит при включенном менеджере буфера обмена Klipper, даже если включена галочка "Не допускать пустого буфера обмена".

 

Интересно, что такого поведения не наблюдается в более старой ветке Lenny, и не наблюдается в более новой ветке Sid. Мы попадаем в какую-то локальную флуктуацию, в которой буфер обмена преподносит нам свои сюрпризы.

 

Итак, перепробовав несколько способов решения (устанавливал другие версии Klipper, пересобирал Klipper из исходников, собирал из исходников GTK-шный Percellite - глюки те же), я наконец нашел решение, которое меня частично устроило. Это решение - собрать из исходников небольшой GTK+ менеджер буфера обмена ClipIt v.1.3.11. С ним буфер обмена четко хранит все данные, которые в него попадают.

 

Скачиваем ClipIt с SF.net: http://sourceforge.net/projects/gtkclipit/. Запускаем последовательно команды configure, make, checkinstall -D (или make install, если уж следовать документации). На этапе configure и make смотрим на консольный вывод и доустанавливаем dev-пакеты, которых не хватает.

 

Далее выключаем Klipper, и подтверждаем, что его не нужно включать при следующем запуске. В консоли выполняем команду clipit, и новый менеджер буфера обмена запустится. Убеждаемся, что данные сохраняются в буфере даже при закрытии программы, в которой они были скопированы. В настройках "Параметры системы" -> "Автозапуск" добавляем вызов /usr/local/bin/clipit. Перегружаем KDE4, и убеждаемся, что теперь можно по-человечески работать с буфером обмена.

 

Почему же это решение меня устроило только частично? Ну, потому, что я люблю, когда все работает правильно. ClipIt выполняет свою функцию, но вот правильно отрисовать себя в системном трее KDE4 может через раз. Поэтому я от случая к случаю вижу такую картинку:

 


Красивого мало, но что поделаешь - это линукс.

 

Что делать, если новое ядро не видит привод CD/DVD-Rom

 

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

 

Итак, привод CD/DVD-Rom, который без вопросов работал в Lenny, перестал определяться в Squeeze. Виной всему ядро 2.6.32-5-686, в котором разломали программный сброс команд АТА-контроллеров. Так что если у вас имеется IDE-шлейф, и на нем висит винчестер с CD/DVD-Rom, готовьтесь.

 

"Кто же так делает?" - возмутится матерый железячник, - "Вешать на один и тот же порт винчестер и CD-привод нельзя!". Ну, во-первых, если не беспокоит скорость работы, то можно. Во-вторых, на всех современных материнках наличествует только один IDE-порт. Так что тут как ни крути, а повесить IDE HDD и IDE CD/DVD-Rom на один контроллер всеравно придется. Или придется покупать новое SATA-оборудование. Мне потратить лишние 2000 руб на покупку железки только для того, чтобы удовлетворить прихоти обновленного ядра, не позволяет религия. Поэтому пришлось разбираться, как заставить работать CD/DVD-Rom в новых условиях.

 

Скажу сразу, что IDE HDD продолжал работать как прежде. Не работал только IDE CD/DVD-Rom. Это затормозило поиски решения, ибо поиск был направлен в русло устранения проблемм с CD/DVD-Rom, а нужно было искать решение проблем в работе с ATA-контроллером.

 

Внимательно изучив лог загрузки /var/log/kern.log, я увидел следующие повторяющиеся сообщения:

 

ata1: SRST failed (errno=-16)
ata1: link is slow to respond, please be patient (ready=0)
ata1: SRST failed (errno=-16)
ata1: link is slow to respond, please be patient (ready=0)

 

Долго мучал поисковик, но ничего лучше чем сообщения "и у меня тоже не работает!" не нашел. Пример:

 

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/220706

 

Потом наткнулся на сообщения некоего пользователя max6665, который задал вопрос http://unixforum.org/index.php?showtopic=94431, ему как всегда никто ничего не ответил, и он сам трое суток безрезультатно боролся с проблемой. У него CD/DVD-Rom не работал в Fedora Core 10 и Open SUSE 11. И при этом прекрасно работал в древнючих KNOPPIX 3.6 и ASP 9.2.

 

В общем, налицо была регрессия, а такие программно-аппаратные регрессии обычно решаются старым дедовским способом. Способ, известный со времен DOS и Windows-95, состоит в следующем:

 

 

Если два IDE-устройства не уживаются вместе на одном IDE-шлейфе, нужно у обоих переставить перемычки на режим Cable Select (сокращенно - CS), и посмотреть что получится. Часто устройства начинают работать как положено.

 

 

Не веря, что такой способ действительно поможет во втором десятилетии XXI века, я все же вооружился отвертками, достал винчестер и CD/DVD-Rom, переткнул на обоих перемычки в положение Cable Select (ранее на винчестере было установлено Master, а на CD/DVD-Rom - Slave). Включил компьютер - и о чудо! CD/DVD-Rom TEAK определился в Squeeze без вопросов! IDE HDD тоже работал как положено. В логе исчезли сообщения об ошибках.

 

Так что, если вы обнаружили ошибки вида "ata1: SRST failed (errno=-16)", знайте, что они решаются либо заменой ядра, либо заменой оборудования, либо аппаратными плясками вокруг ATA - контроллера.

 

* * *

 

Ядро увидело привод CD/DVD-Rom , и даже работает автомонтирование в KDE4. Значит ли это, что все проблемы решены? Нет.

 

При попытке посмотреть видеозапись на DVD-диске с помощью проигрывателя xine, мы увидим, что проигрывание DVD-дисков перестало работать. При попытке открыть DVD-диск будет выдаваться сообщение:

 

 

xine: cannot find input plugin for MRL [dvd:/]

xine: input plugin cannot open MRL [dvd:/]

 

 

 

 

Ошибки эти вроде бы указывают на то, что в системе нет библиотеки deCSS. Возможно, её и нету, однако не работают даже те диски, в которых нет CSS защиты, и которые нормально воспроизводились в Lenny. Так в чем же дело?

 

Дело в том, что в Squeeze, по непонятным причинам, DVD-Rom перестал монтироваться как /dev/dvd. Узнать, как начал называться DVD-Rom диск, можно с помощью команды mount:

 

 

# mount

...

/dev/sr0 on /media/KROT_2 type udf (ro,nosuid,nodev,uhelper=hal,uid=500)

 

 

 Далее, если вы уверены, что DVD-диск отныне всегда будет определяться как /dev/sr0, то можно сделать мягкую ссылку командой:

 

 

# ln  -s /dev/sr0 /dev/dvd

 

 

После чего xine начинает воспроизводить DVD-диски. Однако я не уверен, что после очередного обновления, DVD-диск не станет определяться как-нибудь по-другому. Так же, я не уверен, что наличие вручную созданного /dev/dvd не помешает какому-нибудь скрипту сделать нормальную настройку монтирования DVD в будующих обновлениях.

 

Поэтому, вместо создания ссылки, я просто прописал /dev/sr0 в найстройках xine: "Параметры" -> "Настройка" -> "Media" -> "Device used to DVD playback".

 

После вышеописанных действий воспроизведение DVD заработало.

 

* * *

 

Привод определяется, DVD-диски проигрываются. Значит ли это, что все проблемы с приводом решены? Нет. Попробуем записать что-нибудь на CD/DVD-диск с помощью стандартной KDE-утилиты K3b. Что, не получается? То-то и оно.

 

Программа K3b отлично видит привод, видит чистый диск в приводе и выдает о нём сервисную информацию. Можно даже добавить файлы для записи, но запись сделать невозможно. Почему? Потому что кнопка "Записать" остается неактивной.

 

Причина такого поведения в том, что при обновлении с KDE3 на KDE4 программа K3b обновляется с версии 1.x на 2.x, а обновление конфиг-файлов сделано не полностью корректным. В результате, K3b v.2.x не может правильно работать. Для исправления ситуации нужно в домашней директории пользователя удалить файл ~/.kde/share/config/k3brc. После этого K3b начинает писать диски.

 


К списку "Компьютерное"

Интересное на сайте


Система контроля версий GIT » Установка GIT и настройка GitHub: полное руководство (Windows, Linux)

Здесь описывается практическая часть вопроса использования Git - его установка и регистрация на сервере GitHub.com.    GitHub.com - это серв...


Классическая анимация » Прыгающая подушка

Оборудование: Pentium-IV, Wacom Graphire3 CTE-630 Среда: Flash 8 Год: 2005   Первая и, видимо, последняя попытка нарисовать мини-мультфильм по т...


Web - разработка » Пример простого Flash приложения на Action Script 3, компилируемого с помощью MXMLC

Недавно мне нужно было сделать небольшой SWF-ролик с парой кнопок и несколькими картинками. Так как мой основной рабочий инструмент - Linux, то и дела...

RSS подписка

Подпишитесь на новости сайта по RSS


О, смотри-ка какое хорошее место. Дайте два!

Внимание!

На этом сайте разрабатывается программа MyTetra и её родственные проекты.

Доступны к просмотру следующие базы знаний:

База Xintrea (1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18)

База Rarrugas (1, 2)

База Balas

База YellowRaven

База Yurons

База Lesnik757

База Shandor

База Sirrichar

 

Подробности на странице MyTetra Share.

 WebHamster.Ru
 Домик любопытного хомячка
Яндекс индекс цитирования
Почтовый ящик