Проприетарные видеодрайверы Nvidia в репозиториях Fedora от negativo17

Очередной апгрейд Fedora (до версии 24) в очередной раз навернул графику на моем стареньком десктопе с Nvidia GeForce 8. На этот раз проблема оказалась в отсутствии нужных драйверов на RPM Fusion (их там нет до сих пор). Моей старой видеокарте нужен специальный драйвер серии 340xx. Поиск этой серии на Russian Fedora тоже не увенчался успехом. Перспектива собирать драйвер самому мне не улыбалась: нет никакого удовольствия делать это каждый раз при очередном обновлении ядра. В общем, лень — двигатель прогресса — привела меня на замечательный ресурс negativo17.org, в котором на странице repositories находится список репозиториев Fedora с разными несвободными приложениями типа Skype и Rar, в том числе и с проприетарными драйверами Nvidia. Инструкции по установке драйверов и прочие подробности изложены на этой странице. Поскольку мне был нужен драйвер серии 340xx, для установки репозитория я использовал команду

dnf config-manager --add-repo=http://negativo17.org/repos/fedora-nvidia-340.repo

Остальное всё по инструкции (почти).

dnf remove \*nvidia\*
dnf install nvidia-driver akmod-nvidia
akmods --force

И перезагрузка. Важно отметить, что автор репозиториев является активным мейнтейнером Fedora (см. здесь), поэтому их использование не должно создавать риск нарушения безопасности.

Шрифты infinality-ultimate для Fedora 23

Добрый человек собрал репозиторий с пропатченными пакетами для infinality. Спасибо ему большое! Некоторое время я вообще думал, что infinality мертв, оказывается нет: здесь находится активный репозиторий разработки, но без поддержки Fedora. Лично я установил только основные патчи, без шрифтов — так, как написано в секции Installation — на мой вкус этого вполне достаточно. До этого у меня стояли версии freetype и fontconfig от Russian Fedora и, в общем-то, я не жаловался на рендеринг, однако теперь я вижу разницу: шрифты стали четче, что-ли. Короче, чувствую, что стало лучше, но доказать не могу :) И сравнительные картинки приводить не стану: не сохранил оригинальный вид, да и в интернете такие сравнения найти несложно.

Падение xneur в Fedora 21

Все, кого волнует данная тема, могут скачать xneur src.rpm отсюда. Кстати, лично для меня установка Fedora 21 оказалась наиболее косячной в сравнении с версиями 19 и 20. Хотя косяки эти в общем-то мелкие, но неприятные: кроме падучести xneur, это отсутствие шрифтов infinality, черный экран MATE после пробуждения из длительного сна, произвольное вычищение истории команд оболочки, внезапное подключение репозитория rawhide после обновления, из-за чего я чуть было не обновил все пакеты до следующей Fedora 22 (возможно, это стало следствием не до конца отработавшего скрипта rfremix-upgrade от Russian Fedora), еще что-то там — уже не помню. Надеюсь, все это будет со временем исправлено. Наиболее жесткий косяк был с установкой Fedora 21 на новый ноутбук MSI GE60 2PL Apache. В нем установлены две видеокарты — встроенная Intel и более мощная NVIDIA GeForce GTX 850M. Переключение карт в BIOS не предусмотрено. При первой же загрузке подключение драйвера Nouveau сломало напрочь весь процесс с самого начала. Дальнейшие перезагрузки тоже приводили к разнообразным ошибкам памяти в самом начале загрузки. Пару раз мне все-таки удалось загрузиться (сказалась неопределенность поведения), и в один из этих светлых моментов я установил драйвер bumblebee: это исправило проблему, и даже optirun теперь переключает видеокарты как следует. Update. Собрал пропатченный билд xneur на федориной копре. Репозиторий здесь. Установить пакеты с подключенным репозиторием через yum не удастся, если в системе установлены графические оболочки типа gxneur, которые зависят от оригинального пакета xneur. Поэтому можно загрузить подходящие rpm пакеты непосредственно отсюда и установить их командой rpm -Uvh --nodeps.

Что делать, если у вас маленький /, а обновить Федору очень хочется

