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

В общем-то, не обязательно /, в общем случае это точка монтирования файловой системы, в которой находятся директории /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

Интеграция гистограмм CERN ROOT в Qt GUI Geant4

Собственно, возможность открывать гистограммы из GUI Geant4 я прикрутил уже давно. Реализацию кооперации ROOT и Geant4 можно найти в исходном коде ChargeExchangeMC, который поставляется вместе с Geant4 как один из advanced examples. Эта реализация основана на использовании бэкенда Qt CERN ROOT, поэтому она доступна только при использовании плагина визуализации Qt Geant4.

Базовая реализация интеграции гистограмм в ChargeExchangeMC (входящая в состав последней версии Geant4) была основана исключительно на вводе пользователем команд в командной строке Geant4. Но недавно я подумал, а почему бы не создать специальное меню, в котором будут перечислены все имеющиеся гистограммы в естественном древовидном порядке. При клике на имени гистограммы в меню она будет отображаться в канвасе: это намного проще и естественнее, чем набирать вручную команду листинга гистограмм, затем выбирать из полученного списка нужную гистограмму и вводить новую команду для ее отображения.

На следующей картинке изображена сессия Qt Geant4 c одной из гистограмм, изображающей пучок, прошедший сквозь входной мониторный счетчик. Гистограмма была открыта из меню Histo, находящемся в верхней левой части окна справа от меню Viewer. Все картинки ниже кликабельны.

А это меню Histo в развернутом виде:

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

Самой главной технической сложностью здесь было построение подменю. Интерфейсы GUI Geant4 их просто не поддерживают. Один из вариантов реализации поддержки подменю - субклассинг G4UIQt - мне не понравился, так как из пушки по воробьям. В итоге я решил добавить новую функцию AddSubmenu() прямо в класс CexmcHistoManager. Вот реализация функции BuildMenuTree(), которая рекурсивно строит меню гистограмм, и функции AddSubmenu():

void  CexmcHistoManager::BuildMenuTree( G4UIQt *  session,
                                        const G4String &  menu, TList *  ls )
{
    TIter      objs( ls );
    TObject *  obj( NULL );

    while ( ( obj = ( TObject * )objs() ) )
    {
        G4String  name( obj->GetName() );
        G4String  title( obj->GetTitle() );

        if ( obj->IsFolder() )
        {
            AddSubmenu( session, menu, name, title );
            BuildMenuTree( session, name, ( ( TDirectory * )obj )->GetList() );
        }
        else
        {
            G4String  options( name );

            do
            {
                if ( obj->InheritsFrom( TH3::Class() ) &&
                     ! drawOptions3D.empty() )
                {
                    title = G4String( "3: " ) + title;
                    options += G4String( " " ) + drawOptions3D;
                    break;
                }
                if ( obj->InheritsFrom( TH2::Class() ) &&
                     ! drawOptions2D.empty() )
                {
                    title = G4String( "2: " ) + title;
                    options += G4String( " " ) + drawOptions2D;
                    break;
                }
                if ( obj->InheritsFrom( TH1::Class() ) &&
                     ! drawOptions1D.empty() )
                {
                    options += G4String( " " ) + drawOptions1D;
                    break;
                }
            } while ( false );

            G4String  cmd( CexmcMessenger::histoDirName + "draw " + options );
            session->AddButton( menu, title.c_str(), cmd );
        }
    }
}

void  CexmcHistoManager::AddSubmenu( G4UIQt *  session,
                                     const G4String &  parent,
                                     const G4String &  name,
                                     const G4String &  label )
{
  QMenu *  menu( new QMenu( label.c_str() ) );
  QMenu *  parentMenu( ( QMenu * )session->GetInteractor( parent ) );

  parentMenu->addMenu( menu );
  session->AddInteractor( name, ( G4Interactor )menu );
}

Предполагается, что BuildMenuTree() будет вызвана в момент инициализации менеджера гистограмм примерно таким образом:

    G4UIQt *  qtSession( dynamic_cast< G4UIQt * >( session ) );

    if ( qtSession )
    {
        qtSession->AddMenu( histoMenuHandle, histoMenuLabel );
        BuildMenuTree( qtSession, histoMenuHandle, gDirectory->GetList() );
    }

Здесь session - указатель на объект типа G4UIsession, histoMenuHandle и histoMenuLabel - строки, первая задается произвольно - это дескриптор нового главного меню в строке меню (menu bar), вторая - имя этого меню, в нашем случае она равна Histo.

Этого кода еще нет в составе ChargeExchangeMC, но я думаю добавить его к следующему релизу Geant4.

