Обновление с un-def предлагает ядро 6.11 вместо 6.6. # update-kernel Running kernel: kernel-image-un-def-6.6.58-alt1 Checking for available un-def kernel packages... There are no available kernels with flavour un-def Searching for a newer flavour (>= 6.6.58-un-def-alt1)... Upgrade to the next available flavour 6.11 Checking for available 6.11 kernel packages... Latest available kernel is kernel-image-6.11-6.11.6-alt1 Kernel 6.11 version 6.11.6-alt1 has 9 external modules. Use -i to select which modules to install. ATTENTION: Selected kernel does not have 6 following external module(s) which you have installed for your currently booted un-def kernel: r8125 rtl8192eu rtl8812au rtl8821cu rtl88x2bu rtw89 Do not answer yes if these modules are important for your system. The following extra modules will be installed: (auto-selected) drm drm-nouveau staging virtualbox Try to install kernel kernel-image-6.11-6.11.6-alt1 and 4 modules [Y/n]? # rpm -q update-kernel update-kernel-1.19-alt1.noarch
Возможно, надо было подождать 6.6-6.6.59 перед удалением un-def-6.6.58. Но, со сборкой 6.6.59 сейчас проблемы. Маинайтнеры модулей drbd9 и nvidia не спешат фиксить их сборку (с 1 ноября).
(Ответ для Vitaly Chikunov на комментарий #1) > Возможно, надо было подождать 6.6-6.6.59 перед удалением un-def-6.6.58. Но, > со сборкой 6.6.59 сейчас проблемы. Маинайтнеры модулей drbd9 и nvidia не > спешат фиксить их сборку (с 1 ноября). Я думаю, что это прекрасная возможность скорректировать текущий алгоритм. Такого быть не должно. Условие неверное: Searching for a newer flavour (>= 6.6.58-un-def-alt1)... Нужно выбирать исключительно из цифровых flavour'ов наименьший из них. Иначе впереди нас ждёт много неприятных казусов.
(Ответ для Антон Мидюков на комментарий #2) > (Ответ для Vitaly Chikunov на комментарий #1) > > Возможно, надо было подождать 6.6-6.6.59 перед удалением un-def-6.6.58. Но, > > со сборкой 6.6.59 сейчас проблемы. Маинайтнеры модулей drbd9 и nvidia не > > спешат фиксить их сборку (с 1 ноября). > > Я думаю, что это прекрасная возможность скорректировать текущий алгоритм. > Такого быть не должно. Условие неверное: > > Searching for a newer flavour (>= 6.6.58-un-def-alt1)... > > Нужно выбирать исключительно из цифровых flavour'ов наименьший из них. > Иначе впереди нас ждёт много неприятных казусов. То есть не версии ядер сравнивать, а цифровые flavour'ы. Если flavour нецифровой, то выбирать наименьший цифровой.
Тогда при удалении un-def (6.6) будет прыгать на 6.1 если он есть.
(Ответ для Vitaly Chikunov на комментарий #4) > Тогда при удалении un-def (6.6) будет прыгать на 6.1 если он есть. Хорошо. Согласен. Не самая лучшая идея. Предлагаю улучшить алгоритм следующим образом. Сравнивать найденные цифровые flavour формата %version-<flavour>-%release с %version текущего ядра, чтобы flavour текущего ядра не имел значения. Тогда при подобных коллизиях (равенство %version) будет выбираться ядро с такой же версией или выше.