В общем-то, не обязательно /, в общем случае это точка монтирования файловой системы, в которой находятся директории /var/lib/ и /var/tmp/. На моем рабочем компьютере эти директории находятся в корневой файловой системе, размер которой составляет всего 20 Гб. Это приводит к проблемам при штатном обновлении ядра через yum, что уж тогда говорить об обновлении всей системы.

Итак, обновляться я решил вчера, 23 декабря 2013 года, с Fedora 19 до Fedora 20, то есть уже после официального выхода Fedora 20. Инструмент для обновления - fedup-0.8.0-3, совсем недавно заменивший версию 0.7. Он запускается из командной строки и в процессе загрузки пакетов использует директории /var/lib/system-upgrade/ и /var/tmp/system-upgrade/. Опций для настройки других директорий нет (хотя в файле TODO.asciidoc, входящем в состав пакета fedup, такая возможность анонсируется в будущем). То есть, если запускать fedup без всяких предварительных настроек следующим образом:

fedup --network 20 --nogpgcheck

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

Итак, что же делать? Самое очевидное решение - снести директории /var/lib/system-upgrade/ и /var/tmp/system-upgrade/ вместе с их содержимым, найти диск, на котором достаточно места для пары-тройки гигабайт обновлений, и создать символические ссылки на эти директории из /var/lib/system-upgrade и /var/tmp/system-upgrade. У меня нашлось достаточно места на диске, который монтируется в корневую файловую систему как /home. Поэтому, от имени суперпользователя я создал на нем две директории /home/fedup/cache/ и /home/fedup/packages/, а затем и упомянутые символические ссылки:

ln -s ../../home/fedup/cache /var/tmp/system-upgrade
ln -s ../../home/fedup/packages /var/lib/system-upgrade

Обратите внимание на то, что ссылки задаются не через абсолютные пути, а через относительные, это очень важно! Дело в том, что после перезагрузки системы для ее обновления все файловые системы, в том числе /home, будут смонтированы в /sysroot, а не в /, и загрузчик просто не сможет найти пакеты для обновления (см. об этом здесь).

В общем-то, на этом историю про обновление Fedora с небольшим дисковым пространством можно было бы и закончить. Но не тут-то было! Обновление Федоры - это почти всегда приключение, сопряженное с риском и опасностью, в которых не место домохозяйкам! После перезагрузки системы для дальнейшего обновления и загрузки нескольких сервисов systemd, запустился релэйблинг SELinux, как я понял на загруженные новые пакеты (хотя SELinux в системе у меня отключен). Помурыжив минут 15, компьютер перезагрузился, оставив опцию с апгрейдом системы в верхней строке загрузчика GRUB2. Я попробовал загрузить апгрейд снова: в итоге обычная загрузка GDM как ни в чем не бывало. То есть система не обновилась! Я перезагрузился в старое ядро от Fedora 19, снес Upgrade опцию из загрузчика:

fedup --resetbootloader

и запустил fedup--network 20 --nogpgcheck сначала. После серии таких попыток обновления я понял, что проблема не в новых пакетах, установленных неожиданным для fedup образом, а в чем-то другом. На правильный путь меня натолкнуло описание этого бага. В одном из комментариев было сказано про аргумент ядра systemd.unit=system-upgrade.target, который устанавливал старый fedup 0.7 для старта процесса обновления после перезагрузки системы. Я открыл /boot/grub2/grub.cfg, нашел секцию, соответствующую апгрейду системы, и вставил туда этот параметр, на авось, поскольку так и не понял, нужен ли он новому fedup 0.8 и установочному образу ядра. Кроме того, добавил туда же опцию selinux=0, чтобы не ждать релэйблинга новых пакетов (или чего-то там еще, не суть важно). Более того, новый fedup был так добр, что не установил в аргументы загрузки ядра опцию plymouth.splash=fedup: это в дальнейшем позволило наблюдать за реальным процессом установки пакетов в консоли, а не бестолковый графический прогрессбар. Если вы тоже захотите удалить эту опцию, то не пугайтесь, когда в процессе установки консоль заснет и дисплей погаснет: просто нажмите на клавиатуре Shift - это разбудит консоль.