Как изящно разбить на несколько строк длинный строковый литерал в bash

Под изяществом я здесь понимаю простую возможность контролировать отступы от левого края перенесенных частей литерала. Возьмем, к примеру, следующий алиас g4conf, который я хочу поместить в сценарий $HOME/.bashrc.

alias g4conf='cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR -DGeant4_DIR=$G4CONFIGDIR'

Этот алиас позволяет не писать в терминале длинные команды каждый раз, когда нужно сконфигурировать билд приложения с использованием библиотеки Geant4 (см. мой предыдущий пост). Кстати, обратите внимание на то, что значение алиаса взято в одинарные кавычки: это запрещает интерпретацию переменных среды в момент чтения интерпретатором сценария .bashrc и переносит ее на момент выполнения команды.

К сожалению, эта строка не умещается в 80 символов, чего я всегда стараюсь придерживаться в любом коде. Возникает вопрос о ее переносе. Удобнее всего перенести на новую строку последний аргумент cmake -DGeant4_DIR=$G4CONFIGDIR. Очевидное решение - использовать обратный слэш.

alias g4conf='cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR \
                    -DGeant4_DIR=$G4CONFIGDIR'

Это сработает, хотя и выглядит некрасиво. Так, если ввести в терминале команду alias g4conf, то она выведет вот такую кривулю:

alias g4conf='cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR \
                    -DGeant4_DIR=$G4CONFIGDIR'

Но самое главное - это то, что добавление дополнительных пробелов во многих случаях недопустимо или нежелательно, например при объявлении переменных среды PS1 и PS2. Другой вариант - сформировать две отдельных строки и соединить их обратным слэшем - тоже сработает неправильно.

alias g4conf='cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR '\
                   '-DGeant4_DIR=$G4CONFIGDIR'

На этот раз алиас будет просто неверным.

$ alias g4conf
alias g4conf='cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR '

И это неудивительно. Такой перенос строки вместо конкатенации двух ее частей формирует два аргумента для alias, при этом перенесенный второй аргумент просто игнорируется, что мы и видим в выводе команды alias g4conf.

Очень классное решение я подсмотрел здесь. Оно заключается в нецелевом использовании обратных кавычек.

alias g4conf='cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR '`
                  `'-DGeant4_DIR=$G4CONFIGDIR'

На этот раз вывод команды alias g4conf будет таким, каким мы ожидали его увидеть:

alias g4conf='cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR -DGeant4_DIR=$G4CONFIGDIR'

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

В строках с двойными кавычками или без кавычек вовсе этот подход работает еще лучше. Поскольку обратные кавычки интерпретируются внутри двойных кавычек, то нет нужды расщеплять длинную строку вставкой промежуточных двойных кавычек, cклеенных перемычкой из обратных кавычек: достаточно просто вставить обратные кавычки в нужном месте. Например:

