В тестовом репозитории по умолчанию активен профиль Gentoo 17.1. Во время обновления ревизией будет выполнена подготовка системы к работе с новым профилем, обновлены основные пакеты sys-devel/gcc, sys-devel/binutils, sys-libs/glibc и занижены версии других пакетов (~150 шт.), которые нужно будет так же переустановить для завершения миграции. По завершении обновления директория /lib32 будет удалена.
Александр, доброго дня! Существует вероятновсть, что в период этих обновлений будут нестабильно работать уже установленные ОС? Или всё будет в порядке? Спасибо.
Пока вы явно не выполните cl-update.
Здравствуйте!
Сегодня на компах с калькулейтом внезапно перестал работать wine. Увидел изменения в реорганизации папок lib и lib32. Гугленьем понял что это связано с этим профилем. А как завершить то тогда этот переход?
Доброго времени суток!
Поддерживаю вопрос от asupsam: как правильно завершить этот переход?
Спасибо
дополню: изначально стоял wine-4.0.1.
Так и не понял, как выполнилось частичное обновление: lib32 переименовался в lib. lib32 стал симовлической ссылкой. То же и в /usr.
На другом компе как ни пытался, не мог вызвать это обновление, т.е. структура lib оставалась старая.
запустил cl-update. Выкачал 1,5Гб пакетов 8-|. в итоге грязно ругнулся, что не может разрешить зависимости и предложил выполнить:
emerge --update --newuse --deep --with-bdeps=y @world
что я и сделал.
После снова запустил cl-update, и он доудалил старые пакеты, в.т.ч. и wine-4.0.1.
Но wine опять же не работал, т.к. в /usr/bin слетели все симлинки на wine!!!
И только переустановив пакет wine по новой все восстановилось.
И все это случилось на всех компах в организации. Обновлял до конца дня.
Вопрос знающим, как этого можно было избежать?
1.5 Гб говорит о том, что перед переходом на новый профиль вы “давно” не обновлялись. В моем случае (был установлен wine), переход на новый профиль прошел с небольшими проблемами, которые решились повторным обновлением.
Как вариант, рекомендую обновляться не реже 1 раза в месяц и держать одну машину на тестовое обновление. (Обновили её, а потом, если всё ОК, обновлять остальные). Прилагаю скрин с моей проблемой . У меня перед переходом все пакеты были в актуальном состоянии.
Добрый день, какой пакет wine и для чего кто использует? wine-any замаскировали и пришлось его слить, а все ярлыки через него(
Сам пару дней не спеша ноут обновлял, последний раз то ли весной, то ли летом его обновлял. Тут конечно вопрос о том, что на сайте стабильный релиз 18.12, без опыта gentoo пользования, обновить утилитой не возможно, в течении года portage всегда сильно меняется. Это может оно и лучше, пусть малоопытные и продакшен бинарное обновление используют и все доп пакеты в set custom вносят.
Ну как давно, с июля месяца. Самое смешное, что при установке были включены автообновления. Но компы почему то сами не обновлялись получается. А если руками выполнять cl-update на всех компах(а может их 100 штук) раз в месяц устанешь.
Самый главный вопрос, что изменило структуру папок lib32 и lib64? Ведь изначально cl-update выполнен не был.
Вроде wine-any в генту хотят убрать из репов.
/usr/lib/wine-staging-4.12.1/bin/wine: error while loading shared libraries: libwine.so.1: cannot open shared object file: No such file or directory
Наверно из-за того, что неправильная версия установлена. По идее должна быть без rc73
$ emerge -s wine-staging
Local copy of remote index is up-to-date and will be used.
[ Results for search key : wine-staging ]
Searching...
* app-emulation/wine-staging
Latest version installed: 4.12.1_rc73
Homepage: https://www.winehq.org/
Description: Free implementation of Windows(tm) on Unix, with Wine-Staging patchset
License: LGPL-2.1
[ Applications found : 1 ]
Еще надо смотреть в /etc/portage/
Мне пришлось поправить /etc/portage/package.keywords/zz-autounmask
Пользователь вообще не должен участвовать в этом и не должно у него быть каких-либо прав на что-то подобное. Он никак не должен вмешиваться в это. Админ и только админ или хотя бы привилегированный пользователь.
Переход с профиля 17.0 до 17.1 не очевидный и подразумевает выполнение ряда действий пользователем - запуск скрипта миграции, предварительного обновления пакетов gcc, glibc, binutils, обновленя всех зависимых от миграции пакетов, которые к этому времени уже должны быть пересобраны с новым профилем. Единовременно в оверлее Calculate профили стали наследовать Gentoo 17.1, а в репозитории все пакеты уже были пересобраны. Был выбор, либо остановить обновления с предложением почитать инструкцию для ручного выполнения каких-то действий пользователем, либо сделать этот процесс максимально прозрачным используя существующий функционал утилит. Мы приняли решение саму миграцию выполнить ревизией обновления. Это логично, т.к. после перехода пакеты репозитория становятся несовместимыми с вашей системой и если пользователь захочет потом использовать emerge, у него ничего не должно поломаться. Последующую миграцию выполняет обновление пакетов при помощи cl-update, который сам выполнит установку в правильной очередности. И лишь следуюий вызов cl-udate сверит что все было проведено успешно и удалит /lib32.
Как этого избежать? Выполнять обновления утилитой cl-install --update. Если компьютеры введены в домен CDS, положите новый образ в /var/calculate/remote/linux на сервере. Для удобства добавьте вызов cl-install в скрипт выключения компьютера. Никаких параметров больше указывать не нужно. При авторазметке, выполненняемой по умолчанию во время установки, в системе есть второй раздел для обновления. С установой обновления образом все необходимые настройки будут перенесены, а данные сохранены в общем для двух систем разделе /var/calculate. На моем офисном ПК подобное обновление занимает каких-то 1,5 мин с гарантией, что если что-то не будет работать вновой системе, я всегда смогу загрузиться в предыдущей рабочей версии.
Спасибо за ответ!
Т.е. если включено автообновление системы во время установки, то пакеты все равно не обновляются, пока не запустишь cl-update? И в чем разница между “cl-install --update” и cl-update?
Нет, я его не запускал изначально.
cl-install обновит систему из готового свежего iso в соседний системный раздел, все установленные вами программы придется ставить заново. cl-update обновит текущую систему и все установленные вами программы, но это всегда риск, можете за пять минут управиться, а можете несколько дней потратить).
У каждого варианта есть свои плюсы и минусы. Выбирать вам.
Будет система с настройками по умолчанию, как если бы с нуля с диска поставить?
да, но все пользователи, разметка, точки монтирования и настройки перенесутся в новую систему.
Хм, пользователи в основном работают через wine, т.е. нативными программами практически никакими не пользуются. Соответственно все настройки хранятся в /home/username, а также, .тк. комп входит в домен, в /home/domainname/username.
Это все перенесется в новую систему, и достаточно будет установить wine, он подхватит существующий профиль?
На самом деле wine тоже установится во время первой загрузки если он (как и другие доустановленные пакеты) прописан в /etc/portage/sets/custom-cldx.