Итак, как вы уже поняли, после добавления в аргументы загрузки ядра опции с systemd.unit, процесс пошел. Система обновилась, и после перезагрузки опция с апгрейдом системы ушла из меню GRUB2, что и должно было произойти. Однако, в момент загрузки новой Fedora 20 вернулась проблема с SELinux, с одной стороны неудивительно - я ведь устанавливал ее только для ядра, загружаемого для обновления системы. С другой стороны непонятно, почему fedup не вычистил эти пакеты сразу после обновления. После загрузки Fedora 20 и запуска fedup --clean все стало понятно: fedup сообщил, что он не в состоянии выполнить rmtree на символических ссылках. Пришлось вручную удалять все содержимое из директорий /home/fedup/cache/ и /home/fedup/packages/.

Осталось сказать, что проблему с нехваткой дискового пространства при обновлении ядра через yum решить просто - намного проще, чем с fedup. Создаем директорию /home/yum/cache/, открываем файл /etc/yum.conf и заменяем строку

cachedir=/var/cache/yum/$basearch/$releasever

на

cachedir=/home/yum/cache/$basearch/$releasever

Проблемы, с которыми я столкнулся после обновления Fedora 17 до Fedora 18

У меня установлены MATE и Compiz отсюда. В репозитории пока нет обновленных пакетов для Fedora 18. Это приводит к нескольким проблемам, которые я перечислю в порядке значимости.

1. Симптом: caja (аналог nautilus в MATE) не может загрузить иконки для файлов (в т.ч. на рабочем столе) и начинает поедать 100% CPU.
   Лечение: удаляем директорию $HOME/.thumbnails и создаем вместо нее символическую ссылку на $HOME/.cache/thumbnails:

   cd
   rm -r .thumbnails/
   ln -s .cache/thumbnails .thumbnails
   

   Если целевая директория $HOME/.cache/thumbnails отсутствует, то создайте ее. Проблема уже исправлена в последних версиях mate-desktop ветки 1.4.


2. Симптом: команда yum check показывает отсутствующие зависимости для некоторых компонентов MATE, в частности atril-libs и mate-color-manager требуют libtiff.so.3, а mate-note - libpcre.so.0. Эти библиотеки в Fedora 18 были обновлены до новых версий.
   Лечение: просто забить (однако в этом случае придется удалить иконку mate-note с панели MATE).
   Вариант: скачать SRPM файлы соответствующих библиотек из Fedora 17 (например отсюда), установить их с помощью rpm (я обычно делаю это от имени специального пользователя mockbuild):

   rpm -Uvh libtiff-3.9.7-1.fc17.src.rpm
   

   (здесь я привожу пример только для libtiff). Перейти в директорию rpmbuild/SPECS, заменить строку Name: libtiff на Name: libtiff3 и собрать rpm:

   rpmbuild -ba libtiff.spec
   

   Теперь перейти в директорию ../RPMS/<your-arch> и от имени суперпользователя установить новый пакет libtiff3:

   rpm -Uvh libtiff3-3.9.7-1.fc18.R.x86_64.rpm
   

Вообще-то я надеюсь, что данный репозиторий MATE скоро обновится до Fedora 18 и первые две проблемы уйдут.

Теперь более интересная проблема. Сообщение Authentication is required for powering off while other users are logged in и предложение ввести пароль суперпользователя при попытке выключить или перезагрузить компьютер из GDM или пользовательской сессии. Возможно у вас не возникнет этой проблемы, или она будет возникать иногда при попытке выключить компьютер из GDM сразу же после выхода из пользовательской сессии.

У меня эта проблема проявлялась всегда до тех пор, пока я не поправил... что бы вы думали? ...инит-скрипт для демона TurboPrint (есть такая замечательная программа для печати, хотя и не бесплатная; настоятельно рекомендую особенно для печати фотографий). У меня установлена старая версия TurboPrint 2.15. Возможно в новых версиях проблема с systemd уже решена, но для обновления TurboPrint придется заплатить. Поскольку установленная версия меня вполне устраивает, то пришлось править скрипты для нее.

