Инструменты пользователя

Инструменты сайта



// ArchLinux, systemd, run-level 3, startx, udisks и монтирование

Столкнулся с ситуацией: после перехода к systemd и его logind внезапно отказались монтироваться флешки средствами udisks и udisks2. При этом на соседнем компьютере всё нормально. Разница при этом между ними только одна: на одном иксы запускаются через kdm, на другом - startx. Вот там, где используется startx монтирование и не работает.

В ходе разбора наткнулся на эпичный тред, где поттеринг пытается убедить, что нужно апдейтить startx: https://bugzilla.redhat.com/show_bug.cgi?id=820675

Но оставим этого человека альтернативной ориентации и вернёмся к нашим баранам. А бараны такие: заставить без костылей или минимум оных монтировать накопители средствами udisks/udisks2 на машине, где используется startx.

Для начала выясняем, а в чём собственно соль проблемы. Выясняется, что когда мы запускаем иксы, они захватывают отдельный терминал и переключают пользователя на него, тем самым мы как бы переключаемся из сессии, созданной при логине в консоли, и она становится неактивной. Новой сессии для иксов при этом не создаётся. В результате этого в выводе команды

loginctl show-session $XDG_SESSION_ID

видим такие строчки:

Active=no

При этом, изучая конфиги polkit, мы можем увидеть, что мы можем регулировать права доступа для монтирования для активной сессии, неактивной и для остальных. Отсюда вытекает первый вариант исправления ошибки (и первый костыльный): править конфиги polkit и разрешать доступы с неактивных сессий для операций монтирования.

Проблема метода очевидна: ближайшее обновление и нам нужно мержить, или менять снова. Не гут.

Второй метод, запустить иксы на том же терминале, на котором мы залогинились. К примеру, мы зашли с первой консоли, команда tty выдаёт следующее:

/dev/tty1

тогда, что бы запустить иксы на этой консоли нам нужно выполнить следующую команду:

startx -- vt1

И видим, что в выводе loginctl Active стал yes. Viva!

В таком варианте есть свой плюс: если заблокировать экран, допустим, с помощью xscreensaver, то мы не сможем переключиться на первую текстовую консоль и, нажав Ctrl-C, убить иксы и получить доступ к залогиненому аккаунту. Здесь же кроется и минус: подвисшую сессию оперативно не убьёшь, особенно, если она отказывается реагировать на Ctrl-Alt-BS. Плюс как-то не классически.

Как последний штрих, добавляем в ~/.bashrc следующее:

stx()
{
	local vt=$(fgconsole)
	startx -- vt$vt
}
alias startx='stx'

и продолжать пользоваться просто командой startx.

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

Как заключение: подобные изменения лишний раз подтверждают правило: работает - не трожь! Особенно если это касается системообразующих функций, систем загрузки и пр.

Материалы которые помогли мне разобраться:

// Mime тип для GPX

Столкнулся с тем, что в файловых менеджерах в уютненьком Арчике GPX файлы отображаются просто как «Документ XML», соответственно если назначишь для открытия какую программу, это распространяется на все XML файлы.

Выход: сделать описание Mime типа

Рассмотрю вариант индивидуальный для пользователя, общесистемно - домашнее задание.

Шаг первый, создаём файл $HOME/.local/share/mime/packages/application-gpx+xml.xml:

application-gpx+xml.xml
<?xml version="1.0" encoding="UTF-8"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
    <mime-type type="application/gpx+xml">
        <comment>Geoinformation data (waypoints, tracks and so on) in GPX format</comment>
        <glob-deleteall/>
        <glob pattern="*.gpx"/>
    </mime-type>
</mime-info>

Для ленивых, качаем в одну команду:

wget -O $HOME/.local/share/mime/packages/application-gpx+xml.xml http://htrd.su/wiki/_export/code/zhurnal/2012/07/07/mime_tip_dlja_gpx?codeblock=0

После чего выполняем команду:

update-mime-database $HOME/.local/share/mime

Усё.

Для быстрого просмотра удобна программа Viking, в Арчике есть в стандартных репозиториях.

// Набор для кросс-компиляции для Linux на ARM

Потребовалось сделать окружение для отстройки приложений для системы Linux, запущенной на платформе с процессором ARM.

Внутри есть eglibc, поэтому решено было попробовать сделать окружение с этой библиотекой Си, а не повсеместно используемой newlib.

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

Особо поразило мозг решение проблемы «кто первый: курица или яйцо?»

В результате получился набор правил для сборки окружение под ArchLinux (пакеты идут в порядке сборки):

