| Summary: | Конфликт файлов при апгрейде пакета filesystem | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | serpiph <serpiph> |
| Component: | filesystem | Assignee: | placeholder <placeholder> |
| Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus |
| Severity: | normal | ||
| Priority: | P5 | CC: | arseny, glebfm, iv, ldv, placeholder, vt |
| Version: | unstable | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
|
Description
serpiph
2024-07-03 22:03:47 MSK
Руками перенёс всё из старых каталогов в новые, создал взамен симлинки вместо старых каталогов -и только тогда пакет обновился. Как бы эту старую проблему с rpm порешать? Похоже, проблема в том, что у Вас usrmerge-hier-convert не отработал. Не сохранились ли у Вас его логи, которые вот тут вот спрятаны за многоточием?
> filesystem-3.1-alt1: Starting usrmerge-hier-convert...
> ...
> usr-m: No potentially destructive changes done, cleaning up.
(In reply to Ivan A. Melnikov from comment #2) > Похоже, проблема в том, что у Вас usrmerge-hier-convert не отработал. Не > сохранились ли у Вас его логи, которые вот тут вот спрятаны за многоточием? > > > filesystem-3.1-alt1: Starting usrmerge-hier-convert... > > ... > > usr-m: No potentially destructive changes done, cleaning up. Сами логи не сохранились. Были сообщения про бэкап каталогов, проверку и восстановление каталогов. Словно программа возвращала систему обратно в исходное состояние. Результатов внесения изменений я не увидел. (In reply to serpiph from comment #3) > (In reply to Ivan A. Melnikov from comment #2) > > Похоже, проблема в том, что у Вас usrmerge-hier-convert не отработал. Не > > сохранились ли у Вас его логи, которые вот тут вот спрятаны за многоточием? > > > > > filesystem-3.1-alt1: Starting usrmerge-hier-convert... > > > ... > > > usr-m: No potentially destructive changes done, cleaning up. > > Сами логи не сохранились. Были сообщения про бэкап каталогов, проверку и > восстановление каталогов. Словно программа возвращала систему обратно в > исходное состояние. Результатов внесения изменений я не увидел. Логично: никакие файлы не успели поменяться. Из-за bug 50128 rpm даже после завершения pretrans-скрипта с кодом != 0 всё равно пытается оценить устанавливаемость пакетов в транзакции, что и приводит к 5 строчкам "file ... from install of ... conflicts with file from package ...". Это, конечно, затрудняет чтение :( Вывод должен был закончиться на: usr-m: No potentially destructive changes done, cleaning up. error: lua script failed: [string "%pretrans(filesystem-3.1-alt1.x86_64"]:32: exit Повторите команду ещё раз; там перед завершением должны написать, в чём дело. Скорее всего, hier-convert обнаружил, что нельзя просто так взять и совершить cp -a, не затерев что-нибудь важное, и что он не знает, как поступить. (In reply to serpiph from comment #0) > Решил на своей системе пройти переход на usrmerge. Установил пакеты usrmerge > и usrmerge-hier-convert, пытаюсь дать команду > # apt-get install filesystem Это же обновление с сизифа на сизиф? Тогда, возможно, нужно перед этим filesystem обновить некоторые пакеты, прежние версии которых совсем несовместимые с merged-usr. Как минимум vim-minimal, vim-common. for i in vim-common vim-minimal ash; do rpm -q "$i" && apt-get install "$i" done hier-convert в этом случае пишет, что вне префикса и в префиксе разные файлы. В процессе ручного копирования файлов в новые места внктри /usr обнаружил, что в /lib и /lib64 есть несколько файлов, которые были и в /usr/lib и /usr/lib64 соответственно. Например, libusb. Они идентичные друг другу. Никаких предупреждений на экране не было, только перечисление каталогов, которые проверял скрипт. Сейчас не знаю, как проверить, так как после ручного вмешательства удалось обновить filesystem. Но копии старых каталогов /lib, /lib64 у меня остались на диске. Можно попробовать их вернуть назад. Или взять другую систему Сизиф, где я ещё такого обновления не проводил, и посмотреть там. (In reply to serpiph from comment #6) > В процессе ручного копирования файлов в новые места внутри /usr обнаружил, > что в /lib и /lib64 есть несколько файлов, которые были и в /usr/lib и > /usr/lib64 соответственно. Например, libusb. Они идентичные друг другу. > Никаких предупреждений на экране не было, только перечисление каталогов, > которые проверял скрипт. В случае с libusb он сам может исправить ситуацию: там в /%_lib и /usr/%_lib лежат либо одинаковые файлы, либо симлинк и его цель, не помню уже. https://git.altlinux.org/gears/u/usrmerge.git?p=usrmerge.git;a=shortlog Почитать, какие конфликты скрипт исправляет самостоятельно, можно так: git log --grep detect Или вместо этого можно прочитать блочные комменты начиная отсюда и до конца строки 335: https://git.altlinux.org/gears/u/usrmerge.git?p=usrmerge.git;a=blob;f=usrmerge/hier-convert;h=6eac897c6ce4c90a50a8ed023f2c697b88c29bf8;hb=f92a040ae0d619c4bc79bfae689217bd5255776b#l204 (In reply to serpiph from comment #6) > Сейчас не знаю, как проверить, так как после ручного вмешательства удалось > обновить filesystem. Ну ладно. > Но копии старых каталогов /lib, /lib64 у меня остались > на диске. Можно попробовать их вернуть назад. Или взять другую систему > Сизиф, где я ещё такого обновления не проводил, и посмотреть там. Если обнаружите неучтённый конфликт между пакетами A и B, который нельзя исправить обновлением A и B — пишите. :) В каталоге /lib64 оказались битые символьные ссылки: winbind.so и winbind_wins.so на файлы с суффиксом версии в том же каталоге. При этом сами нужные файлы лежали в /usr/lib64, но не было символьных ссылок, указанных выше. |