Итак, по порядку. Как обнаружить причину такой странной и специфичной для Fedora 18 проблемы? Что мы имеем? Мы загрузили компьютер, пытаемся тут же его выключить и получаем сообщение, что мы не одни в системе! Оказывается, в новой Fedora за сессиями пользователей следит systemd, а просмотреть состояние сессий можно с помощью утилиты loginctl. Так и делаем. Переходим в виртуальную консоль, логинимся от имени рута и набираем loginctl list-sessions. На экран выводится

   SESSION        UID USER             SEAT            
        c1          4 lp

Супер! Пользователь lp в системе! Что же он делает?

# loginctl user-status lp
lp (4)
           Since: Tue, 2013-01-15 21:26:02 MSK; 3min 49s ago
           State: active
        Sessions: c1
          CGroup: name=systemd:/user/lp
                  └ c1
                    └ 701 /usr/bin/tprintdaemon 0

Очевидно, это результат запуска системного демона /etc/init.d/tpdaemon, который при старте открывает оболочку для пользователя lp. Как теперь быть? Мигрировать демон на systemd! Здесь я нашел как это сделать. Сначала отключаем демон в init.d:

chkconfig tpdaemon off
service tpdaemon stop

Затем создаем новый сервисный файл для systemd /etc/systemd/system/tprintdaemon.service и записываем в него строки

[Unit]
Description=TurboPrintDaemon

[Service]
Type=forking
ExecStart=/usr/bin/tprintdaemon
Restart=on-abort

[Install]
WantedBy=multi-user.target

Теперь регистрируем и запускаем новый сервис:

systemctl enable tprintdaemon.service
systemctl start tprintdaemon.service

Как это обычно бывает, с первого раза новый подход не принес результата. Выяснилось, что TurboPrint запускает программу turboprint-monitor 0 -hide, которая работает от имени залогинившегося пользователя и действует как демон, что не позволяет systemd и loginctl считать, что этот пользователь успешно разлогинился. Выход из ситуации: убивать turboprint-monitor при выходе пользователя из графической оболочки, благо эта программа запускается при каждом новом логине заново. Как это сделать? Я использую в качестве дисплейного менеджера GDM. В GDM есть прекрасное место, где можно определить действия при выходе из пользовательской сессии: это файл /etc/gdm/PostSession/Default. Вот строки, которые я добавил в этот файл для принудительного завершения turboprint-monitor, а также pulseaudio:

for service in pulseaudio turboprint-monitor ; do
  PID=$(loginctl user-status $USER | grep "[0-9]\+\s\+\S*$service" | \
                                     sed 's/^[^0-9]\+\([0-9]\+\).*/\1/')
  [ "$?" == "0" ] && kill $PID
done

Зачем здесь pulseaudio? Оказывается, он большой тормоз и выходит по завершении пользовательской сессии не сразу. Это приводит к задержке очистки пользовательской сессии, и соответственно возможен сценарий, когда пользователь выходит из графической сессии и, сразу пытаясь выключить компьютер из GDM, получает то же невнятное сообщение о присутствии других пользователей с предложением ввести пароль рута.

В общем, systemd в роли менеджера сессий вызывает впечатление пока еще сырого продукта.

Update. Репозиторий MATE обновился! Инструкция по установке здесь. Соответственно проблема с зависимостями и mate-note уходит. Однако автор решил не обновлять сами пакеты до выхода стабильной ветки MATE 1.6, которая ожидается в марте этого года, а это значит, что проблема с caja скорее всего не исправлена. Кроме того, после обновления я заметил, что цвет текста в верхней панели стал почти полностью сливаться с фоном панели, поэтому пришлось добавить в файл $HOME/.gtkrc-2.0 такие строки:

style "my_color"
{
        fg[NORMAL] = "#AAAAAA"
}
widget "*PanelWidget*" style "my_color"
widget "*PanelApplet*" style "my_color"

Кроме того, я убрал с панели стандартный индикатор раскладки клавиатуры, так как непонятно, как изменить его цвет, да и к тому же он мне не нужен, так как я использую gxneur:

