# uname -a Linux gw-sad156.kraft-s.net 5.10.82-std-def-alt1 #1 SMP Fri Dec 3 14:49:25 UTC 2021 x86_64 GNU/Linux Try to install new kernel kernel-image-std-def-2:5.10.145-alt1:p10+307268.100.1.1@1663953418 and update its modules [y]/n? update-kernel: kernel-modules-i40e is installed, trying to update... update-kernel: kernel-modules-ipset is installed, trying to update... update-kernel: kernel-modules-ipt_netflow is installed, trying to update... update-kernel: kernel-modules-ipt-ratelimit is installed, trying to update... update-kernel: kernel-modules-xtables-addons is installed, trying to update... При этом kernel-modules-i40e установлен только для ядра kernel-image-std-def-4.9.291-alt0.M80P.1, а все ядра, соответствующие p10, внешнего i40e не имеют.
1.4-alt3 делает так же: # update-kernel Running kernel: kernel-image-std-def-5.10.82-alt1 Checking for available std-def kernel packages... Latest kernel is kernel-image-std-def-5.10.145-alt1 ATTENTION: Selected kernel is 1 months old. Kernel std-def version 5.10.145-alt1 has 47 external modules. Use -i to select which modules to install. The following extra modules will be installed: (auto-selected) i40e ipset ipt-ratelimit ipt_netflow xtables-addons
Пожалуйста, обоснуйте почему это bug, а не feature - и не только для вас, а для всех пользователей.
(In reply to Sergey Y. Afonin from comment #0) > а все ядра, соответствующие p10, > внешнего i40e не имеют. 233092 Sep 23 20:22 /ALT/p10/files/x86_64/RPMS/kernel-modules-i40e-std-def-2.18.9-alt1.330385.1.x86_64.rpm 231242 Oct 15 12:49 /ALT/p10/files/x86_64/RPMS/kernel-modules-i40e-un-def-2.18.9-alt1.331594.1.x86_64.rpm По-моему, это означает что все ядра в p10 имеют внешний модуль i40e.
(In reply to Vitaly Chikunov from comment #3) > > а все ядра, соответствующие p10, внешнего i40e не имеют. > > По-моему, это означает что все ядра в p10 имеют внешний модуль i40e. Я имел ввиду в установленной системе, а не в репозитории.
(In reply to Vitaly Chikunov from comment #2) > Пожалуйста, обоснуйте почему это bug, а не feature - и не только для вас, а > для всех пользователей. Может я, конечно, ошибаюсь, но я, до этого момента, полагал, что задача update-kernel - это обновить текущее ядро максимально точно. В данном примере система работает с модулем из ядра, а использование update-kernel приводит к тому, что новое ядро, внезапно, начинает работать с внешним модулем. Это явно незапланированное изменене поведения. Что касается конкретно i40e, то не знаю, как оно с 2.18.9, но модуль версии 2.17.4 мне не понравился: https://lists.altlinux.org/pipermail/devel-kernel/2021-December/007387.html Потому я не хотел бы внезапного появления внешнего модуля i40e и считаю такое поведение ошибкой. Не надо собирать список всех установленных модулей, надо брать только список для работающего ядра.
Как я уже понял, представления о том что должен и не должен делать update-kernel у всех разное. Видимо, должно быть поведение по умолчанию максимально безлопастное и гибкое для всех пользователей. У людей разное представление о том что такое "последнее ядро", "новое ядро", "рабочее ядро". Поэтому важно осторожно подходить к изменению поведения по умолчанию в устоявшей утилите к которой привыкли. Дополнительное поведение можно сделать опциями. Поставленный модуль можно удалить (он есть в списке перед установкой и видно как он ставится), а вот молча не приехавший модуль, который может был нужен надо вспомнить, что нужно поставить. Сейчас есть опция -A modulename add external module (by a short name) возможно стоит добавить парную ей -D modulename -- модуль который не будет ставится? Так же, после удаления старого ядра с i40e этот модуль не должен предлагаться к установке. update-kernel не может знать какой модуль в каком ядре не понравился пользователю, а в каком понравился. Поэтому предлагаются все модули из этого флейвора которые есть в системе.
(In reply to Vitaly Chikunov from comment #6) > Так же, после удаления старого ядра с i40e этот модуль не должен > предлагаться к установке. update-kernel не может знать какой модуль в каком > ядре не понравился пользователю, а в каком понравился. Поэтому предлагаются > все модули из этого флейвора которые есть в системе. Всё же эта логика выглядит не очень правильной. Мало ли, зачем установлено какое-то ядро, которое имеет всякие разные модули? > а вот молча не приехавший модуль, который может был нужен надо вспомнить, > что нужно поставить. Если модуль нужен, как работающее ядро может его не иметь? :-) Оно может его не иметь только в одном случае: если что-то пошло не так, а тогда решение одно: откат до старого работающего ядра. Вероятность, что кто-то будет заниматься какой-то установкой на неработающей системе мне кажется совсем маленькой. А в рассматриваемом примере приехавший незапланированный модуль не сильно лучше того, чем если бы какой-то модуль не доехал.
> Мало ли, зачем установлено какое-то ядро, которое имеет всякие разные модули? Именно. > Если модуль нужен, как работающее ядро может его не иметь? Потому что пользователь может апдейтиться из другого ядра и даже другого флейвора (осознав, после загрузки в него, что оно ему не подходит, например), у которого другой набор модулей, где, например, внешний модель уже не нужен. Боюсь что все это не решаемые задачи даже для сильного ИИ -- не маленькому врапперу вокруг apt-get install решать что на самом деле хочет пользователь, зачем он что-то делает, что ему нравится, что нет. Поэтому единственный вариант с хорошим UI/UX сделать понятную и простую утилиту. Но у которой есть возможности, чтоб скорректировать поведение по умолчанию для продвинутого пользователя. К сожалению сильный ИИ в update-kernel мы реализовать вряд ли сможем, а все намерения пользователя и его желания и предпочтения, его систему ценностей мы знать не можем, а у разных людей они будут противоречить друг другу. Не ставить модуль можно только если пользователь обозначил своё желание, например, удалив его, но мы не знаем, что он вручную удалял этот модуль (нет API для этого, да если бы знали, что удалял, то не знаем почему - может просто эксперимент - загрузился в ядро без него и понял что не подошло и делает апдейт). Для всего остального работает логика по умолчанию (AFAIK много лет).
(In reply to Vitaly Chikunov from comment #8) > Не ставить модуль можно только если пользователь обозначил своё желание, Нет, я при всём желании не понимаю логику, когда ставятся все найденные в системе модули без разбора, а не только те, которые есть у работающего сейчас ядра.
(In reply to Sergey Y. Afonin from comment #9) > (In reply to Vitaly Chikunov from comment #8) > > > Не ставить модуль можно только если пользователь обозначил своё желание, > > Нет, я при всём желании не понимаю логику, когда ставятся все найденные в > системе модули без разбора, а не только те, которые есть у работающего > сейчас ядра. Ставятся не все модули без разбора, а только те которые уже были в системе, то есть пользователь их как минимум поставил. Человек может ставить новое ядро из любого старого загруженного ядра любого флейвора, с любым набором модулей в этом работающем ядре. Угадать желания пользователя — невозможно. А требовать у программы угадывания желаний не реализуемо.
Можно реализовать алгоритм, но нельзя реализовать - я не хотел этот модуль, а он приехал. Конечно вы можете объяснить почему вы не хотели этот модуль. Но другой пользователь точно так же, по веским причинам, будет его хотеть. Прога не может знать ваши намерения, это просто невозможно.
Максимум можно сделать так: 1. если пользователь загружен в том же флейворе -- то предлагаются только модули загруженного сейчас ядра. Но есть вероятность что пользователь загрузил "старое" ядро. 2. если пользователь загрузил другой флейвор -- то предлагаются модули из нужного (из -t) флейвора - из самой старшей версии установленного ядра. Вариант замены "из самой старшей версии" на "последнее установленное". Велика вероятность, это этот выбор будет совпадать так что можно пользоваться любым списком. 3. если пользователь загрузил любой флейвор -- далее как п.2. То есть загруженность ядра не учитывается.
(In reply to Vitaly Chikunov from comment #11) > Можно реализовать алгоритм, но нельзя реализовать - я не хотел этот модуль, > а он приехал. Конечно вы можете объяснить почему вы не хотели этот модуль. > Но другой пользователь точно так же, по веским причинам, будет его хотеть. > Прога не может знать ваши намерения, это просто невозможно. Зачем поользователь будет хотеть модуль для неработающего ядра? Вот как раз не надо угадывать хотелки. Захочет - доустановит. Есть работающее ядро - его и надо обновлять с максимальной точностью.
(In reply to Sergey Y. Afonin from comment #13) > Зачем поользователь будет хотеть модуль для неработающего ядра? Вот как раз > не надо угадывать хотелки. Захочет - доустановит. Есть работающее ядро - его > и надо обновлять с максимальной точностью. И с другим флавором тоже смотреть на рабочее. Просто ввиду того, что при удалённой работе мало ли что может случиться из-за чего-то дополнительно установленного.
Может быть не мудрить и прямо перечислить модули ядра, которые надо обновлять при update-kernel для каждого типа ? Что-то вроде опционального конфигурационного файла, которым можно поменять текущее поведение.
(In reply to Anton Farygin from comment #15) > Может быть не мудрить и прямо перечислить модули ядра, которые надо > обновлять при update-kernel для каждого типа ? > > Что-то вроде опционального конфигурационного файла, которым можно поменять > текущее поведение. Это было бы не плохо, но, наверное, в качестве необязательного дополнения. И предусмотреть в синтаксисе варианты "обязательно установить" и "обязательно не установить". То есть, видится три варианта, третий как сейчас, как я понимаю "хорошо бы, но не важно".
update-kernel-1.6-alt1 -> sisyphus: Tue Apr 25 2023 Vitaly Chikunov <vt@altlinux> 1.6-alt1 - update-kernel: Check existence of DKMS tool, not just the DKMS package. - update-kernel: Support -D option to exclude modules from install (ALT#44158). - update-kernel: Hint remove-old-kernels in help message. - remove-old-kernels: Do not list 'keeping' kernels if there's none. - Rename analyze-kmodules to analyze-kmodules-experimental.