$ echo "My shell is `
>      `$SHELL"
My shell is /bin/bash

То же самое при отсутствии двойных кавычек:

$ echo My shell is `
>      `$SHELL
My shell is /bin/bash

Проблемы, с которыми я столкнулся при компиляции нового Geant4 10.0

Новая версия замечательной библиотеки Geant4 вышла 6 декабря. Я решил написать данную статью, так как встретился с одним интересным багом, который не давал скомпилировать новый Geant4. Баг связан не с самой библиотекой Geant4, и даже не с cmake, а с компилятором moc из Qt4.

Итак, последние версии Geant4 компилируются исключительно с помощью cmake. Для этого создается новая директория, например geant4.10.00-build/, и в ней запускается cmake. Я обычно использую псевдографическую оболочку ccmake (см. здесь) или обычный консольный cmake в интерактивном режиме (с опцией -i) - это позволяет включить различные опции, выключенные по умолчанию. Так, для своих нужд я обычно включаю опции GEANT4_USE_GDML, GEANT4_USE_OPENGL_X11 и GEANT4_USE_QT. Кроме того, в версии Geant4 10.0 появилась возможность включить многопоточную обработку событий при компиляции библиотеки с опцией GEANT4_BUILD_MULTITHREADED: ее включение позволит протестировать эту новую киллер-фичу.

По завершении конфигурирования билда cmake запускаем обычный make. Ждем окончания компиляции, если повезет... Мне не повезло. Когда статус достиг 84%, она прервалась с таким сообщением об ошибке:

[ 84%] Generating basic/include/moc_G4UIQt.cxx
moc: Cannot open options file specified with @
Usage: moc [options] <header-file>
  -o<file>           write output to file rather than stdout
  -I<dir>            add dir to the include path for header files
  -E                 preprocess only; do not generate meta object code
  -D<macro>[=<def>]  define macro, with optional definition
  -U<macro>          undefine macro
  -i                 do not generate an #include statement
  -p<path>           path prefix for included file
  -f[<file>]         force #include, optional file name
  -nn                do not display notes
  -nw                do not display warnings
  @<file>            read additional options from file
  -v                 display version of moc
make[2]: *** [source/interfaces/basic/include/moc_G4UIQt.cxx] Ошибка 1
make[1]: *** [source/interfaces/CMakeFiles/G4interfaces.dir/all] Ошибка 2
make: *** [all] Ошибка 2

Это и есть тот самый интересный баг, который я анонсировал в начале статьи. Для его воспроизведения требуется стечение нескольких обстоятельств: Geant4 должен компилироваться с поддержкой Qt, мажорная версия Qt не должна быть выше 4 (на моей Fedora 19 установлена Qt4 8.5) и в полном пути к директории, из которой выполняется cmake, должны присутствовать нелатинские символы (у меня эта директория находилась в $HOME/Загрузки/). Выяснилось, что во всем виноват компилятор moc, который ошибочно обрабатывает опцию @<file>, если в ней присутствуют нелатинские символы. В этом багрепорте описана проблема. Оказалось, что она уже решена в Qt5 и, поскольку ее проявления должны быть весьма редкими, то чинить ее в Qt4 нет смысла. Что же делать, если вас постигла такая неудача? Да просто строить билд Geant4 в директории, в пути к которой нет нелатинских символов!

После успешного завершения компиляции выполняем make install, переходим в директорию, куда были установлены данные (она задается переменной cmake GEANT4_INSTALL_DATADIR), и проверяем все ли они на месте: у меня почему-то не оказалось данных в поддиректориях G4PII1.3, G4SAIDDATA1.1 и RealSurface1.0, и из-за этого уже скомпилированное и запущенное приложение упало при запуске первого же события. В случае отсутствия данных в поддиректориях скачиваем их отсюда (из раздела Data Files) и устанавливаем вручную.

Теперь о настройках среды. Я уже рассказывал об этом здесь. Но, поскольку в новой версии Geant4 использование простого Makefile больше не поддерживается, то и сорсинг geant4make.sh больше не нужен. Соответственно, в $HOME/.bash_profile теперь помещаем такие строки:

export G4ROOT=/usr/local/geant4
export G4CONFIGDIR=$G4ROOT/lib64/Geant4-10.0.0
export G4WORKDIR=$HOME/geant4

[ -f $G4ROOT/bin/geant4.sh ] && . $G4ROOT/bin/geant4.sh

PATH=$PATH:$G4WORKDIR/bin

Для компиляции приложений, которые используют Geant4, нужно использовать cmake. Создаем отдельную директорию, переходим в нее и конфигурируем билд:

cmake -DCMAKE_INSTALL_PREFIX:PATH=$G4WORKDIR -DGeant4_DIR=$G4CONFIGDIR <path-to-srcs>

Здесь <path-to-srcs> - это директория с исходниками приложения. В принципе, билд можно сконфигурировать прямо внутри этой директории и аргумент cmake <path-to-src> в этом случае не нужен, однако это замусорит директорию с исходниками, поэтому такой подход обычно не рекомендуют. После успешной конфигурации запускаем make и, если нужно, make install.

Еще одна проблема, с которой я столкнулся при компиляции своего приложения - это огромное количество предупреждений о перекрытии (shadowing) имен. Дело в том, что в новой версии Geant4 в скрипты cmake была добавлена опция компилятора -Wshadow, которая выдает предупреждения, если, например, имена формальных параметров конструкторов класса и их членов совпадают. Я писал об этом здесь. Проблема в том, что такой уж у меня стиль: я всегда именую формальные параметры конструкторов и члены класса, которые они инициализируют, одинаково. Такой подход полностью противоречит модели, в которой перекрытия имен не дозволяются. Как быть? Ведь я не собираюсь переименовывать огромное количество членов всевозможных классов в своем проекте только для того, чтобы убрать эти предупреждения. Оказывается, их легко подавить, если вставить в файл CMakeLists.txt строку

add_definitions(-Wno-shadow)

где-нибудь внизу после включения ${Geant4_USE_FILE}. В этом случае противоположная опции -Wshadow опция -Wno-shadow победит исходно установленную -Wshadow и предупреждения уйдут.