Bug 38434 - Удалять остатки старых ядер в remove-old-kernels
Summary: Удалять остатки старых ядер в remove-old-kernels
Status: REOPENED
Alias: None
Product: Sisyphus
Classification: Development
Component: kernel-modules-rtl88x2bu-std-def (show other bugs)
Version: unstable
Hardware: x86 Linux
: P5 enhancement
Assignee: Andrey Cherepanov
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-04 13:11 MSK by Sergey Y. Afonin
Modified: 2022-08-25 18:33 MSK (History)
17 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Y. Afonin 2020-05-04 13:11:05 MSK
При удалении пакетов с ядрами в /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
Comment 1 Sergey Y. Afonin 2020-05-04 13:31:20 MSK
(In reply to Sergey Y. Afonin from comment #0)

> Логика может быть такой:

Хотя нет, логика поиска набора исключений должна быть сложнее. Есть kernel-image-domU-std-def, а в p9, смотрю, появились kernel-image-rt, kernel-image-lts и т.п.
Comment 2 Vitaly Chikunov 2020-05-04 15:18:33 MSK
Что за хвосты?
Comment 3 Sergey Y. Afonin 2020-05-04 18:38:08 MSK
(In reply to Vitaly Chikunov from comment #2)

> Что за хвосты?

Почему-то неопакеченные файлы в /lib/modules/`uname -r` от каждого ядра, которое когда-то было установлено. Хотя, может быть, это стоит повесить на сами ядра.
Comment 4 Vitaly Chikunov 2020-05-05 03:10:21 MSK
Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться.
Comment 5 Vitaly Chikunov 2020-05-05 03:49:16 MSK
Посчитал сам.

$ 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
Comment 6 Sergey Y. Afonin 2020-05-05 13:01:47 MSK
(In reply to Vitaly Chikunov from comment #5)

> Посчитал сам.

Это не всё. Ещё там остаются /lib/modules/`uname -r`/modules.*
Comment 7 Sergey Y. Afonin 2020-05-05 13:17:36 MSK
(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 у меня какое-то дежавю, что я, вроде бы, про это где-то писал. Но баг что-то не вижу.
Comment 8 Sergey V Turchin 2020-05-06 12:36:35 MSK
(Ответ для 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 .
Comment 9 Vitaly Chikunov 2020-05-06 21:54:47 MSK
> Каталог .versions должен принадлежать kernel-image .

Скажите пожалуйста, почему каталог .versions должен принадлежать пакету kernel-image?
Comment 10 Sergey V Turchin 2020-05-07 10:19:40 MSK
(Ответ для Vitaly Chikunov на комментарий #9)
> Скажите пожалуйста, почему каталог .versions должен принадлежать пакету
> kernel-image?
Потому, что в этом каталоге могут лежать файлы любых других пакетов с модулями к этому ядру.
Comment 11 Sergey Y. Afonin 2020-05-07 13:04:56 MSK
(In reply to Sergey V Turchin from comment #10)

> Потому, что в этом каталоге могут лежать файлы любых других пакетов с
> модулями к этому ядру.

а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с ядром не принадлежит.
Comment 12 Sergey Y. Afonin 2020-05-07 13:06:22 MSK
(In reply to Vitaly Chikunov from comment #4)

> Ответ на вопрос какие файлы автоматом даст ответ к кому обращаться.

Проще чистить в remove-old-kernels :-)
Comment 13 Sergey V Turchin 2020-05-07 13:34:22 MSK
(Ответ для Sergey Y. Afonin на комментарий #11)
> > Потому, что в этом каталоге могут лежать файлы любых других пакетов с
> > модулями к этому ядру.
> а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с
> ядром не принадлежит.
Причём здесь .versions?
Comment 14 Sergey V Turchin 2020-05-07 13:36:56 MSK
(Ответ для Sergey Y. Afonin на комментарий #11)
> а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с
> ядром не принадлежит.
Если не ошибка, то его тоже надо добавить в ядро.
Comment 15 Sergey Y. Afonin 2020-05-07 13:38:35 MSK
(In reply to Sergey V Turchin from comment #13)

> > а то, что e1000e использует misc, это ошибка? Впрочем, он тоже пакету с
> > ядром не принадлежит.

> Причём здесь .versions?

Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не разьираться.
Comment 16 Sergey V Turchin 2020-05-07 13:50:39 MSK
(Ответ для Sergey Y. Afonin на комментарий #15)
> Я, вообще-то, сразу с remove-old-kernels начал, чтобы с ядрами и модулями не
> разьираться.
Зачем городить лишние костыли?
Comment 17 Sergey Y. Afonin 2020-05-07 13:55:49 MSK
(In reply to Sergey V Turchin from comment #16)

> Зачем городить лишние костыли?

С одной стороны согласен, но remove-old-kernels - это одно место, а мантейнеров всех ядер и модулей собрать можно только посредством сизифусчеки и непропуском пакетов в репозиторий. Хотя это тоже одно место.
Comment 18 Sergey V Turchin 2020-05-07 14:03:35 MSK
У нас со всех сторон добавлением и удалением файлов управляет пакетный менеджер.
Всё остальное -- костыли.
Comment 19 Vitaly Chikunov 2020-05-07 15:55:26 MSK
(In reply to Sergey V Turchin from comment #10)
> (Ответ для Vitaly Chikunov на комментарий #9)
> > Скажите пожалуйста, почему каталог .versions должен принадлежать пакету
> > kernel-image?
> Потому, что в этом каталоге могут лежать файлы любых других пакетов с
> модулями к этому ядру.

Если это стандартная директория, то где она стандартизована? Если не секрет. В коде ядра нет ссылок на ".versions". Если не найдется стандарт, то запаковывать её должны модули, которые её используют. Иначе любой модуль напридумает себе директорий, а ядро должно их упаковывать?

Я согласен с тем, что remove-old-kernels не должен ничего лишнего удалять так как у пользователя могут быть свои, вручную собранные, модули - и он их удалит?
Comment 20 Sergey V Turchin 2020-05-07 16:12:02 MSK
(Ответ для Vitaly Chikunov на комментарий #19)
> Если это стандартная директория, то где она стандартизована? Если не секрет.
А никто не говорил что это стандарт. Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей.

> так как у пользователя могут быть свои, вручную собранные, модули - и он их
> удалит?
С этим я согласен. Было бы неплохо, чтоб подчищал, но чужого(пакетного) не трогал.
Comment 21 Vitaly Chikunov 2020-05-07 16:56:30 MSK
> А никто не говорил что это стандарт.

Стандарт, видимо, слишком сильное слово, имелось ввиду договоренность, упоминание в документации, в коде, общепринятая практика.

> Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей.

Где про это почитать?

1. Как пакующему любые модули, хотелось бы понять, что такое '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно.

Из https://www.altlinux.org/Nvidia назначение .versions (кроме того что там версия) не понятно. Для ядра эта информация там не нужна.

2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не перекладывая на другие пакеты. И пока эти "любые пакеты" это только одна nvidia. Пользователь у этой диры только один.
Comment 22 Vitaly Chikunov 2020-05-07 17:02:45 MSK
> Это было придумано в рамках извращений с nvidia, но задумана как общая директория для _любых_ модулей.

Судя по тому, что в пакеты с ядрами не добавлена эта дира - про эту договоренность никто не знает.
Comment 23 Sergey V Turchin 2020-05-07 17:16:28 MSK
(Ответ для Vitaly Chikunov на комментарий #21)
> 1. Как пакующему любые модули, хотелось бы понять, что такое
> '/lib/modules/*/.versions/'. Вдруг это мне тоже нужно.
Да по аналогии, собственно. Драйвера для ATI до этого так и не добрались.

> Из https://www.altlinux.org/Nvidia
Я там и не участвовал.

> Для ядра эта информация там не нужна.
Если я правильно понял, у ядра нет common-пакета, поэтому нужна для остальных модулей.

> 2. В любом случае, "любые модули" могли бы паковать эту диру тоже, не
> перекладывая на другие пакеты.
У нас не принято паковать один и тот же каталог в несколько пакетов.

> И пока эти "любые пакеты" это только одна nvidia.
Смысл от этого не меняется.

> Пользователь у этой диры только один.
Нет. Их прямо сейчас может стать 3, но из-за различных недостатков приходится паковать в один.
Comment 24 Sergey V Turchin 2020-05-07 17:18:00 MSK
(Ответ для Vitaly Chikunov на комментарий #22)
> Судя по тому, что в пакеты с ядрами не добавлена эта дира - про эту
> договоренность никто не знает.
Нет, все забыли. Особенно, кто не знал.
Идея была vsu@alt много лет назад. Я поддержал.
Comment 25 Sergey V Turchin 2020-05-07 17:20:31 MSK
(Ответ для Sergey V Turchin на комментарий #23)
> Драйвера для ATI до этого так и не добрались.
Проприетарные, которые. Это 1-й кандидат.
Comment 26 Vitaly Chikunov 2020-05-07 17:32:19 MSK
(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.
> Смысл от этого не меняется.

Смысл, это то что я хочу узнать.
Comment 27 Sergey V Turchin 2020-05-07 17:46:55 MSK
(Ответ для Vitaly Chikunov на комментарий #26)
> Смысл, это то что я хочу узнать.
Смысл в том, чтобы common-каталоги паковать в базовые пакеты, как filesystem, например.
Comment 28 Sergey V Turchin 2020-05-07 17:49:15 MSK
(Ответ для Vitaly Chikunov на комментарий #26)
> > Если я правильно понял, у ядра нет common-пакета, поэтому нужна для
> > остальных модулей.
> Я имел ввиду, что ядру эта информация не нужна, оно её никак не использует,
> для ядра эта дира с версиями, это дира с мусором.
Если бы оно не могло работать в файлами, в ней находящимися, то да. А так оно с ними работает, соответственно, каталог для них хорошо бы предоставить.
Comment 29 Sergey V Turchin 2020-05-07 17:52:50 MSK
(Ответ для Vitaly Chikunov на комментарий #26)
> Раз это нигде не документировано, тогда, пожалуйста, опишите своими словами,
> если не трудно -- в чем цель хранить там версию. Возможно, это будет полезно
> и для других кто не участвовал.
Симлинки на модули текущего ядра для возможности их переключения, т.к. патчить возможности нет по различным причинам включая проприетарность.
Comment 30 Vitaly Chikunov 2020-05-07 21:29:54 MSK
(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/` зачем?
Comment 31 Sergey V Turchin 2020-05-07 21:43:48 MSK
(Ответ для Vitaly Chikunov на комментарий #30)
> Симлинки на модули лежат в `/lib/modules/*/nVidia/`, а `.versions/` зачем?
Ой, да. В .versions лежат файлы с их версиями.
Чтоб проще было версию модуля прочесть. У нас до сих пор нет библиотеки, которая это умеет прямо из файла модуля сделать.
Comment 32 Vitaly Chikunov 2020-05-07 21:57:24 MSK
(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/, конечно не ломает ядро, но к ядру отношения, всё же, не имеет.
Comment 33 Vitaly Chikunov 2020-05-07 22:04:38 MSK
Пример опредеелняи версии без либ:

/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
Comment 34 Vitaly Chikunov 2020-05-07 22:09:13 MSK
Еще вариант через modinfo

# modinfo -F version /lib/modules/5.4.39-std-def-alt1/nVidia/nvidia.ko
440.82
Comment 35 Sergey V Turchin 2020-05-07 22:20:32 MSK
(Ответ для Vitaly Chikunov на комментарий #34)
> Еще вариант через modinfo
Потом в C-коде парсить?
Comment 36 Sergey V Turchin 2020-05-07 22:21:53 MSK
(Ответ для Vitaly Chikunov на комментарий #33)
> readlink
Имена файлов не зависят напрямую от версии. По сути совпадение.
Comment 37 Sergey V Turchin 2020-05-07 22:23:42 MSK
(Ответ для Vitaly Chikunov на комментарий #32)
> /lib/modules/nvidia/.versions?
Ещё раз повторяю. Это не nvidia.

P.S.
То, что туда никто ничего не кладёт, не делает каталог "nvidia".
Comment 38 Sergey V Turchin 2020-05-07 22:24:48 MSK
(Ответ для Vitaly Chikunov на комментарий #34)
> Еще вариант через modinfo
Да. Это вообще не вариант. depmod может быть ещё не сделан.
Comment 39 Sergey V Turchin 2020-05-07 22:27:07 MSK
В общем, не надо ломать работающее больше 10-и лет.
Не захочет мантейнер ядра паковать, я упакую.
Comment 40 Michael Shigorin 2020-05-07 23:44:03 MSK
(Ответ для Sergey V Turchin на комментарий #23)
> > 2. В любом случае, "любые модули" могли бы паковать эту диру тоже,
> > не перекладывая на другие пакеты.
> У нас не принято паковать один и тот же каталог в несколько пакетов.
Это не так; даже для каталогов с интересными правами (не 755 root:root),
помнится, бывает.  Важно то, чтобы _все_ такие пакеты обеспечивали идентичные права на один и тот же каталог.
Comment 41 Sergey V Turchin 2020-05-08 09:23:53 MSK
(Ответ для Michael Shigorin на комментарий #40)
> Это не так;
Разве что, уже не так.

> даже для каталогов с интересными правами (не 755 root:root),
> помнится, бывает.  Важно то, чтобы _все_ такие пакеты обеспечивали
> идентичные права на один и тот же каталог.
Какой самый вопиющий пример в репозитории?
Comment 42 Sergey V Turchin 2020-05-08 09:36:40 MSK
(Ответ для Michael Shigorin на комментарий #40)
> > У нас не принято паковать один и тот же каталог в несколько пакетов.
> Это не так
Что это означает? Теперь все тупо пакуют любые каталоги, за которые их сборочница не пошлёт?
Comment 43 Michael Shigorin 2020-05-08 20:47:42 MSK
2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные пакеты без конфликтов при установке, если владелец, группа и режим каталога одинаковы, насколько я вообще помню.  Уточни у glebfm@ или ldv@, если не веришь.
Comment 44 Sergey V Turchin 2020-05-09 14:38:03 MSK
(Ответ для Michael Shigorin на комментарий #43)
> 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные
> пакеты без конфликтов при установке
Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали?
Comment 45 Michael Shigorin 2020-05-09 15:25:43 MSK
(Ответ для Sergey V Turchin на комментарий #44)
> > 2 zerg@: у нас всегда было можно паковать одинаковые каталоги в разные
> > пакеты без конфликтов при установке
> Т.е. по барабану, в какой пакет упакован каталог, лишь бы права совпадали?
Ага.  Что для 755 root:root достаточно естественно и выходит :-)
Comment 46 Alexander Kovalev 2022-08-24 19:43:13 MSK
После удаления ядер в 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
Comment 47 Vitaly Chikunov 2022-08-25 03:08:53 MSK
Alexander Kovalev, видимо, это ошибка запаковки какого-то из модулей

  kernel-modules-rtl88x2bu-std-def
  kernel-modules-rtl8812au-std-def

В их пакеты не запакованы промежуточные директории.
Comment 48 Anton Farygin 2022-08-25 08:23:57 MSK
на модуль.
Comment 49 Vitaly Chikunov 2022-08-25 18:33:39 MSK
Наверное, тогда лучше на kernel-modules-rtl88x2bu-std-def.
А сделать как у kernel-modules-rtl8821ce-std-def