ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Удалять остатки старых ядер в remove-old-kernels | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sergey Y. Afonin <asy> |
| Component: | kernel-modules-rtl88x2bu-std-def | Assignee: | Andrey Cherepanov <cas> |
| Status: | REOPENED --- | QA Contact: | qa-sisyphus |
| Severity: | enhancement | ||
| Priority: | P5 | CC: | alexvk72, boyarsh, cas, evg, glebfm, kernelbot, lav, ldv, mike, rider, sbolshakov, serega2005, shrek, sin, vitty, vsu, vt, zerg |
| Version: | unstable | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
(In reply to Sergey Y. Afonin from comment #0) > Логика может быть такой: Хотя нет, логика поиска набора исключений должна быть сложнее. Есть kernel-image-domU-std-def, а в p9, смотрю, появились kernel-image-rt, kernel-image-lts и т.п. Что за хвосты? (In reply to Vitaly Chikunov from comment #2) > Что за хвосты? Почему-то неопакеченные файлы в /lib/modules/`uname -r` от каждого ядра, которое когда-то было установлено. Хотя, может быть, это стоит повесить на сами ядра. Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться. Посчитал сам. $ less orphaned.txt.gz | grep /lib/modules/ kernel-modules-nvidia-std-def /lib/modules/5.4.32-std-def-alt1/.versions kernel-modules-nvidia-un-def /lib/modules/5.5.17-un-def-alt1/.versions kernel-modules-xtables-addons-std-def /lib/modules/5.4.32-std-def-alt1/xtables-addons kernel-modules-xtables-addons-un-def /lib/modules/5.5.17-un-def-alt1/xtables-addons Последний в changelog: kernel-modules-nvidia-std-def zerg kernel-modules-xtables-addons-std-def rider (In reply to Vitaly Chikunov from comment #5) > Посчитал сам. Это не всё. Ещё там остаются /lib/modules/`uname -r`/modules.* (In reply to Sergey Y. Afonin from comment #6) > Это не всё. Ещё там остаются /lib/modules/`uname -r`/modules.* Хотя это было в std-def в p8. В p9 остаётся каталог misc, видимо от kernel-modules-e1000e-std-def. А про nvidia-std-def у меня какое-то дежавю, что я, вроде бы, про это где-то писал. Но баг что-то не вижу. (Ответ для Vitaly Chikunov на комментарий #5) > kernel-modules-nvidia-std-def /lib/modules/5.4.32-std-def-alt1/.versions > kernel-modules-nvidia-un-def /lib/modules/5.5.17-un-def-alt1/.versions > Последний в changelog: > kernel-modules-nvidia-std-def zerg Файлы в /lib/modules/[...]/.versions принадлежат моим пакетам. Каталог .versions должен принадлежать kernel-image . > Каталог .versions должен принадлежать kernel-image .
Скажите пожалуйста, почему каталог .versions должен принадлежать пакету kernel-image?
(Ответ для Vitaly Chikunov на комментарий #9) > Скажите пожалуйста, почему каталог .versions должен принадлежать пакету > kernel-image? Потому, что в этом каталоге могут лежать файлы любых других пакетов с модулями к этому ядру. (In reply to Sergey V Turchin from comment #10) > Потому, что в этом каталоге могут лежать файлы любых других пакетов с > модулями к этому ядру. а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с ядром не принадлежит. (In reply to Vitaly Chikunov from comment #4) > Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться. Проще чистить в remove-old-kernels :-) (Ответ для Sergey Y. Afonin на комментарий #11) > > Потому, что в этом каталоге могут лежать файлы любых других пакетов с > > модулями к этому ядру. > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с > ядром не принадлежит. Причём здесь .versions? (Ответ для Sergey Y. Afonin на комментарий #11) > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с > ядром не принадлежит. Если не ошибка, то его тоже надо добавить в ядро. (In reply to Sergey V Turchin from comment #13) > > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с > > ядром не принадлежит. > Причём здесь .versions? Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не разьираться. (Ответ для Sergey Y. Afonin на комментарий #15) > Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не > разьираться. Зачем городить лишние костыли? (In reply to Sergey V Turchin from comment #16) > Зачем городить лишние костыли? С одной стороны согласен, но remove-old-kernels - это одно место, а мантейнеров всех ядер и модулей собрать можно только посредством сизифусчеки и непропуском пакетов в репозиторий. Хотя это тоже одно место. У нас со всех сторон добавлением и удалением файлов управляет пакетный менеджер. Всё остальное -- костыли. (In reply to Sergey V Turchin from comment #10) > (Ответ для Vitaly Chikunov на комментарий #9) > > Скажите пожалуйста, почему каталог .versions должен принадлежать пакету > > kernel-image? > Потому, что в этом каталоге могут лежать файлы любых других пакетов с > модулями к этому ядру. Если это стандартная директория, то где она стандартизована? Если не секрет. В коде ядра нет ссылок на ".versions". Если не найдется стандарт, то запаковывать её должны модули, которые её используют. Иначе любой модуль напридумает себе директорий, а ядро должно их упаковывать? Я согласен с тем, что remove-old-kernels не должен ничего лишнего удалять так как у пользователя могут быть свои, вручную собранные, модули - и он их удалит? (Ответ для Vitaly Chikunov на комментарий #19) > Если это стандартная директория, то где она стандартизована? Если не секрет. А никто не говорил что это стандарт. Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей. > так как у пользователя могут быть свои, вручную собранные, модули - и он их > удалит? С этим я согласен. Было бы неплохо, чтоб подчищал, но чужого(пакетного) не трогал. > А никто не говорил что это стандарт. Стандарт, видимо, слишком сильное слово, имелось ввиду договоренность, упоминание в документации, в коде, общепринятая практика. > Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей. Где про это почитать? 1. Как пакующему любые модули, хотелось бы понять, что такое '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно. Из https://www.altlinux.org/Nvidia назначение .versions (кроме того что там версия) не понятно. Для ядра эта информация там не нужна. 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не перекладывая на другие пакеты. И пока эти "любые пакеты" это только одна nvidia. Пользователь у этой диры только один. > Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей.
Судя по тому, что в пакеты с ядрами не добавлена эта дира - про эту договоренность никто не знает.
(Ответ для Vitaly Chikunov на комментарий #21) > 1. Как пакующему любые модули, хотелось бы понять, что такое > '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно. Да по аналогии, собственно. Драйвера для ATI до этого так и не добрались. > Из https://www.altlinux.org/Nvidia Я там и не участвовал. > Для ядра эта информация там не нужна. Если я правильно понял, у ядра нет common-пакета, поэтому нужна для остальных модулей. > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не > перекладывая на другие пакеты. У нас не принято паковать один и тот же каталог в несколько пакетов. > И пока эти "любые пакеты" это только одна nvidia. Смысл от этого не меняется. > Пользователь у этой диры только один. Нет. Их прямо сейчас может стать 3, но из-за различных недостатков приходится паковать в один. (Ответ для Vitaly Chikunov на комментарий #22) > Судя по тому, что в пакеты с ядрами не добавлена эта дира - про эту > договоренность никто не знает. Нет, все забыли. Особенно, кто не знал. Идея была vsu@alt много лет назад. Я поддержал. (Ответ для Sergey V Turchin на комментарий #23) > Драйвера для ATI до этого так и не добрались. Проприетарные, которые. Это 1-й кандидат. (In reply to Sergey V Turchin from comment #23) > (Ответ для Vitaly Chikunov на комментарий #21) > > 1. Как пакующему любые модули, хотелось бы понять, что такое > > '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно. > Да по аналогии, собственно. Драйвера для ATI до этого так и не добрались. > > > Из https://www.altlinux.org/Nvidia > Я там и не участвовал. Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами, если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно и для других кто не участвовал. > > Для ядра эта информация там не нужна. > Если я правильно понял, у ядра нет common-пакета, поэтому нужна для > остальных модулей. Я имел ввиду, что ядру эта информация не нужна, оно её никак не использует, для ядра эта дира с версиями, это дира с мусором. > > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не > > перекладывая на другие пакеты. > У нас не принято паковать один и тот же каталог в несколько пакетов. vseleznv утверждает, что так делать можно. Хотелось бы разобраться между "можно" и "не принято". Перенаправил ему этот вопрос. > > И пока эти "любые пакеты" это только одна nvidia. > Смысл от этого не меняется. Смысл, это то что я хочу узнать. (Ответ для Vitaly Chikunov на комментарий #26) > Смысл, это то что я хочу узнать. Смысл в том, чтобы common-каталоги паковать в базовые пакеты, как filesystem, например. (Ответ для Vitaly Chikunov на комментарий #26) > > Если я правильно понял, у ядра нет common-пакета, поэтому нужна для > > остальных модулей. > Я имел ввиду, что ядру эта информация не нужна, оно её никак не использует, > для ядра эта дира с версиями, это дира с мусором. Если бы оно не могло работать в файлами, в ней находящимися, то да. А так оно с ними работает, соответственно, каталог для них хорошо бы предоставить. (Ответ для Vitaly Chikunov на комментарий #26) > Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами, > если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно > и для других кто не участвовал. Симлинки на модули текущего ядра для возможности их переключения, т.к. патчить возможности нет по различным причинам включая проприетарность. (In reply to Sergey V Turchin from comment #27) > > Смысл, это то что я хочу узнать. > Смысл в том, чтобы common-каталоги паковать в базовые пакеты, как > filesystem, например. Я про смысл `.versions`. (In reply to Sergey V Turchin from comment #29) > (Ответ для Vitaly Chikunov на комментарий #26) > > Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами, > > если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно > > и для других кто не участвовал. > Симлинки на модули текущего ядра для возможности их переключения, т.к. > патчить возможности нет по различным причинам включая проприетарность. Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем? (Ответ для Vitaly Chikunov на комментарий #30) > Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем? Ой, да. В .versions лежат файлы с их версиями. Чтоб проще было версию модуля прочесть. У нас до сих пор нет библиотеки, которая это умеет прямо из файла модуля сделать. (In reply to Sergey V Turchin from comment #31) > (Ответ для Vitaly Chikunov на комментарий #30) > > Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем? > Ой, да. В .versions лежат файлы с их версиями. > Чтоб проще было версию модуля прочесть. У нас до сих пор нет библиотеки, > которая это умеет прямо из файла модуля сделать. Может хранить версии в другом месте, например в /lib/modules/nvidia/.versions? Хранение в /lib/modules/5.4.39-std-def-alt1/.versions/, конечно не ломает ядро, но к ядру отношения, всё же, не имеет. Пример опредеелняи версии без либ:
/tmp/.private/vt/rpmpeek.u1DmFjvJ# readlink ./lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko
../../nvidia/5.4.39-std-def-alt1-440.82
/tmp/.private/vt/rpmpeek.u1DmFjvJ# mod=$(readlink ./lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko)
/tmp/.private/vt/rpmpeek.u1DmFjvJ# echo ${mod##*-}
440.82
Еще вариант через modinfo # modinfo -F version /lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko 440.82 (Ответ для Vitaly Chikunov на комментарий #34) > Еще вариант через modinfo Потом в C-коде парсить? (Ответ для Vitaly Chikunov на комментарий #33) > readlink Имена файлов не зависят напрямую от версии. По сути совпадение. (Ответ для Vitaly Chikunov на комментарий #32) > /lib/modules/nvidia/.versions? Ещё раз повторяю. Это не nvidia. P.S. То, что туда никто ничего не кладёт, не делает каталог "nvidia". (Ответ для Vitaly Chikunov на комментарий #34) > Еще вариант через modinfo Да. Это вообще не вариант. depmod может быть ещё не сделан. В общем, не надо ломать работающее больше 10-и лет. Не захочет мантейнер ядра паковать, я упакую. (Ответ для Sergey V Turchin на комментарий #23) > > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, > > не перекладывая на другие пакеты. > У нас не принято паковать один и тот же каталог в несколько пакетов. Это не так; даже для каталогов с интересными правами (не 755 root:root), помнится, бывает. Важно то, чтобы _все_ такие пакеты обеспечивали идентичные права на один и тот же каталог. (Ответ для Michael Shigorin на комментарий #40) > Это не так; Разве что, уже не так. > даже для каталогов с интересными правами (не 755 root:root), > помнится, бывает. Важно то, чтобы _все_ такие пакеты обеспечивали > идентичные права на один и тот же каталог. Какой самый вопиющий пример в репозитории? (Ответ для Michael Shigorin на комментарий #40) > > У нас не принято паковать один и тот же каталог в несколько пакетов. > Это не так Что это означает? Теперь все тупо пакуют любые каталоги, за которые их сборочница не пошлёт? 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные пакеты без конфликтов при установке, если владелец, группа и режим каталога одинаковы, насколько я вообще помню. Уточни у glebfm@ или ldv@, если не веришь. (Ответ для Michael Shigorin на комментарий #43) > 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные > пакеты без конфликтов при установке Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали? (Ответ для Sergey V Turchin на комментарий #44) > > 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные > > пакеты без конфликтов при установке > Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали? Ага. Что для 755 root:root достаточно естественно и выходит :-) После удаления ядер в p10 остаются такие пустые папки: /lib/modules/5.10.118-std-def-alt1/net/wireless/realtek /lib/modules/5.10.121-std-def-alt1/net/wireless/realtek/rtlwifi /lib/modules/5.10.126-std-def-alt1/net/wireless/realtek /lib/modules/5.10.128-std-def-alt1/net/wireless/realtek/rtlwifi /lib/modules/5.10.136-std-def-alt1/net/wireless/realtek/rtlwifi Alexander Kovalev, видимо, это ошибка запаковки какого-то из модулей kernel-modules-rtl88x2bu-std-def kernel-modules-rtl8812au-std-def В их пакеты не запакованы промежуточные директории. на модуль. Наверное, тогда лучше на kernel-modules-rtl88x2bu-std-def. А сделать как у kernel-modules-rtl8821ce-std-def *** Bug 37165 has been marked as a duplicate of this bug. *** |
При удалении пакетов с ядрами в /lib/modules остаются хвосты. Их стоить тоже удалять. Логика может быть такой: MODDIR=/lib/modules INSTALLED=`rpm -qa | grep kernel-image | sed "s/.*-\([^-]\+\)-\([^-]\+\)-\([^-]\+\)-\([^-]\+\)$/\3-\1-\2-\4/"| xargs -I{} echo -n "{}\|"|sed "s/\\\\\|$//"` cd $MODDIR ls -d [0-9]* | grep -v "$INSTALLED" | xargs rm -rf