mateconftool-2 -s /desktop/mate/peripherals/keyboard/general/disable_indicator -t bool true

Update 2. Еще одна проблема. Программа epstopdf стала генерировать пустые pdf с такими сообщениями об ошибке:

Error: /invalidfont in /findfont
Operand stack:
   Times-Roman
Execution stack:
   ...
Dictionary stack:
   ...
Current allocation mode is local
Last OS error: Not a directory
GPL Ghostscript 9.06: Unrecoverable error, exit code 1

Выяснилось, что это из-за того, что я установил пакет fontconfig-infinality, который банит шрифты Type 1 в /etc/fonts/infinality/infinality.conf. Чтобы восстановить работу epstopdf, следует закомментировать в этом файле следующие строки:

    <selectfont>
        <rejectfont>
            <pattern>
                <patelt name="fontformat" >
                    <string>Type 1</string>
                </patelt>
            </pattern>
        </rejectfont>
    </selectfont>

Очевидно, данная проблема связана не с обновлением Fedora, а, собственно, с установкой fontconfig-infinality.
 
Update 3. Автор репозитория MATE таки отказался поддерживать свой репозиторий для Fedora 18. То, что он выложил раньше, оказалось его ошибкой (см. здесь). Так что теперь у нас два варианта (напомню, что моим приоритетом является сохранение Compiz в системе, а этот пакет предоставляется только данным репозиторием).

1. Оставить все как есть. В этом случае все пакеты из старого репозитория MATE, включая Compiz, останутся в системе и будут работать. Если вы не успели проапгрейдить MATE из ошибочного репозитория, то останутся проблемы с зависимостями (libtiff.so.3 и libpcre.so.0), и, вполне возможно, в дальнейшем появятся новые неудовлетворенные зависимости, так как вы, очевидно, не сможете проапгрейдить пакеты MATE из более несуществующего репозитория.


2. Выбрать и снести выборочные пакеты из старого репозитория MATE c помощью rpm -evh --nodeps. При этом не следует удалять пакеты Compiz, поскольку автор репозитория обещал добавить их в новый репозиторий mate-desktop-extra через неделю, и пока их там нет! Собственно для этого и нужен флаг --nodeps для rpm, так как пакеты Compiz зависят от MATE. После удаления старых пакетов MATE нужно установить новые пакеты командой

   yum groupinstall MATE-desktop
   

   и добавить пакеты из репозитория mate-desktop-extra:

   yum install https://dl.dropbox.com/u/105479527/Mate-Desktop/fedora-release-extra-18/mate-desktop-fedora/noarch/mate-desktop-extra-release-18-1.fc18.noarch.rpm
   yum groupinstall mate-desktop-extra
   

   Минус этого подхода в сложности выбора нужных пакетов для удаления и необходимости заново настраивать внешний вид десктопа. Плюсы: отсутствие проблем с зависимостями и постоянные обновления пакетов из стандартного репозитория Fedora.

Лично я воспользовался вторым способом. Все работает, но есть и регрессии, связанные с верхней панелью: по какой-то причине отсутствует апплет для датчиков температуры, нет больше mintmenu (оно якобы несовместимо с новой версией панели), нет апплета переключения пользователей, погодный апплет почему-то выводит текст Неизвестно.
 
Update 4. До Fedora 18 я пользовался этим репозиторием для texlive. Теперь все пакеты из последнего texlive есть в стандартном репозитории, поэтому сносим все пакеты из старого репозитория и устанавливаем их из нового:

rpm -qa tex-* texlive-* | xargs yum -y remove
yum install texlive texlive-collection-langcyrillic texlive-disser texlive-mhchem texlive-braket texlive-feynmf texlive-hepparticles texlive-hepnames texlive-subfigure texlive-wrapfig texlive-gost texlive-bibtexu texlive-helvetic texlive-epstopdf texlive-metapost texlive-minted texlive-latexmk texlive-cm-super

