38434 2020-05-04 13:11:05 +0300 Удалять остатки старых ядер в remove-old-kernels 2023-03-31 17:05:30 +0300 1 1 4 Development Sisyphus kernel-modules-rtl88x2bu-std-def unstable x86 Linux REOPENED P5 enhancement --- 1 asy cas alexvk72 boyarsh cas evg glebfm kernelbot lav ldv mike rider sbolshakov serega2005 shrek sin vitty vsu vt zerg qa-sisyphus oldest_to_newest 189686 0 asy 2020-05-04 13:11:05 +0300 При удалении пакетов с ядрами в /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 189687 1 asy 2020-05-04 13:31:20 +0300 (In reply to Sergey Y. Afonin from comment #0) > Логика может быть такой: Хотя нет, логика поиска набора исключений должна быть сложнее. Есть kernel-image-domU-std-def, а в p9, смотрю, появились kernel-image-rt, kernel-image-lts и т.п. 189691 2 vt 2020-05-04 15:18:33 +0300 Что за хвосты? 189697 3 asy 2020-05-04 18:38:08 +0300 (In reply to Vitaly Chikunov from comment #2) > Что за хвосты? Почему-то неопакеченные файлы в /lib/modules/`uname -r` от каждого ядра, которое когда-то было установлено. Хотя, может быть, это стоит повесить на сами ядра. 189705 4 vt 2020-05-05 03:10:21 +0300 Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться. 189706 5 vt 2020-05-05 03:49:16 +0300 Посчитал сам. $ 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 189710 6 asy 2020-05-05 13:01:47 +0300 (In reply to Vitaly Chikunov from comment #5) > Посчитал сам. Это не всё. Ещё там остаются /lib/modules/`uname -r`/modules.* 189711 7 asy 2020-05-05 13:17:36 +0300 (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 у меня какое-то дежавю, что я, вроде бы, про это где-то писал. Но баг что-то не вижу. 189729 8 zerg 2020-05-06 12:36:35 +0300 (Ответ для 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 . 189755 9 vt 2020-05-06 21:54:47 +0300 > Каталог .versions должен принадлежать kernel-image . Скажите пожалуйста, почему каталог .versions должен принадлежать пакету kernel-image? 189758 10 zerg 2020-05-07 10:19:40 +0300 (Ответ для Vitaly Chikunov на комментарий #9) > Скажите пожалуйста, почему каталог .versions должен принадлежать пакету > kernel-image? Потому, что в этом каталоге могут лежать файлы любых других пакетов с модулями к этому ядру. 189760 11 asy 2020-05-07 13:04:56 +0300 (In reply to Sergey V Turchin from comment #10) > Потому, что в этом каталоге могут лежать файлы любых других пакетов с > модулями к этому ядру. а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с ядром не принадлежит. 189761 12 asy 2020-05-07 13:06:22 +0300 (In reply to Vitaly Chikunov from comment #4) > Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться. Проще чистить в remove-old-kernels :-) 189762 13 zerg 2020-05-07 13:34:22 +0300 (Ответ для Sergey Y. Afonin на комментарий #11) > > Потому, что в этом каталоге могут лежать файлы любых других пакетов с > > модулями к этому ядру. > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с > ядром не принадлежит. Причём здесь .versions? 189763 14 zerg 2020-05-07 13:36:56 +0300 (Ответ для Sergey Y. Afonin на комментарий #11) > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с > ядром не принадлежит. Если не ошибка, то его тоже надо добавить в ядро. 189764 15 asy 2020-05-07 13:38:35 +0300 (In reply to Sergey V Turchin from comment #13) > > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с > > ядром не принадлежит. > Причём здесь .versions? Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не разьираться. 189765 16 zerg 2020-05-07 13:50:39 +0300 (Ответ для Sergey Y. Afonin на комментарий #15) > Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не > разьираться. Зачем городить лишние костыли? 189766 17 asy 2020-05-07 13:55:49 +0300 (In reply to Sergey V Turchin from comment #16) > Зачем городить лишние костыли? С одной стороны согласен, но remove-old-kernels - это одно место, а мантейнеров всех ядер и модулей собрать можно только посредством сизифусчеки и непропуском пакетов в репозиторий. Хотя это тоже одно место. 189767 18 zerg 2020-05-07 14:03:35 +0300 У нас со всех сторон добавлением и удалением файлов управляет пакетный менеджер. Всё остальное -- костыли. 189771 19 vt 2020-05-07 15:55:26 +0300 (In reply to Sergey V Turchin from comment #10) > (Ответ для Vitaly Chikunov на комментарий #9) > > Скажите пожалуйста, почему каталог .versions должен принадлежать пакету > > kernel-image? > Потому, что в этом каталоге могут лежать файлы любых других пакетов с > модулями к этому ядру. Если это стандартная директория, то где она стандартизована? Если не секрет. В коде ядра нет ссылок на ".versions". Если не найдется стандарт, то запаковывать её должны модули, которые её используют. Иначе любой модуль напридумает себе директорий, а ядро должно их упаковывать? Я согласен с тем, что remove-old-kernels не должен ничего лишнего удалять так как у пользователя могут быть свои, вручную собранные, модули - и он их удалит? 189772 20 zerg 2020-05-07 16:12:02 +0300 (Ответ для Vitaly Chikunov на комментарий #19) > Если это стандартная директория, то где она стандартизована? Если не секрет. А никто не говорил что это стандарт. Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей. > так как у пользователя могут быть свои, вручную собранные, модули - и он их > удалит? С этим я согласен. Было бы неплохо, чтоб подчищал, но чужого(пакетного) не трогал. 189773 21 vt 2020-05-07 16:56:30 +0300 > А никто не говорил что это стандарт. Стандарт, видимо, слишком сильное слово, имелось ввиду договоренность, упоминание в документации, в коде, общепринятая практика. > Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей. Где про это почитать? 1. Как пакующему любые модули, хотелось бы понять, что такое '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно. Из https://www.altlinux.org/Nvidia назначение .versions (кроме того что там версия) не понятно. Для ядра эта информация там не нужна. 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не перекладывая на другие пакеты. И пока эти "любые пакеты" это только одна nvidia. Пользователь у этой диры только один. 189776 22 vt 2020-05-07 17:02:45 +0300 > Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей. Судя по тому, что в пакеты с ядрами не добавлена эта дира - про эту договоренность никто не знает. 189777 23 zerg 2020-05-07 17:16:28 +0300 (Ответ для Vitaly Chikunov на комментарий #21) > 1. Как пакующему любые модули, хотелось бы понять, что такое > '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно. Да по аналогии, собственно. Драйвера для ATI до этого так и не добрались. > Из https://www.altlinux.org/Nvidia Я там и не участвовал. > Для ядра эта информация там не нужна. Если я правильно понял, у ядра нет common-пакета, поэтому нужна для остальных модулей. > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не > перекладывая на другие пакеты. У нас не принято паковать один и тот же каталог в несколько пакетов. > И пока эти "любые пакеты" это только одна nvidia. Смысл от этого не меняется. > Пользователь у этой диры только один. Нет. Их прямо сейчас может стать 3, но из-за различных недостатков приходится паковать в один. 189778 24 zerg 2020-05-07 17:18:00 +0300 (Ответ для Vitaly Chikunov на комментарий #22) > Судя по тому, что в пакеты с ядрами не добавлена эта дира - про эту > договоренность никто не знает. Нет, все забыли. Особенно, кто не знал. Идея была vsu@alt много лет назад. Я поддержал. 189779 25 zerg 2020-05-07 17:20:31 +0300 (Ответ для Sergey V Turchin на комментарий #23) > Драйвера для ATI до этого так и не добрались. Проприетарные, которые. Это 1-й кандидат. 189780 26 vt 2020-05-07 17:32:19 +0300 (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. > Смысл от этого не меняется. Смысл, это то что я хочу узнать. 189781 27 zerg 2020-05-07 17:46:55 +0300 (Ответ для Vitaly Chikunov на комментарий #26) > Смысл, это то что я хочу узнать. Смысл в том, чтобы common-каталоги паковать в базовые пакеты, как filesystem, например. 189782 28 zerg 2020-05-07 17:49:15 +0300 (Ответ для Vitaly Chikunov на комментарий #26) > > Если я правильно понял, у ядра нет common-пакета, поэтому нужна для > > остальных модулей. > Я имел ввиду, что ядру эта информация не нужна, оно её никак не использует, > для ядра эта дира с версиями, это дира с мусором. Если бы оно не могло работать в файлами, в ней находящимися, то да. А так оно с ними работает, соответственно, каталог для них хорошо бы предоставить. 189783 29 zerg 2020-05-07 17:52:50 +0300 (Ответ для Vitaly Chikunov на комментарий #26) > Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами, > если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно > и для других кто не участвовал. Симлинки на модули текущего ядра для возможности их переключения, т.к. патчить возможности нет по различным причинам включая проприетарность. 189789 30 vt 2020-05-07 21:29:54 +0300 (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/` зачем? 189790 31 zerg 2020-05-07 21:43:48 +0300 (Ответ для Vitaly Chikunov на комментарий #30) > Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем? Ой, да. В .versions лежат файлы с их версиями. Чтоб проще было версию модуля прочесть. У нас до сих пор нет библиотеки, которая это умеет прямо из файла модуля сделать. 189791 32 vt 2020-05-07 21:57:24 +0300 (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/, конечно не ломает ядро, но к ядру отношения, всё же, не имеет. 189792 33 vt 2020-05-07 22:04:38 +0300 Пример опредеелняи версии без либ: /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 189793 34 vt 2020-05-07 22:09:13 +0300 Еще вариант через modinfo # modinfo -F version /lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko 440.82 189794 35 zerg 2020-05-07 22:20:32 +0300 (Ответ для Vitaly Chikunov на комментарий #34) > Еще вариант через modinfo Потом в C-коде парсить? 189795 36 zerg 2020-05-07 22:21:53 +0300 (Ответ для Vitaly Chikunov на комментарий #33) > readlink Имена файлов не зависят напрямую от версии. По сути совпадение. 189796 37 zerg 2020-05-07 22:23:42 +0300 (Ответ для Vitaly Chikunov на комментарий #32) > /lib/modules/nvidia/.versions? Ещё раз повторяю. Это не nvidia. P.S. То, что туда никто ничего не кладёт, не делает каталог "nvidia". 189797 38 zerg 2020-05-07 22:24:48 +0300 (Ответ для Vitaly Chikunov на комментарий #34) > Еще вариант через modinfo Да. Это вообще не вариант. depmod может быть ещё не сделан. 189798 39 zerg 2020-05-07 22:27:07 +0300 В общем, не надо ломать работающее больше 10-и лет. Не захочет мантейнер ядра паковать, я упакую. 189804 40 mike 2020-05-07 23:44:03 +0300 (Ответ для Sergey V Turchin на комментарий #23) > > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, > > не перекладывая на другие пакеты. > У нас не принято паковать один и тот же каталог в несколько пакетов. Это не так; даже для каталогов с интересными правами (не 755 root:root), помнится, бывает. Важно то, чтобы _все_ такие пакеты обеспечивали идентичные права на один и тот же каталог. 189806 41 zerg 2020-05-08 09:23:53 +0300 (Ответ для Michael Shigorin на комментарий #40) > Это не так; Разве что, уже не так. > даже для каталогов с интересными правами (не 755 root:root), > помнится, бывает. Важно то, чтобы _все_ такие пакеты обеспечивали > идентичные права на один и тот же каталог. Какой самый вопиющий пример в репозитории? 189807 42 zerg 2020-05-08 09:36:40 +0300 (Ответ для Michael Shigorin на комментарий #40) > > У нас не принято паковать один и тот же каталог в несколько пакетов. > Это не так Что это означает? Теперь все тупо пакуют любые каталоги, за которые их сборочница не пошлёт? 189833 43 mike 2020-05-08 20:47:42 +0300 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные пакеты без конфликтов при установке, если владелец, группа и режим каталога одинаковы, насколько я вообще помню. Уточни у glebfm@ или ldv@, если не веришь. 189841 44 zerg 2020-05-09 14:38:03 +0300 (Ответ для Michael Shigorin на комментарий #43) > 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные > пакеты без конфликтов при установке Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали? 189843 45 mike 2020-05-09 15:25:43 +0300 (Ответ для Sergey V Turchin на комментарий #44) > > 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные > > пакеты без конфликтов при установке > Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали? Ага. Что для 755 root:root достаточно естественно и выходит :-) 213996 46 alexvk72 2022-08-24 19:43:13 +0300 После удаления ядер в 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 214012 47 vt 2022-08-25 03:08:53 +0300 Alexander Kovalev, видимо, это ошибка запаковки какого-то из модулей kernel-modules-rtl88x2bu-std-def kernel-modules-rtl8812au-std-def В их пакеты не запакованы промежуточные директории. 214013 48 rider 2022-08-25 08:23:57 +0300 на модуль. 214046 49 vt 2022-08-25 18:33:39 +0300 Наверное, тогда лучше на kernel-modules-rtl88x2bu-std-def. А сделать как у kernel-modules-rtl8821ce-std-def 223745 50 amakeenk 2023-03-31 17:05:30 +0300 *** Bug 37165 has been marked as a duplicate of this bug. ***