Ну и несколько библиотек сразу в придачу:

// Новый GTK+ и падение Opera

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

$ opera

(opera:13093): Gtk-CRITICAL **: IA__gtk_widget_unrealize: assertion `GTK_IS_WIDGET (widget)' failed

(opera:13093): Gtk-CRITICAL **: IA__gtk_widget_is_toplevel: assertion `GTK_IS_WIDGET (widget)' failed
opera [crash logging]: CRASH!!
/usr/lib/opera/opera got signal SIGSEGV at address B6B26E77

Log was created here:
/var/tmp/crash20111110210615.txt
Убито

Для столкнувшихся с этой же проблемой в ArchLinux:

// ArchLinux: geda-gaf в community

Собственно - радость! :)

Там же теперь и разводчик pcb. Двойная радость!

К сожалению, утилита xgsch2pcb (менеджер проектов-интегратор gschem и pcb) до community ещё не добралась, но уже не плохо.

// Автомонтирование udev+udisks

Повторять весь текст не буду, авторство и так моё: http://groups.google.com/group/archlinux-ru/browse_thread/thread/33c0d288bd05823d

Тут как реминдер

// OpenSource #066

Вышел 66 выпуск электронного приложения к журналу «Системный администратор», а в нем и моя третья статья из цикла «Схемотехника в Linux с помощью gEDA», в которой рассмотрено создание условного обозначения компонент для gschem. Так же сделано небольшое отступление и рассказано о интеграции gschem и pcb при помощи менеджера проектов xgschm2pcb. В общем качаем и читаем: http://osa.samag.ru/get/OpenSource066.zip

// Arduino как программатор для контроллеров Atmel и сопутствующий софт

За последние дни окончательно убедился, что Arduino не просто игрушка, а настроящие ворота для начинающих постигать мир программирования микроконтроллеров Atmel.

К чему это я, а к тому, что плата Arduino может выступить в роли программатора для самостоятельных конструкций на контроллерах. Как минимум существует два варианта, про которые можно прочитать на сайте http://freeduino.ru: http://freeduino.ru/arduino/isp.html.

Меня больше заинтересовал вариант BitBang программатора, т.к. не нужно каждый раз заливать прошивку в Arduino, когда нужно прошить внешний контроллер. Кроме того, можно прошить сам контроллер в кроватке (допустим если вышел из строя, количество же циклов перезаписи ограничено или залить обновленный boot loader).

В статье выше сказано, что подходят не все платы, это верно, но главное, что бы это была USB плата и на ней был чип FT232R/FT232RL, а вот разьём X3 можно распаять и самому (как это сделал Я - при помощи олово-отсоса очистил отверстия, поставил планочку и пропаял).

Но на этом наши приключения не заканчиваются. Возникает вопрос - чем шить? Ведь BitBang («ножкодрыгание») это достаточно не стандартная для общепринятых API процедура. Соответственно этим нужно заниматься через специализированные библиотеки, коих под Linux я раскопал две для чипов от FTDI:

  • libftd2xx - закрытая (проприетарная) библиотека от производителя, есть в вариантах для i686 и x86_64 (и естественно для Windows), скачать можно тут: http://www.ftdichip.com/Drivers/D2XX.htm, там в же в архиве есть заголовочные файлы, а на сайте можно скачать PDF с руководтством программиста. Вообще, там же рекомендую скачать и документацию на саму микросхему FT232R/FT232RL и информацию про работу в BitBang режиме (дальше потребуется). Библиотека доступна в ArchLinux через AUR.
  • libftdi - библиотека с открытыми исходными кодами, из зависимостей только libusb, а так как последняя может быть собрана и для Windows, теоретически и данная библиотека тоже. Домашняя страница: http://www.intra2net.com/en/developer/libftdi/download.php, имеется так же в репозитории extra в ArchLinux.

Для первой библиотеки (libftd2xx), есть набор патчей для avrdude. На сайте FreeDuino есть ссылка на сборку для Windows. Я выложил в AUR правила для сборки последней версии avrdude с этими патчами: avrdude-serjtag (потому как патчи изначально родились в недрах проекта serjtag).

На сайте libftdi лежит патч для древней версии uisp, поэтому подумав, и потратив 1.5 дня сделал на основе патчей serjtag свой патч ftdi-bitbang-5.10-1.patch, который использует эту библиотеку. Проверил прошивая и устанавливая fuse-биты на ATTiny2313. Естественно сделал правила для сборки и поместил в AUR: avrdude-ftdi. Вариант, если нужно отстроить на архитектуру отличную от x86/x86_64 или если бинарная версия проприетарной библиотеки рушится на вашей системе (тем более, что обновлялась она с 2008 года).

