Summary: | не корректная сборка/упаковка | ||
---|---|---|---|
Product: | Branch p8 | Reporter: | stalker <stalker> |
Component: | mariadb-server | Assignee: | Andrey Cherepanov <cas> |
Status: | NEW --- | QA Contact: | qa-p8 <qa-p8> |
Severity: | normal | ||
Priority: | P3 | CC: | nickel, shaba |
Version: | не указана | ||
Hardware: | all | ||
OS: | Linux |
Description
stalker
2019-07-03 23:04:50 MSK
(В ответ на комментарий №0) > По причине того, что он пишет в /db не в чруте.. Проблема в том, что mysql_upgrade не знает о чруте. И нет в нем, по умолчанию, механизма как о пути к chroot сообщить. В MySQL-server до версии 8.0.16 у нас был костыль решавший эту проблему: http://git.altlinux.org/gears/M/MySQL.git?p=MySQL.git;a=commitdiff;h=e87f39c9310ff4dd6203511e20fc13644be6a158 Затем функционал обновления перенесли в сам сервер. Вопрос: не захочет ли upstream mariadb последовать по тому же пути? Код клиента несколько различается, что не позволяет применить патч на два фронта сразу. Объехать, наверное, проще всего так: # control mysqld-chroot disabled # mysql_upgrade # control mysqld-chroot enabled запись mysql_upgrade_info это другая проблема, давайте их не смешивать. mariad-upgrade успешно отрабатывает, только не может записать mysql_upgrade_info. Я ошибок, типа "mysql"."innodb_table_stats" not found, не вижу. |