В списке на установку обязательными являются только два пакета: texlive и texlive-collection-langcyrillic. Остальные пакеты из списка не устанавливаются по умолчанию, но я их использую. Кстати, проблему с переносами русских слов, о которой я писал здесь, в новом репозитории кажется уже решили.

Установка Firefox 6 и Thunderbird 6 в Fedora 14

Да, я так и не перешел на Fedora 15, так как не определился, чем заменить старый добрый Gnome 2. А пользоваться обновленными продуктами от Mozilla очень хочется. Так, недавно вышли очередные мажорные версии Firefox и Thunderbird, обе за номером 6. Естественно, в репозиториях Федоры их нет, зато они нашлись в репозитории Remi. Я не подключал данный репозиторий, поэтому просто скачал соответствующие пакеты (thunderbird, firefox и xulrunner6) и установил их. К сожалению, сразу же всплыла старая проблема с ужасными шрифтами без поддержки Byte Code Interpreter. Насколько я помню, исходный код библиотеки cairo был с изменениями включен в состав Firefox для сборки из-за какого-то странного бага с никому ненужными анимированными файлами gif. Благодаря этому, результирующий вид шрифтов стал зависеть не от того, какие системные библиотеки, отвечающие за рендеринг шрифтов, используются в вашей системе, а от того, какие библиотеки были у сборщика во время компиляции. Таким образом, товарищ Remi Collet при компиляции Firefox и Thunderbird использовал опцию, которая включает измененный вариант cairo, и кроме того, он располагал библиотеками для рендеринга шрифтов (fontconfig и libXft), которые поставлялись с Fedora 14 по умолчанию, что, в общем-то, логично и неудивительно.

Итак, проблема ясна. Будем лечить. Я не захотел собирать firefox и thunderbird с нуля, а решил воспользоваться SRPM пакетами из репозитория Remi. Найти их можно здесь. Очевидно, для того чтобы правильно пересобрать эти пакеты, нужно чтобы соответствующие правильные библиотеки были представлены в вашей  системе. Проще всего это сделать (если вы до сих пор этого не сделали и не используете репозиторий infinality), подключив репозиторий russianfedora-fixes и обновившись через yum update. После обновления будут установлены правильные fontconfig и libXft. Кроме того, для сборки нам понадобятся fontconfig-devel, libXft-devel и, разумеется, cairo-devel:

yum install fontconfig-devel libXft-devel cairo-devel

Перейдем к сборке rpm. Если вы еще не завели специального псевдопользователя для этой цели (а так рекомендует Федора), то сейчас самое время. От имени суперпользователя вводим

useradd mockbuild

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

passwd mockbuild

Для того, чтобы пользователь-сборщик не появился в списке приглашения GDM, откроем файл /usr/share/gdm/gdm.schemas, найдем там строку <key>greeter/Exclude</key> и добавим в список пользователей ниже внутри тегов <default>...</default> нашего mockbuild.

Теперь нужно установить пакет для поддержки сборки rpm пакетов:

yum install rpmdevtools

Затем логинимся как mockbuild:

su - mockbuild

и создаем дерево директорий для сборки пакетов:

rpmdev-setuptree

Устанавливаем скачанные пакеты SRPM (от имени mockbuild, конечно) с помощью простой команды

rpm -ivh firefox-6.0-1.remi.src.rpm xulrunner6-6.0-1.remi.src.rpm thunderbird-6.0-1.remi.src.rpm

После этой команды исходники попадают в rpmbuild/SOURCES, а spec файлы - в директорию rpmbuild/SPECS. Переходим в директорию со spec файлами и правим. В файлах firefox6.spec и xulrunner6.spec после строки

echo "ac_add_options --enable-system-lcms" >> .mozconfig

добавляем строку

echo "ac_add_options --enable-system-cairo" >> .mozconfig

а в файле thunderbird.spec добавляем строку

ac_add_options --enable-system-cairo

где-нибудь между строками

cat <<EOF | tee -a .mozconfig

и

EOF

(например в самом конце, прямо перед строкой EOF).

Возможно, для сборки вам придется установить дополнительные пакеты. Так, мне пришлось установить autoconf213, lcms-devel, wireless-tools-devel и libvpx-devel. С помощью yum это сделать несложно.

