Сегодня решил проапгрейдить рабочую машину с 11 на 12 Fedora. Процесс занял минут 20. Все прошло спокойно и без всяких нареканий. Итог: Fedora release 12 (Constantine).
Вчера обновлял с omega 11 — были проблемы только с nvidia драйвером (execstack и прочее). Совет — читаем nVidia HowTo@rpmfusion
Сегодня (прямо сейчас) обновляю удаленно еще одну машину с F10 на F12… пока полет нормальный. Думаю к моменту обновления сервера нашего — процедура будет 100% отлажена.
сегодня обновил две машины — F10->F11->F12. Резюмирую опыт 4-х yum upgrade:
— Всё происходит на ура.
— вероятна проблема не запуска Xorg при использовании nvidia проприетарного драйвера. (см коммент выше с ссылкой на HowTo)
— после update остаются пакеты с предыдущей системы, так как не у всех пакетов номер версии выше (хотя должен) быть. Проверяются такие пакеты коммандой rpm -qa|grep .fc|grep -v .fc12. Исключаем пакеты из rpmfusion, а также ядра — на всякий случай их лучше оставить некоторое время. остальное удаляем rpm -e —nodeps pkg1 pkg2… а потом yum install pkg1 pkg2..
— для некоторых систем загрузка на новом ядре остановиться — передать параметр ядра intel_iommu=off или использовать сохраненное ядро от F11.
Как правило после апдейта отмечается улучшенная производительность. Причины — более быстрые драйверы intel, nouveau, ati, пересборка дистрибутива под i686 (было i586), исправления регресий в производительности файловых систем (ext3, ext4).
и что, пакет rpm для f12 пожат через LZMA? Почему для него не сделали исключение? Это что-ж получается, экономишь пару килобайт траффика, но ценой пары убитых часов на обновление на «транзитную» версию дистра?
Как вариант — поставить вручную rpm из f11, и потом подключить репы от f12 🙂
Олег, а причём тут yum? Это-ж frontend над rpm — пусть себе старый yum на старом питоне разберёт зависимости, и установит посреством RPM новую версию себя 🙂
Проверяю на Сэнделе (последняя доступная 10-ка):
# pushd /pub/fedora/linux/updates/11/x86_64/
rpm —test -Uvh rpm-4.7.1-3.fc11.x86_64.rpm rpm-libs-4.7.1-3.fc11.x86_64.rpm rpm-python-4.7.1-3.fc11.x86_64.rpm
warning: rpm-4.7.1-3.fc11.x86_64.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2
error: Failed dependencies:
db4-utils = 4.7.25 is needed by rpm-4.7.1-3.fc11.x86_64
libpython2.6.so.1.0()(64bit) is needed by rpm-python-4.7.1-3.fc11.x86_64
python(abi) = 2.6 is needed by rpm-python-4.7.1-3.fc11.x86_64
librpm-4.6.so()(64bit) is needed by (installed) net-snmp-libs-1:5.4.2.1-4.fc10.x86_64
librpm-4.6.so()(64bit) is needed by (installed) net-snmp-1:5.4.2.1-4.fc10.x86_64
librpm-4.6.so()(64bit) is needed by (installed) deltarpm-3.4-11.fc10.1.x86_64
librpmio-4.6.so()(64bit) is needed by (installed) net-snmp-libs-1:5.4.2.1-4.fc10.x86_64
librpmio-4.6.so()(64bit) is needed by (installed) net-snmp-1:5.4.2.1-4.fc10.x86_64
librpmio-4.6.so()(64bit) is needed by (installed) deltarpm-3.4-11.fc10.1.x86_64
если с db4-utils, deltarpm и туе-snmp ещё понятно, то питон — это тяжко. Потянет за собой в могилу полсистемы 😀
Кстати, а что делают под redhat, если разному софту нужны разные версии питона? в Debian есть отдельный пакет python2.6 и отдельный — python2.4. И над ними — метапакет python.
То есть если пакету пофиг на версию питона, ему в зависимости ставят python. А если версия важна — указывают соответствующий пакет.
В репах есть следующие версии:
c python2.4 — An interactive high-level object-oriented
i A python2.5 — An interactive high-level object-oriented
p python2.6 — An interactive high-level object-oriented
p python3 — An interactive high-level object-oriented
p python3.1 — An interactive high-level object-oriented
(то есть в данный момент у меня установлена только версия 2.5)
Если старому софту нужна старая библиотека, или компилятор (интерпретатор), то эту библиотеку упакуют как compat-libname. Пример db4-4.7.25 и compat-db45-4.5.20.
Есть и метапакеты. А в случае с питоном работают virtual provides. Пакет питон экспортирует псевдо имя python(abi) и версию (2.6) и уже софт может затребовать либо python(abi) >= 2.2, либо либо прописать Conflicts: python(abi) < 2.2
Другой пример - ядро. В системе может быть несколько ядер установленных параллельно, каждое предоставляет какие-то имена и версии. И все зависимости работают пока есть хоть одно из них.
Loading...
22, 2009 0:57
Молодец. Опять нет повода не выпить 😀
23, 2009 10:59
Вчера обновлял с omega 11 — были проблемы только с nvidia драйвером (execstack и прочее). Совет — читаем nVidia HowTo@rpmfusion
Сегодня (прямо сейчас) обновляю удаленно еще одну машину с F10 на F12… пока полет нормальный. Думаю к моменту обновления сервера нашего — процедура будет 100% отлажена.
23, 2009 19:06
сегодня обновил две машины — F10->F11->F12. Резюмирую опыт 4-х yum upgrade:
— Всё происходит на ура.
— вероятна проблема не запуска Xorg при использовании nvidia проприетарного драйвера. (см коммент выше с ссылкой на HowTo)
— после update остаются пакеты с предыдущей системы, так как не у всех пакетов номер версии выше (хотя должен) быть. Проверяются такие пакеты коммандой rpm -qa|grep .fc|grep -v .fc12. Исключаем пакеты из rpmfusion, а также ядра — на всякий случай их лучше оставить некоторое время. остальное удаляем rpm -e —nodeps pkg1 pkg2… а потом yum install pkg1 pkg2..
— для некоторых систем загрузка на новом ядре остановиться — передать параметр ядра intel_iommu=off или использовать сохраненное ядро от F11.
Как правило после апдейта отмечается улучшенная производительность. Причины — более быстрые драйверы intel, nouveau, ati, пересборка дистрибутива под i686 (было i586), исправления регресий в производительности файловых систем (ext3, ext4).
23, 2009 19:11
и напоследок — если SELinux работает — обязательно нужен relabel (touch /.autorelabel или restorecon -R /)
23, 2009 19:55
а что будет, если обновить сразу с 10 на 12?
I want blood!
23, 2009 20:21
фигушки — не пойдет. RPM с поддержкой LZMA сжатых пакетов есть только в F11.
23, 2009 21:55
это хорошо, что есть испытательный полигон.
24, 2009 20:01
и что, пакет rpm для f12 пожат через LZMA? Почему для него не сделали исключение? Это что-ж получается, экономишь пару килобайт траффика, но ценой пары убитых часов на обновление на «транзитную» версию дистра?
Как вариант — поставить вручную rpm из f11, и потом подключить репы от f12 🙂
24, 2009 23:14
Rpm это пол беды. Есть yum, который привязан к питону, а последний каждый релиз меняет версию. Итог куча проблем с зависимостями.
25, 2009 8:52
>>Итог куча проблем с зависимостями.
только если что-то ставить как не было предусмотрено разработчиками 🙂
25, 2009 11:10
Олег, а причём тут yum? Это-ж frontend над rpm — пусть себе старый yum на старом питоне разберёт зависимости, и установит посреством RPM новую версию себя 🙂
25, 2009 11:33
Проверяю на Сэнделе (последняя доступная 10-ка):
# pushd /pub/fedora/linux/updates/11/x86_64/
rpm —test -Uvh rpm-4.7.1-3.fc11.x86_64.rpm rpm-libs-4.7.1-3.fc11.x86_64.rpm rpm-python-4.7.1-3.fc11.x86_64.rpm
warning: rpm-4.7.1-3.fc11.x86_64.rpm: Header V3 RSA/SHA256 signature: NOKEY, key ID d22e77f2
error: Failed dependencies:
db4-utils = 4.7.25 is needed by rpm-4.7.1-3.fc11.x86_64
libpython2.6.so.1.0()(64bit) is needed by rpm-python-4.7.1-3.fc11.x86_64
python(abi) = 2.6 is needed by rpm-python-4.7.1-3.fc11.x86_64
librpm-4.6.so()(64bit) is needed by (installed) net-snmp-libs-1:5.4.2.1-4.fc10.x86_64
librpm-4.6.so()(64bit) is needed by (installed) net-snmp-1:5.4.2.1-4.fc10.x86_64
librpm-4.6.so()(64bit) is needed by (installed) deltarpm-3.4-11.fc10.1.x86_64
librpmio-4.6.so()(64bit) is needed by (installed) net-snmp-libs-1:5.4.2.1-4.fc10.x86_64
librpmio-4.6.so()(64bit) is needed by (installed) net-snmp-1:5.4.2.1-4.fc10.x86_64
librpmio-4.6.so()(64bit) is needed by (installed) deltarpm-3.4-11.fc10.1.x86_64
25, 2009 13:53
Да, всё понятно 🙁
если с db4-utils, deltarpm и туе-snmp ещё понятно, то питон — это тяжко. Потянет за собой в могилу полсистемы 😀
Кстати, а что делают под redhat, если разному софту нужны разные версии питона? в Debian есть отдельный пакет python2.6 и отдельный — python2.4. И над ними — метапакет python.
То есть если пакету пофиг на версию питона, ему в зависимости ставят python. А если версия важна — указывают соответствующий пакет.
В репах есть следующие версии:
c python2.4 — An interactive high-level object-oriented
i A python2.5 — An interactive high-level object-oriented
p python2.6 — An interactive high-level object-oriented
p python3 — An interactive high-level object-oriented
p python3.1 — An interactive high-level object-oriented
(то есть в данный момент у меня установлена только версия 2.5)
25, 2009 14:24
Если старому софту нужна старая библиотека, или компилятор (интерпретатор), то эту библиотеку упакуют как compat-libname. Пример db4-4.7.25 и compat-db45-4.5.20.
Есть и метапакеты. А в случае с питоном работают virtual provides. Пакет питон экспортирует псевдо имя python(abi) и версию (2.6) и уже софт может затребовать либо python(abi) >= 2.2, либо либо прописать Conflicts: python(abi) < 2.2 Другой пример - ядро. В системе может быть несколько ядер установленных параллельно, каждое предоставляет какие-то имена и версии. И все зависимости работают пока есть хоть одно из них.