Чудо{вищные} заметки

После обновления ядра до версии 2.6.38.7 система стала работать нестабильно, переодически зависала на продолжительное время, решил не откатываться на предыдущее, не ждать милости Патрика, а собрать более свежее ядро руками (вспомнить молодость, ага).

Процесс прошёл на удивление быстро:

#"инструкция"
cd /usr/src/
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.1.8.tar.bz2
tar xfj linux-3.1.8.tar.bz2
rm -rf linux
ln -s /usr/src/linux-3.1.8 /usr/src/linux
cd /usr/src/linux
zcat /proc/config.gz > .config
make oldnoconfig
make menuconfig
make -j3 all
make modules_install
make install
cd /etc/rc.d
mv /boot/vmlinuz /boot/vmlinuz-3.1.8
ln -s /boot/vmlinuz-3.1.8 /boot/vmlinuz
mv /boot/System.map /boot/System.map-3.1.8
ln -s /boot/System.map-3.1.8 /boot/System.map
cp /usr/src/linux/.config /boot/config-3.1.8
rm /boot/config
ln -s /boot/config-3.1.8 /boot/config
mcedit lilo.conf
lilo
reboot

…а главное безболезненно – система загрузилась сразу.

Настал черёд пересобрать драйвера nvidia. В наличии имелся инсталлятор версии 275.09 – он работать отказался сославшись на то, что не может найти исходники ядра. Хорошо – скачал последнюю на данный момент сборку – 290.10, которая установилась без проблем. Но не тут-то было – xOrg не запустился ругнувшись:

