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

akorop	# 5 лет, 9 месяцев назад
Темы: 111 Сообщения: 1756 Участник с: 29 февраля 2012	Опять накатил новый 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 ничего необычного не выводилилось.

# 5 лет, 9 месяцев назад

Сообщения: 1756

Участник с: 29 февраля 2012

Опять накатил новый 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 ничего необычного не выводилилось.

vs220	# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)
Темы: 25 Сообщения: 8524 Участник с: 16 августа 2009	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`

vs220

# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)

Темы: 25

Сообщения: 8524

Участник с: 16 августа 2009

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

akorop	# 5 лет, 9 месяцев назад
Темы: 111 Сообщения: 1756 Участник с: 29 февраля 2012	Тогда, после выхода в 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

# 5 лет, 9 месяцев назад

Темы: 111

Сообщения: 1756

Участник с: 29 февраля 2012

Тогда, после выхода в 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 даёт пустой вывод.

vs220	# 5 лет, 9 месяцев назад
Темы: 25 Сообщения: 8524 Участник с: 16 августа 2009	akorop grep failed даёт пустой вывод А без грипа что кажет? Если слишком большой вывод то по номеру загрузки journalctl -b -1 -u

akorop	# 5 лет, 9 месяцев назад
Темы: 111 Сообщения: 1756 Участник с: 29 февраля 2012	vs220 А без грипа что кажет? Без счёту раз повторенный нормальный вывод. А какая, собственно, разница? Я ж при криво загуженной системе сохранил (и выше привёл) вывод с ошибкой. Но, вообще, меня меньше интересуют вопросы "кто виноват" (фиг с ним). и "что делать" (откатил ядро, и всё работает). А очень интересно, на будущее, что может быть причиной одновременного и одинакового дефекта с основным ядром и с lts-ядром. По идее, lts для того и отстаёт, чтобы туда попадали только проверенные изменения, то есть одно и то же изменение не должно попадать одновременно в основное и в lts-ядро. И вобще, ядро ли виновато? Может, как уже высказывалось, источник проблемы - initcpio? Или ещё что-то, связанное не с функциональностью ядра, а с оформлением?

akorop

# 5 лет, 9 месяцев назад

Темы: 111

Сообщения: 1756

Участник с: 29 февраля 2012

vs220
А без грипа что кажет?

Без счёту раз повторенный нормальный вывод. А какая, собственно, разница? Я ж при криво загуженной системе сохранил (и выше привёл) вывод с ошибкой.
Но, вообще, меня меньше интересуют вопросы "кто виноват" (фиг с ним). и "что делать" (откатил ядро, и всё работает). А очень интересно, на будущее, что может быть причиной одновременного и одинакового дефекта с основным ядром и с lts-ядром. По идее, lts для того и отстаёт, чтобы туда попадали только проверенные изменения, то есть одно и то же изменение не должно попадать одновременно в основное и в lts-ядро.
И вобще, ядро ли виновато? Может, как уже высказывалось, источник проблемы - initcpio? Или ещё что-то, связанное не с функциональностью ядра, а с оформлением?

vs220	# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)
Темы: 25 Сообщения: 8524 Участник с: 16 августа 2009	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`

vs220

# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)

Темы: 25

Сообщения: 8524

Участник с: 16 августа 2009

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

vasek	# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)
Темы: 47 Сообщения: 11856 Участник с: 17 февраля 2013	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 оболочки. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)

Темы: 47

Сообщения: 11856

Участник с: 17 февраля 2013

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 оболочки.

Ошибки не исчезают с опытом - они просто умнеют

Andy_Vetrov	# 5 лет, 9 месяцев назад
Темы: 2 Сообщения: 27 Участник с: 09 февраля 2019	Обновление libvncserver до версии 0.9.12 - кривое. Использую совместно с ним x11vnc. Обновились эти пакеты после длительного периода затишья практически одновременно. После обновления сессии начали зависать, после убийства x11vnc отказывался стартовать с ошибкой, лечилось только перезагрузкой. Вначале откатил x11vnc - не помогло, после отката libvncserver до версии 0.9.11-3 все стало опять нормально работать. Взять старую версию можно как обычно в archive.archlinux.org и приморозить, либо собрать самому с другим именем, дабы pacman не ругался - тут уж кому как удобнее.

Andy_Vetrov

# 5 лет, 9 месяцев назад

Темы: 2

Сообщения: 27

Участник с: 09 февраля 2019

Обновление libvncserver до версии 0.9.12 - кривое. Использую совместно с ним x11vnc. Обновились эти пакеты после длительного периода затишья практически одновременно. После обновления сессии начали зависать, после убийства x11vnc отказывался стартовать с ошибкой, лечилось только перезагрузкой. Вначале откатил x11vnc - не помогло, после отката libvncserver до версии 0.9.11-3 все стало опять нормально работать. Взять старую версию можно как обычно в archive.archlinux.org и приморозить, либо собрать самому с другим именем, дабы pacman не ругался - тут уж кому как удобнее.

vall	# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	Способ добавления проблемного пакета в /etc/pacman.conf секцию "IgnorePkg =" наиболее традиционен для арча. Однако со временем могут возникать проблемы с зависимостями. Поэтому желательно мониторить ситуацию и после исправления багов всё же обновиться. Роллинг же) К счастью, в последнее время проблемы возникают крайне редко.

vall

# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)

Темы: 45

Сообщения: 1786

Участник с: 28 марта 2017

Способ добавления проблемного пакета в /etc/pacman.conf секцию "IgnorePkg =" наиболее традиционен для арча. Однако со временем могут возникать проблемы с зависимостями. Поэтому желательно мониторить ситуацию и после исправления багов всё же обновиться. Роллинг же) К счастью, в последнее время проблемы возникают крайне редко.

vadik	# 5 лет, 9 месяцев назад (отредактировано 5 лет, 9 месяцев назад)
Темы: 57 Сообщения: 5495 Участник с: 17 августа 2009	Тему почистил. Дальше, пожалуйста, без флуда. Либо --> в профильные темы/ветки.