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

В прошлой статье о переезде с 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 начинает писать диски.