NVIDIA: could not open the device file /dev/nvidia0 (Input/output error).
(EE) NVIDIA(0): Failed to initialize the NVIDIA GPU at PCI:1:0:0.  Please
(EE) NVIDIA(0):     check your system's kernel log for additional error
(EE) NVIDIA(0):     messages and refer to Chapter 8: Common Problems in the
(EE) NVIDIA(0):     README for additional information.
(EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device

И пошло-поехало…

• откатился до 285.05.09 – тоже самое
• последовательно перепробовал всевозможные опции ядру, которые удалось найти в “этих ваших интернетах” и noacpi и pci=biosirq и vmalloc=XXXm – без результата.
• перепробовал море разных опций модулю nvidia – без толку

И вот надежда уже погибла, xOrg работает через убогий nouveau и остаётся лишь “установить бубунту“ загрузить старое ядро (и собрать ему старые драйвера nvidia). Поудалял кучу старых инсталляторов и решил скачать (раз пошла такая пьянка) 275.28 и на всякий попробовал их собрать к свежему ядру. И что удивительно – получилось! всё заработало, на первый взгляд система стала шустрее, chrome с полусотней открытых табов больше не вводит иксы в транс. На днях попробую повторить операцию “хватить тупить” на другой машине

“Такой день” (ц)

После прочтения заметки о “странных кнопках ноутбука” сразу вспомнил о неработающем zoom-слайдере на клавиатуре Microsoft Microsoft® Digital Media Keyboard. Немедленно с помощью showkeys выяснил keycodes событий “слайдер вверх” – 418, слайдер вниз – 419. Перечитав ещё несколько раз заметку понял что мне она больше не поможет – xOrg в принципе не переваривает keycodes выше 255, ситуация казалось бы безвыходная, но оказалось не совсем, нашлось решение в виде evrouter – программы, которая (как видно из названия) “пробрасывает” события одних устройств на другие трансформируя согласно правилам описанным в конфигурационном файле.

После непродолжительных мытарств родился следующий ~/.evrouterrc:

#при нажатии на slider up на клавиатуре - сгенерируй событие "mousewheelup"
"Microsoft Microsoft® Digital Media Keyboard" "/dev/input/event.*" none key/418 "XButton/4"
#при нажатии на slider down на клавиатуре - сгенерируй событие "mousewheeldown
"Microsoft Microsoft® Digital Media Keyboard" "/dev/input/event.*" none key/419 "XButton/5"

Для получения необходимых прав в /dev/input в rc.local была добавлена строка:

# внимание - используйте на свой страх и риск! Слабо представляю какие подсистемы затронет такое наглое вмешательство в /dev
chgrp users /dev/input/event*

В ~/.kde/Autostart добавлен запуск /usr/bin/evrouter /dev/input/event*

Вы можете запускать evrouter через sudo (и не трогать права на /dev), но подозреваю, что с автозапуском могут быть проблемы…

После чего обнаружил что скроллинг работает, да совсем не так, как ожидалось – одно нажатие на слайдер прогручивает активное окно на три строки (как и указано в настройках KDE), но хотелось-то чтобы прокручивалось до тех пор пока слайдер не отпустишь… Снова поиск и снова решение (more…)

Встроенная камера ноутбука уже давненько определялась "через раз", был выработан целый шаманский обряд для её включения, но видимо я чем-то прогневил Великого Байта и последние месяцы камера совсем, что называется "отвалилась". Поэтому "случайно" посетив большой магазин с кучей техники, "случайно" же приобрёл usb-вебкамеру. Вопреки опасениям камера определилась и заработала (в skype) сразу же, без каких-либо танцев с драйверами, настройками, поиском anus-ware решений и т.п. дребеденью непременно сопровождающей подключение «любого» периферийного устройства в linux. Это не может не радовать!

После перезагрузки вдруг перестал работать звук в flash. Недлительное гугление рассказало о какой-то libflashsupport, которая немедленно поможет справиться с недугом, но внутренний голос пробасил что-то вроде «ты же не менял никаких настроек уже несколько недель». Что характерно – звук в amarok, vlc и skype работал исправно, но было замечено что в kmix первой закладкой было устройство под названием "USB Device 0x46d:0×825" вместо обычной "HDA Intel", которая стала второй. Запустил alsamixer – и точно, устройством по-умолчанию стала новоявленная карта, у которой даже и playback-а-то нет. Но видимых настроек у flash-player-а нет, поэтому надо было исправлять ситуацию "системно".

Поскольку уже имелся негативный опыт ковыряния с asound.conf(.asoundrc), то сразу стал искать способ либо переименовать устройства (вроде того, как переименовывают eth* правилами в udev) или определить порядок загрузки драйверов – лишь бы не трогать asound.

И способ нашёлся – в /etc/modprobe.d/sound.conf добавлены следующие правила:

options snd_hda_intel index=0
options snd_usb_audio index=1

После перезагрузки карты выстроились в порядке живой очереди:

$ cat /proc/asound/cards
 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xa5100000 irq 41
 1 [U0x46d0x825    ]: USB-Audio - USB Device 0x46d:0x825
                      USB Device 0x46d:0x825 at usb-0000:00:1d.7-5.4, high speed

Разрабатывать продукт в недра которого может влезть “чужой” непросто. Мы придумываем всяческие “неймспейсы”, давая файлам, директориям, переменным и классам псевдо-уникальные префиксы, пытаясь предотвратить коллизии с чужеродной средой.

Однажды, много лет назад, ко мне свалилась задача – размещение некой сложной формы на сторонних ресурсах. Очевидное и годами отработанное решение – iframe было забраковано, т.к. опыт и пятая точкашестое чувство подсказывали – как только владелец сайта разместит форму у себя, его светлую голову немедленно посетит мысль – “а как мне приделать перламутровые пуговицы?!”. Это, признаться, пугало – целыми днями верстать и раскрашивать незнакомым дядям и тётям одну и ту же страницу пятью миллионами способов? Нет, пристрелите меня семеро! Второй способ – разработать и задокументировать API, чтобы владелец ресурса сам разрабатывал себе форму, был отвергнут как трудозатратный, но совершенно нежизнеспособный так как рядовой клиент как правило (тут могло бы быть нечто оскорбительное про уровень интеллекта и радиус кривизны передних конечностей, но цензура не пропустит) не готов своими силами что-то создавать, тогда как продукт конкурента был проще в освоении (работал из коробки). Был выбран третий путь – размещение формы в виде html-разметки, которую мы отдаём заказчику, что называется “в руки”, а данные подгружаем через <script src="http://my-resource.example.com/?parameters"></script>, это позволяло владельцу ресурса до определённой степени контролировать внешний вид полученного документа и избавляло нас от трудозатратной кастомизации сотен инсталляций продукта. Но этот способ потенциально создавал много проблем, т.к. находясь в инородной среде наш документ мог “подхватить” незапланированные свойства, “заразится” чужими переменными и вообще рассыпаться в пыль в руках неуклюжего веб-мастера. Необходимо было тщательно изолировать всё и вся. Одним из способов отделить своё “добро” внутри документа было создание уникального “пространства имён”, например создание атрибутов в виде <div rpz:property="value"></div> – это самое rpz: давало надежду на то, что внешний скрипт(движок сайта или сам вебмастер) “случайно” не создаст аналогичный атрибут с другим value (или вовсе без него), развалив всю эту шаткую конструкцию. Решение оказалось рабочим во всех доступных графических браузерах и популяризировалось мной не только в этом продукте, но и повсеместно в других (печатая эти строки пытаюсь понять – зачем вообще нужны были именно атрибуты и почему их нельзя было заменить на переменные в скрипте, но разумного ответа почему-то не нахожу).

Это неоднозначное решение “выстрелило в ногу” только на днях – появился IE9… Невероятно быстр, ангельски красив, дьявольски умён – блеск, а не браузер На вид такой же унылый как все предыдущие В общем обзор новшеств можно наверное найти на сайте разработчиков, ну а я увидел его первый раз два дня назад, ничего хорошего про него сказать не могу, да и речь совсем не о том. Случись такое совпадение – сайт заказчика оказался настолько весь из себя валиден, что IE9 работал со страницей в своём новом document.documentMode. И чтобы вы думали? Точно! Годами отработанная “технология” дала сбой – “самодельные” атрибуты просто-напросто не видны на такой странице, а моя твёрдая уверенность в том, что они есть запретила здравому смыслу проверять их наличие… так и случаются epic fail-ы, так было и со мной.

Один грязный хак удалось временно залатать другим грязным хаком, но урок получен – недокументированная возможность это лишь “возможность”, строить на ней что-то прочное нельзя.

К слову сказать, не так давно вместо атрибута rpz:property="value", я начал использовать “документированную возможность” – атрибут data-rpz-property="value" и соответствующий вызов в js изменился с jQuery(selector).attr("rpz:property") на jQuery(selector).data("rpz-property") , видимо “шестое чувство” о чём-то подозревало…

В последнее время практически не слушаю музыку из локальной коллекции по причине описанной ранее. Но иногда запускаю и Amarok. И вот этот самый amarok начал чудить – останавливает проигрывание после каждого файла. Перерыл все настройки на предмет управление playback-ом, по многочисленным советам с разных убунтофорумов попробовал удалять все конфиги, перерыл багтрекер – все найденные баги были пофиксены несколько версий назад, всё безрезультатно, надежды нет и конец близок. Хоть бери да используй другой плеер…

Решение оказалось неожиданным – потребовалось сменить backend у phonon (кто бы мог подумать?!) с mplayer на xine, чтобы плеер перестал проказничать.

“Такой день.” (ц)

Экспериментируя с Plasma сильно-сильно уронил KDE. Роковое стечение обстоятельств – как раз перед этим обновил систему (в т.ч. и kde) и не успел рестартнуть сессию. Итого: утомительная многочасовая битва с мельницами, почти полностью утерянные настройки и эта чудо{вищная} заметка.

Симптомы были следующие: kde не стартует под пользователем, но прекрасно запускаются под root-ом.

startkde: Starting up...
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
kded(4946): Communication problem with  "kded" , it probably crashed.
Error message was:  "org.freedesktop.DBus.Error.ServiceUnknown" : " "The name org.kde.kded was not provided by any .service files" " 

(4944)/ KStartupInfo::createNewStartupId: creating:  "${HOSTNAME};1283501102;250139;4944_TIME0" : "unnamed app"
startkde: Shutting down...
klauncher: Exiting on signal 1
startkde: Running shutdown scripts...
startkde: Done.

Незамедлительно был сделан вывод: что-то “пришло” в обновлённых пакетах, как назло недоступен slackware.com (нет, ну вы подумайте – всё вот так вот разом, а?). Был перелопачен /etc на предмет разного рода изменений в правах доступа. Затем в /dev/null один за одним полетели файлы из $HOME, /tmp и т.п. Удалил весь $HOME, создал девственно чистый – ничего. Начинала свербить мысль – а может остаться под root-ом…. ?!

Решение как всегда оказалось простым и ожиданным. Позабыл удалить /var/tmp/kdecache-$USER. Уже не первый раз сталкиваюсь и не последний раз забываю начать именно с этого.

P.S.
Вот на кой ляд половина хлама падает в /tmp, а другая в /var/tmp ?

Крайне странно что раньше я не замечал по-умолчанию директива use-commit-times ВЫКЛЮЧЕНА!.

Включить, понятное дело, можно настройкой в конфиге ~/.subversion/config.

Ну или в cli добавив параметр –config-option=config:miscellany:use-commit-times=yes