Вот тут товарищ Di Halt более подробно рассказывает про программатор на такой же микросхеме, которая стоит на Arduino. Там он говорит об одной неприятной особенности: после прошивки не отпускается линия RESET и решает проблему аппаратно. Можете поступить так же, но оказалось что, что в исходных кодах avrdude достаточно добавить одну строчку - выставление высокого уровня на линии RESET перед закрытием порта и выходом. Патч делающий это для использования с libftd2xx и набором патчей serjtag можно поглядеть тут: http://aur.archlinux.org/packages/avrdude-serjtag/avrdude-serjtag/clean-reset-pin.diff. При сборке пакетов avrdude-serjtag и avrdude-ftdi изменения отраженные в этом патче уже применены, так что, счастливым обладателям ArchLinux достаточно просто собрать и поставить пакет :)

Немножно хотел бы остановиться на описании программатора в конфигурационном файле avrdude.conf, особенно назначение цифр для задания линий. Выглядит это примерно так:

#arduino duemilanove
programmer
  id    = "duemilanove";
  desc  = "FT232R Synchronous BitBang";
  type  = ft245r;
  miso  = 3;  # CTS X3(1)
  sck   = 5;  # DSR X3(2)
  mosi  = 6;  # DCD X3(3)
  reset = 7;  # RI X3(4)
;

programmer
  id    = "ft245r";
  desc  = "FT245R Synchronous BitBang";
  type  = ft245r;
  miso  = 1; # D1
  sck   = 0; # D0
  mosi  = 2; # D2
  reset = 4; # D4
;

Не мог понять, пока не почитал внимательно приложение к даташиту FT232R подробно рассказывающее про Bit Bang режимы этой микросхемы. Если коротко: для программатора нужно 4 линии, микросхема предоставляет 8 линий, на которых можно играться уровнями. Естественно в каждом конкретном программаторе могут использоваться любые 4 из этих 8ми линий.

Каждая линия отражает бит с номером от 0 до 7. На Arduino на разъем X3 выведены контакты микросхемы с номерами 11, 9, 10, 6, подключаемых по следущей схеме:

11 - MISO
 9 - SCK
10 - MOSI
 6 - RESET

В документации находим табличку, в которой представлены номера выводов и какой бит они предоставляют, и получаем такую таблицу соответствий:

Имя линии Номер вывода микросхемы Имя вывода Номер вывода разъема X3 Номер/Имя бита (согласно таблицы)
MISO 11 CTS 1 D3
SCK 9 DSR 2 D5
MOSI 10 DCD 3 D6
RESET 6 RI 4 D7

Смотрим на последнюю колонку: вот они откуда и берутся эти самые 3, 5, 6, 7 в описании программатора в avrdude.conf. Т.е. эти номера - это номера битов. С остальными программаторами дело обстоит схожим образом. Одного я не понял, почему этого нет в документации? Или плохо искал?

На этом пока все, сейчас обощаю идеи о среде разработки (на данный момент на базе Makefile) и опубликую заметку.

// pacman 3.4.0

Все подробности тут: http://www.archlinux.org/news/503/

От себя, на что стоит обратить внимание:

  1. -U теперь в большинстве случаев работает как -S, а точнее:
    • обработка зависимостей
    • обработка конфликтов (если пакет заменяет какой-то пакет, раньше нужно было сначала удалить установленный, потом ставить локальный новый)
  2. makepkg теперь завершает свою работу с ошибкой, если какая-то вызываемая программа завершается не с нулевым кодом возврата. Таким образом не нужно больше писать «|| return 1» после команды, если дальнейшая сборка при ошибке не имеет смысла. С другой стороны, когда завершение программы с не нулевым кодом возврата это нормальное поведение (предположим наложение патчей с опцией -N, когда патч был уже наложен), нужно будет после команды поставить «|| true» что бы сборка не завершилась с ошибкой.

// Долго запускаются Xlib/Xt приложения

Столкнулся давно с проблемой: приложения написанные с использованием только Xlib и Xt, например,xclock, xfontsel, или удобная тюнинговалка xvidtune, или мелкая оповещалка xmessage, очень долго запускаются, до 15-20 секунд, при этом давая значительную нагрузку на процессор. Если запускать в терминале, то обычно получаем, среди прочего, такую строку:

Warning: Missing charsets in String to FontSet conversion

