Дефектные обновления [Core, Extra, Community, Multilib]

Опять накатил новый lts и получил ту же проблему. Теперь сфотографировал с экрана. Переписываю, как это начинается:
[OK] Mounted Arbitrary Excutable File Format System
[7.8] systemd[1]: Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service'
Starting Apply Kernel Variables
...
Started Journal Service
systemctl status systemd-modules-load.service делал, там голый failed, без всяких дополнительных пояснений.
При генерации initramfs ничего необычного не выводилилось.
akorop
там голый failed
В journalctl -b -u
 journalctl  -u systemd-modules-load.service
ничего нет?
или по pid

 systemctl status systemd-modules-load.service
[quote]● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset>
   Active: active (exited) since Sun 2019-02-10 21:30:02 EET; 9s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 2670 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
 Main PID: 2670[/quote]

journalctl -b _PID=2670
Тогда, после выхода в emergency mode, выхлоп такой:
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static; vendor preset: disabled)
   Active: failed (Result: exit-code) since Sun 2019-02-10 22:00:53 EET; 50s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
  Process: 248 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
 Main PID: 248 (code=exited, status=1/FAILURE)
Сейчас, с нормально загрузившейся системой, команда journalctl -u systemd-modules-load.service | grep failed даёт пустой вывод.
akorop
grep failed даёт пустой вывод
А без грипа что кажет? Если слишком большой вывод то по номеру загрузки journalctl -b -1 -u
vs220
А без грипа что кажет?
Без счёту раз повторенный нормальный вывод. А какая, собственно, разница? Я ж при криво загуженной системе сохранил (и выше привёл) вывод с ошибкой.
Но, вообще, меня меньше интересуют вопросы "кто виноват" (фиг с ним). и "что делать" (откатил ядро, и всё работает). А очень интересно, на будущее, что может быть причиной одновременного и одинакового дефекта с основным ядром и с lts-ядром. По идее, lts для того и отстаёт, чтобы туда попадали только проверенные изменения, то есть одно и то же изменение не должно попадать одновременно в основное и в lts-ядро.
И вобще, ядро ли виновато? Может, как уже высказывалось, источник проблемы - initcpio? Или ещё что-то, связанное не с функциональностью ядра, а с оформлением?
akorop
Без счёту раз повторенный нормальный вывод
Что то не обратил внимание что журнал стартует после
[7.8] systemd[1]: Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service'
Starting Apply Kernel Variables

Started Journal Service
И ошибки не попадают в журнал

Тогда можно попробовать (на сбойном ядре)
systemctl restart systemd-modules-load.service
# и
journalctl -b -u systemd-modules-load
dmesg |grep modul
dmesg |grep error
так по идее должно в журнал попасть (если только смонтировался /var на запись, потому что может как раз и модуль файловой глючить и монтировать только на чтение)

akorop
что может быть причиной одновременного и одинакового дефекта
Какой то модуль скорее всего не подходит для новых ядер. Такое часто бывает с модулями виртуалбокса или собранными под старое ядро DKMS

akorop
initcpio?
Можно на всякий случай проверить на ошибки
pacman -Sy linux linux-headers
mkinitcpio -P
и чтобы версии модулей совпадали с версией ядра
 bsdcpio -itF /boot/initramfs-linux.img |grep module
akorop
А очень интересно, на будущее, что может быть причиной одновременного и одинакового дефекта с основным ядром и с lts-ядром. По идее, lts для того и отстаёт, чтобы туда попадали только проверенные изменения, то есть одно и то же изменение не должно попадать одновременно в основное и в lts-ядро.
И вобще, ядро ли виновато? Может, как уже высказывалось, источник проблемы - initcpio? Или ещё что-то, связанное не с функциональностью ядра, а с оформлением?
Подробно не вникал, в смысле не читал. Но я бы попробовал 2 варианта/способа, чтобы получить больше информации. От обычного логирования здесь похоже толку мало и нужно пробовать не стандартные способы.
Если я правильно понял, то управление уже передается systemd, так как ругается на ошибку systemd-modules-load.service, а значит нужно дебажить только этот юнит. Способов несколько, но учитывая его особенности (systemd-modules-load.service; static; vendor preset: disabled) похоже в данном случае подойдет только использование strace, а именно использовать, например, следующий запуск (изменить кто как привык)
- или с выводом в файл (будет создан файл systemd-modules-load.strace)
ExecStart=/usr/bin/strace -f -tt -o /run/%N.strace /lib/systemd/systemd-modules-load
- или без вывода в файл (результат работы будет включен в лог journal)
ExecStart=/usr/bin/strace -f -tt /lib/systemd/systemd-modules-load

Если грешите на модули, то можно попробовать отследить загрузку модулей, используя параметр загрузки initcall_debug, но это работает только для встроенных в ядро модулей и помогает отследить где затыкается ядро.
В вывде будут строки типа
calling  evdev_init+0x0/0x1000 [evdev] @ 250
initcall evdev_init+0x0/0x1000 [evdev] returned 0 after 222 usecs
то есть указано время загрузки и код возврата ошибки загрузки (returned 0 - успешно, returned N - ошибка)
UPD - кстати это хорошо помагает при проблемах с suspend по причине модулей

И лучше при анализе активировать debug-shell.service и работать из создаваемой им shell оболочки.
Ошибки не исчезают с опытом - они просто умнеют
Обновление libvncserver до версии 0.9.12 - кривое. Использую совместно с ним x11vnc. Обновились эти пакеты после длительного периода затишья практически одновременно. После обновления сессии начали зависать, после убийства x11vnc отказывался стартовать с ошибкой, лечилось только перезагрузкой. Вначале откатил x11vnc - не помогло, после отката libvncserver до версии 0.9.11-3 все стало опять нормально работать. Взять старую версию можно как обычно в archive.archlinux.org и приморозить, либо собрать самому с другим именем, дабы pacman не ругался - тут уж кому как удобнее.
Способ добавления проблемного пакета в /etc/pacman.conf секцию "IgnorePkg =" наиболее традиционен для арча. Однако со временем могут возникать проблемы с зависимостями. Поэтому желательно мониторить ситуацию и после исправления багов всё же обновиться. Роллинг же) К счастью, в последнее время проблемы возникают крайне редко.
 
Зарегистрироваться или войдите чтобы оставить сообщение.