Переходим к построению rpm, последовательно запуская команды

rpmbuild -ba xulrunner6.spec
rpmbuild -ba thunderbird.spec

В списке нет firefox, поскольку он зависит от построенного xulrunner6, поэтому, когда эти две команды отработают (а ждать нужно достаточно долго), переходим в директорию /home/mockbuild/rpmbuild/RPMS/your_arch, где your_arch - архитектура вашей системы (например, x86_64) и от имени суперпользователя обновляем свежесобранные пакеты:

rpm -Uvh thunderbird-6.0-1.fc14.x86_64.rpm  xulrunner6-6.0-1.fc14.x86_64.rpm xulrunner6-devel-6.0-1.fc14.x86_64.rpm

Если в вашей системе уже стоит xulrunner-devel, то его нужно будет предварительно удалить, так как он конфликтует с xulrunner6-devel. После установки новых пакетов возвращаемся в директорию SPECS и от имени mockbuild строим firefox:

rpmbuild -ba firefox6.spec

После завершения сборки снова возвращаемся в директорию RPMS и от имени суперпользователя обновляем firefox:

rpm -Uvh firefox-6.0-1.fc14.x86_64.rpm

После установки запускаем новые firefox и thunderbird и наслаждаемся правильным рендерингом шрифтов и проделанной работой :)

Fedora 15 и wicd

Так уж получилось, что на моем ноутбуке Lenovo B560 вместо NetworkManager установлен wicd: просто на момент покупки (в феврале этого года) NetworkManager не умел работать с броадкомовским сетевым интерфейсом, установленном в B560 (да и сейчас наверное не умеет); кcтати и дрова для этого драйвера пришлось брать проприетарные - из rpmfusion (broadcom-wl). Как бы то ни было, но wicd мне вполне понравился и менять его обратно на NetworkManager я не собираюсь.

После того, как совсем недавно вышел релиз Fedora 15, я решил опробовать его на данном ноутбуке, перед тем как переносить на десктоп. Теперь я могу сказать совершенно точно, что обновлять десктоп с Fedora 14 до Fedora 15 я не буду, подожду следующего релиза. И, конечно же, огромное спасибо за такое решение хочется сказать разработчикам Gnome 3 :) Ну да ладно, это тема отдельного разговора.

Итак, вернемся к B560 и wicd. После обновления до Fedora 15 на ноутбуке отвалился wi-fi. Апплет wicd-gtk ругался на dbus и отказывался сканировать wi-fi источники. Первое, что удалось установить, это отсутствие модуля wl в списке загруженных модулей ядра. Оказывается, rpmfusion еще не удосужились обновиться до Fedora 15 (на момент написания этих строк репозитория rpmfusion Fedora 15 так и не появилось). В rpmfusion rawhide я этого драйвера тоже на тот момент не нашел (хотя сейчас он там уже присутствует). Поэтому я снес akmod-wl и kmod-wl и переустановил их из russianfedora. Команда modprobe wl вернула броадкомовскую железяку к жизни.

Однако это никак не повлияло на работу апплета wicd-gtk, который упорно ругался на dbus. Как выяснилось, демон wicd, который на Fedora 15 управляется новой системой загрузки systemd, умирал сразу же, как только systemd его стартовал. В багзилле Red Hat имеется соответствующий баг #327829, который был создан в апреле этого года и почему-то ни разу не комментировался. Если кому-то интересно, скрипт systemd для запуска демона wicd находится в файле /lib/systemd/system/wicd.service. Проверка статуса осуществляется командой systemctl status wicd.service, аналогично запуск и остановка - stop и start. Хотя старая добрая service wicd status тоже работает, просто перенаправляя действия на systemctl (обратите внимание, что в systemctl сначала указывается команда, а потом сервис). Как бы то ни было, но возиться с этим мне было некогда, мне нужен был рабочий wi-fi сразу после загрузки.

Очевидное решение - поместить строку /usr/sbin/wicd в файл /etc/rc.local - сработало. Остается ждать, когда разработчики починят баг #327829 и вернуть управление демоном wicd системе systemd.

