про суровую реальность :)

Несколько дней назад, я потратил часов 12 на развлекуху с LVM в гостевой системе xen domU и “замечательную” утилиту preupgrade, которая теперь используется в Fedora для обновления.

Исходные данные
у меня есть мощный сервер, на котором крутится большое кол-во виртуалок служебного характера, некоторые из них на базе Fedora, например тикеты RT или ejabberd, так как эти пакеты в Fedora постоянно поддерживаются, а не то что в CentOS. По-умолчанию виртуалки я создаю на отдельном LVM-томе, размером примерно 5 гиг, /var чаще всего выношу на отдельный LVM том, который также прописываю в конфиг, например, как /dev/xvdb.

Задача
Встала задача обновить Fedora с десятки до 12 на одной из виртуалок. Как известно, теперь для обновления ОС есть утилита preupgrade, которая скачивает все необходимые пакеты, кэширует их в/var/cache/yum, в /boot прописывает свое ядро, в grub новая запись, при перезагрузке запускается anaconda и начинает процесс обновления.

Место на диске
Первое с чем я столкнулся – мне не хватило места на диске. Я решил его увеличить. Первое о чем я подумал – добавить еще один том в виртуалку и смонтировать в /var. Второе, что мне пришло в голову(и как оказывается не только мне), это опять же добавить в систему еще одно устройство, например, /dev/xvdb, это может быть тот же LVM раздел на dom0, и за счет него расширить VolumeGroup, которая присутствует в виртуалке. Я это сделал, запустил снова preupgrade, скачал пакеты и перезагрузился. Далее, я столкнулся с тем, что ядро от preupgrade не знает что такое /dev/xvdb, и предлагает стереть это устройство. Оба варианта не сработали. Очевидно, со вторым дисковым устройством ничего не выйдет, поэтому я увеличил размер LVM тома под виртуалку на dom0, в самой виртуалке создал еще один раздел, за счет него расширил VolumeGroup, увеличил размер тома и тогда все стало хорошо. Ненадолго..

/boot
Еще одна перезагрузка, идет процесс preupgrade и вываливается, говорит, что в /boot нет места! Дело в том, что preupgrade записывает в /boot необходимые для апгрейда файлы, например, свое ядро. Я всегда делаю раздел /boot 200 мегабайт и всегда считал, что на самом деле это просто дохрена, 3-4 ядра постоянно хранится. Не тут то было. Даже удалив все лишние ядра, удалив папку efi и splash.xpm.gz, мне все еще не хватает места в /boot!!! Встала задача увеличить /boot в гостевой системе. Дело в том, что /boot идет первым разделом(xvda1), затем pv(xvda2) от LVM группы виртуалки, я надеялся, что parted сможет “раздвинуть” xvda1 и xvda2, но он не смог. Честно говоря я не придумал способа проще, как снова увеличить раздел под гостевую систему и создать новый том для /boot, сделать его загрузочным и установить на него grub. Я сделал это. Но дальше столкнулся с тем, что anaconda при ребуте не запускается, а сразу запускается второе ядро. Чего я только не пробовал – нет и все. Понять суть данного процесса я не смог и тут..

Тут мой мозг сломался и пока не починился Возможно, это произошло из-за того, что в какой-то момент, уже практически отчаявшись использовать preupgrade, я начал апгрейд руками через yum и столкнулся с тем, что он категорически отказывался видеть несколько пакетов от F-11(примерно штук 100), в том числе httpd, не хотел разрешать зависимости, так как старому httpd от F-10 требовался libcrypto и libssl от F-10, плюнув на все я обновил все пакеты кроме этих. В общем, я буду мучаться дальше.

Чем хорошо делать domU виртуалки на базе LVM – это возможность менять размеры практически на лету, отсутствие фрагментации, как если бы образ был в файле и самое главное снапшоты! Мне пришлось несколько раз откатывать то, что я наворотил

Возможно никакой особой ценности данная заметка не представляет, но я хотя бы не забуду, о тех манипуляциях, которые я производил.

Главное, что я осознал, если вы хотите использовать в виртуалке Fedora, то нужно:

1. создавать раздел достаточно размера, чтобы смог вместить в себя пакеты для апгрейда
2. создавать /boot раздел не менее 300мб

Линки по теме
Доступ к разделам диска domU из dom0
Изменение размера LVM тома в domU, путем добавления нового дискового устройства в domU, а затем в LVM группу