(ru) Миграция с F11 на F12

    2009-11-21 11:44 | Autor: Oleg | Filed under: Oleg

    Sorry, this entry is only available in ru.

    1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5,00 out of 5)
    Loading...

    Etichete: ,

    Comments (14) »


    Număr de comentarii de arătat: 14

    1. jekader:

      Молодец. Опять нет повода не выпить 😀

    2. Vasile:

      Вчера обновлял с omega 11 – были проблемы только с nvidia драйвером (execstack и прочее). Совет – читаем nVidia HowTo@rpmfusion
      Сегодня (прямо сейчас) обновляю удаленно еще одну машину с F10 на F12… пока полет нормальный. Думаю к моменту обновления сервера нашего – процедура будет 100% отлажена.

    3. Vasile:

      сегодня обновил две машины – 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).

    4. Vasile:

      и напоследок – если SELinux работает – обязательно нужен relabel (touch /.autorelabel или restorecon -R /)

    5. jekader:

      а что будет, если обновить сразу с 10 на 12?

      I want blood!

    6. Vasile:

      фигушки – не пойдет. RPM с поддержкой LZMA сжатых пакетов есть только в F11.

    7. Oleg:

      это хорошо, что есть испытательный полигон.

    8. jekader:

      и что, пакет rpm для f12 пожат через LZMA? Почему для него не сделали исключение? Это что-ж получается, экономишь пару килобайт траффика, но ценой пары убитых часов на обновление на „транзитную” версию дистра?

      Как вариант – поставить вручную rpm из f11, и потом подключить репы от f12 🙂

    9. Oleg:

      Rpm это пол беды. Есть yum, который привязан к питону, а последний каждый релиз меняет версию. Итог куча проблем с зависимостями.

    10. Vasile:

      >>Итог куча проблем с зависимостями.
      только если что-то ставить как не было предусмотрено разработчиками 🙂

    11. jekader:

      Олег, а причём тут yum? Это-ж frontend над rpm – пусть себе старый yum на старом питоне разберёт зависимости, и установит посреством RPM новую версию себя 🙂

    12. Vasile:

      Проверяю на Сэнделе (последняя доступная 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

    13. jekader:

      Да, всё понятно 🙁

      если с 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)

    14. Vasile:

      Если старому софту нужна старая библиотека, или компилятор (интерпретатор), то эту библиотеку упакуют как 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 Другой пример - ядро. В системе может быть несколько ядер установленных параллельно, каждое предоставляет какие-то имена и версии. И все зависимости работают пока есть хоть одно из них.

    Leave a comment

    *