Отключение автоматического монтирования отдельных разделов диска устройства, подключаемого через USB

Имеется в наличии медиаплеер Iconbit HDR12L, в который установлен внутренний диск размером 500Гб. Диск был размечен устройством следующим образом:

Устр-во Загр     Начало       Конец       Блоки     Id  Система
/dev/sdc1           16065   967386104   483685020    7  HPFS/NTFS
/dev/sdc2       967386105   967707404      160650   82  Linux своп / Solaris
/dev/sdc3       967707405   976125464     4209030   83  Linux
/dev/sdc4       976125465   976446764      160650   83  Linux 

При обмене файлов с компьютером интерес представляет только первый раздел с NTFS системой. Но по умолчанию в моем дистрибутиве (Fedora 14) монтируются все три раздела (исключение составляет 2-ой раздел с подкачкой). Соответственно, задача формулируется следующим образом: отключить автоматическое монтирование разделов /dev/sdc3 и /dev/sdc4 при подключении медиаплеера через USB.
За работу со съемными носителями в Linux традиционно отвечают две подсистемы: udev и hal. Первая подсистема привязывает устройства к корневой файловой системе в директории /dev, а вторая работает на более высоком уровне и определяет что делать с новым устройством: для съемных носителей это что обычно заключается в монтировании носителя в корневую файловую систему. Соответственно, нас интересует уровень hal и мы создаем новое правило hal для медиаплеера iconbit и помещаем его в новый файл /etc/hal/fdi/policy/90-iconbit.fdi. Вот его содержимое:

<?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">
  <device>
    <match key="volume.label" string_outof="iconbit_p3;iconbit_p4">
      <merge key="volume.ignore" type="bool">true</merge>
    </match>
  </device>
</deviceinfo>

На этом примере видно, что правила hal записываются в формате xml. В нашем правиле будут проверяться метки разделов: если метка раздела совпадает с iconbit_p3 или iconbit_p4, то он не будет монтироваться (значение volume.ignore для таких разделов устанавливается в true). Важно отметить, что удобные метки разделов я установил сам. Вместо проверки на совпадение метки раздела можно установить проверку на совпадение с uuid раздела: в этом случае ключом будет не volume.label, а volume.uuid. Атрибут string_outof соответствует выбору между несколькими вариантами, разделенными точкой с запятой; если нужно осуществлять проверку только для одного варианта, то вместо string_outof нужно использовать string.
Всё. Прекрасно. Перезапускаем hal и оно ... не работает. Проблема в том, что в новых дистрибутивах (в Fedora начиная с версии 11) для работы со съемными носителями вместо hal используется подсистема udisks из DeviceKit. В udisks несколько иной подход, и здесь нам таки придется добавлять правила на уровне udev. Итак, создаем файл /etc/udev/rules.d/90-iconbit.rules co следующим содержимым:

# iconbit auxiliary partitions
ENV{ID_FS_TYPE}=="ext3", \
  ENV{ID_FS_LABEL}=="iconbit_p3|iconbit_p4", \
  ENV{UDISKS_PRESENTATION_HIDE}="1"

Теперь, после перезагрузки компьютера, цель достигнута: при подключении медиаплеера к компьютеру через USB монтируется только один раздел с NTFS.
Примеры использования правил udisks можно найти в файле  /lib/udev/rules.d/80-udisks.rules.

Update. В Fedora 17, а может быть даже раньше, система udisks была заменена на udisks2, в которой синтаксис правил опять изменился. Теперь правило для iconbit выглядит так:

# iconbit auxiliary partitions
ENV{ID_FS_TYPE}=="ext3", \
  ENV{ID_FS_LABEL}=="iconbit_p3|iconbit_p4", \
  ENV{UDISKS_IGNORE}="1"

Кроме того, файлы правил теперь находятся в директории /usr/lib/udev/rules.d/. И еще, лично я переименовал 90-iconbit.rules в 98-iconbit.rule (хотя конкретное значение численного префикса в названии файла не играет существенной роли до тех пор, пока указанные в нем правила не пересекаются с правилами из других файлов в этой директории).