Так как эти приложения использовал достаточно редко, то не обращал внимание, но сегодня что-то достало, решил разобраться. Беглый поиск привел на эту страницу: http://www.holoweb.net/~liam/fonts/common-linux-font-problems.html (искать по фразе «Everything starts up really slowly»). Информация старая, ещё для XFree86, ориентировочно 2002 года, но, с небольшими поправками, не потерявшая актуальность и сегодня.

В общих чертах: проблема в fontconfig и локалях Xorg, где указаны кодировки для шрифтов, которых нет в системе. Путей решения получается три:

  1. Запускать через приведенный там скрипт nolocale, добавив туда ещё сточку:
    export LANG=
  2. Поставить шрифты со всеми нужными кодировками
  3. Отредактировать файл локали, убрав (закоментировав) использование несуществующих кодировок

Так как первый способ неудобен, а второй накладен, решил сделать по последнему варианту. Итак, рецепт для ArchLinux (с небольшой адаптацией последнего пункта подходит и для любого другого дистрибутива)

Для начала нужно понять шрифтов в каких кодировках у нас нет.

Для этого бредём в директорию /usr/share/X11/locale/<ВАША_ЛОКАЛЬ>. У меня локаль ru_RU.UTF-8, поэтому директория: /usr/share/X11/locale/ru_RU.UTF-8 и выполним там команду:

cat XLC_LOCALE | grep name | grep -v 'object_name\|encoding_name'

В результате получим примерно такой вывод:

		name	ISO8859-1:GL
		name	ISO8859-1:GR
		name	KOI8-R:GR
		name	MICROSOFT-CP1251:GR
		name	ISO8859-5:GR
		name	JISX0208.1983-0:GL
		name	KSC5601.1987-0:GL
		name	GB2312.1980-0:GL
		name	JISX0201.1976-0:GR
		name	ISO10646-1

На то, что после двоеточия не обращаем внимания, итого, кодировка состоит из двух частей, разделенных «-»: CHARSET_REGISTRY и CHARSET_ENCODING (за подробностями сюда: http://lesstif.sourceforge.net/doc/super-ux/g1ae04e/chap5.html)

Теперь запускаем программку xfontsel, придется подождать малость (с чем собственно мы сейчас и боремся).

Итак, шрифты в X11 издревле задавались хитрой строчкой, поля в которой были разделены знаком «-», последние два элемента как раз и есть CHARSET_REGISTRY и CHARSET_ENCODING (в терминах xfontsel: rgstry и encdng соответственно). Теперь просто проверяем по последним двум полям, что есть все комбинации из вышеполученных rgstry-encdng (на регистр внимания не обращаем), те, которые не находим помечаем.

Теперь возвращаемся в каталог с локалью, открываем файл XLC_LOCALE на редактирование находим секцию с несуществующей кодировкой и комментируем её.

У себя я не нашел шрифтов в кодировке microsoft-cp1251 (есть только cp1252), поэтому полностью закомментированная секция выглядит теперь так:

#	fs3 class (MICROSOFT-CP1251)
#fs3	{
#	charset	{
#		name	MICROSOFT-CP1251:GR
#	}
#	font	{
#		primary	MICROSOFT-CP1251:GR
#	}
#}

Все, сохраняемся и выходим. Проверяем, приложения должны стартовать практически мгновенно.

Ну и последний штрих для ArhLinux. Дабы уберечь от перезаписывания этого файла при обновлениях пакета libx11 (а именно ему принадлежат эти файлы локали), его нужно «замаскировать». Для чего открываем на редактирование файл /etc/pacman.conf, находим параметр NoUpgrade и приводим его примерно к такому виду:

NoUpgrade    =  usr/share/X11/locale/ru_RU.UTF-8/XLC_LOCALE

Теперь при обновлениях, если файл в пакете изменился, он будет ставиться под именем XLC_LOCALE.pacnew и соответствующим предупреждением на экране и в логе. Дальнейшие шаги по поддержанию в актуальном состоянии зависят от вас.

Ну и последнее замечание, описанной процедурой можно и просто найти шрифтов в каких кодировках нет в системе и просто поставить их, если они у вас имеются :)

// Xorg 1.8 в extra

Собственно сабж, подробности: http://www.archlinux.org/news/502/

Для пользователей старых карт nVidia небольшая засада.

// epssplit & jpeg2ps

Про эти утилиты писал года три назад в статье: Резка большеформатных изображений на листы формата А4 для последующего склеивания

Сейчас дошли руки приготовить пакеты для AUR: epssplit, jpeg2ps, так что, в ArchLinux с установкой стало проще :)

По поводу преобразование растра в PS/EPS можно почитать в статье Евгения Балдина в «Linux Format»: LaTeX. Часть 4: Графика

