Вчера обновлял с 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
Другой пример - ядро. В системе может быть несколько ядер установленных параллельно, каждое предоставляет какие-то имена и версии. И все зависимости работают пока есть хоть одно из них.
noiembrie 22, 2009 0:57
Молодец. Опять нет повода не выпить 😀
noiembrie 23, 2009 10:59
Вчера обновлял с omega 11 – были проблемы только с nvidia драйвером (execstack и прочее). Совет – читаем nVidia HowTo@rpmfusion
Сегодня (прямо сейчас) обновляю удаленно еще одну машину с F10 на F12… пока полет нормальный. Думаю к моменту обновления сервера нашего – процедура будет 100% отлажена.
noiembrie 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).
noiembrie 23, 2009 19:11
и напоследок – если SELinux работает – обязательно нужен relabel (touch /.autorelabel или restorecon -R /)
noiembrie 23, 2009 19:55
а что будет, если обновить сразу с 10 на 12?
I want blood!
noiembrie 23, 2009 20:21
фигушки – не пойдет. RPM с поддержкой LZMA сжатых пакетов есть только в F11.
noiembrie 23, 2009 21:55
это хорошо, что есть испытательный полигон.
noiembrie 24, 2009 20:01
и что, пакет rpm для f12 пожат через LZMA? Почему для него не сделали исключение? Это что-ж получается, экономишь пару килобайт траффика, но ценой пары убитых часов на обновление на „транзитную” версию дистра?
Как вариант – поставить вручную rpm из f11, и потом подключить репы от f12 🙂
noiembrie 24, 2009 23:14
Rpm это пол беды. Есть yum, который привязан к питону, а последний каждый релиз меняет версию. Итог куча проблем с зависимостями.
noiembrie 25, 2009 8:52
>>Итог куча проблем с зависимостями.
только если что-то ставить как не было предусмотрено разработчиками 🙂
noiembrie 25, 2009 11:10
Олег, а причём тут yum? Это-ж frontend над rpm – пусть себе старый yum на старом питоне разберёт зависимости, и установит посреством RPM новую версию себя 🙂
noiembrie 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
noiembrie 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)
noiembrie 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 Другой пример - ядро. В системе может быть несколько ядер установленных параллельно, каждое предоставляет какие-то имена и версии. И все зависимости работают пока есть хоть одно из них.