// Странная проблема с WiFi на EeePC 1000HA

Проблема сводится к тому, что при запуске Xorg связь начинает умирать. Для восстановления достаточно переключиться в консоль. Причины и связи мне не понятны, и вообще фантастически выглядит решение проблемы: перепрошивка точки доступа. Вот где тут связь???

Пока разбирался, научился запускать драйвер ath5k - просто для его включения нужно активизировать 2 rfkill устройсва:

  1. сначала eeepc-wlan (см вывод rfkill list)
  2. после появится ещё одно - phy0, и активировать его
  3. затем, в обязательном порядке - ifconfig wlan0 up

после чего можно начинать работать.

Точка доступа (DWL-G700AP) же, была последним шагом - нет нормальной связи, так хоть поэксперементирую. Прошивку туда залил Wive-ng, она на базе ядра Linux 2.4, и очень значительно расширяет возможности точки, превращая её в полноценный маленький сервер с управлением по ssh/telnet:

  • pppoe-client
  • pptp-client
  • dhcp
  • iptables/nat
  • балансировка трафика
  • роуминг (прозрачный переход от точки доступа к точке доступа)
  • vlan
  • широкий диапазон регулировки мощности (больше чем в базовой поставке, но для значений больше 20, следует применять принудительное охлаждение)
  • smbclient (но… не могу представить для чего :) если бы было память побольше, можно было бы туда запихнуть rtorrent с веб-интерфейсом (или даже без оного), а так…)
  • и ещё всего и вся по мелочи

В результате и связь при запущенных Xorg поднялась. Хитрая уличная магия.

По прошивке и вообще точке доступа:

General:

Wive:

Wive-ng:

// Emacs и пустые меню

Столкнулся с проблемой: в некоторых модах, которые добавляют пункты меню в Emacs, эти самые пукнты меню оказываются пустыми, причем, при последующем перезапуске, бывают оказываются и не пустыми.

Собственно вот так это выглядит, открыт C-файл и выбран пункт меню C:

Поиск привел на английски форум ArchLinux: http://bbs.archlinux.org/viewtopic.php?id=83860, собственно от туда варианты решения:

  1. выполнять команду:
    M-x accelerate-menu
  2. установить переменную окружения GDK_NATIVE_WINDOWS перед запуском Emacs:
    export GDK_NATIVE_WINDOWS=1

И сразу на правах рекомендации: Doxymacs

И ещё одна рекомендация, статья Алекса Отта по настройке CEDET: http://alexott.net/ru/writings/emacs-devenv/EmacsCedet.html

// Из одной установки ArchLinux

Подогнали тут машинку, мамка Asus CUBX-L, процессор Intel Celeron 600MHz, RAM около 415Mb (free кажет 416800Kb, что-то не могу подобрать комбинацию, там 3 планки стоят). У меня вообще в последнее время какая-то тенденция с оживлением всякого старого железа, лотеком прям себя ощущаю.

Образ с которого устанавливаюсь 2009.08, так вот, на машинке или сам привод немного подгоняет, или диск так записан (возможности проверить на другом нет), но при попытке установке пакетов, вылетает на том, что не может проверить контрольные суммы у некоторых пакетов. Причем, установка пакетов у меня выбрана не с диска, а с сети - благо у меня локальное зеркало есть. Это навело на мысль - удалить пакеты, чтобы перезакачались: была такая проблема на моём EeePC - подглючивала сетевая карта.

Сказано - сделано. Иду в /mnt/var/cache/pacman/pkg и… правильно, пытаюсь удалить некорректные пакеты, а оно мне что? А оно мне говорит - а нет таких файлов. Опппппааааа… ЧДКВ?

Смотрю какой командой запускается pacman:

pacman --root /mnt --config /tmp/pacman.conf --noconfirm -S <список пакетов>

Смекаю, я же зеркало выбирал, значит должно быть отражено в конфигурационном файле, а вдруг там ещё что, понаписано… Открываю:

nano /tmp/pacman.conf

и что я вижу? там в секции [options] указаны два параметра для CacheDir, один верно ведет в /mnt/var/cache/pacman/pkg, а другой, на те пакеты, что на диске: /src/… и так получилось, что пакеты, на которые ругалось, не изменились с августа прошлого года, а т.к. диск/привод гонят - прочитаться не смогли, на что ругнулось, что контрольные суммы не получилось просчитать.

Удаляю эту строчку, после чего возвращаюсь на пункт Install packages и пробую заново устанавливать пакеты - удача :)

To be continued…