Вопрос или проблема
Около месяца назад я обновил свою систему с 22.04 на 24.04. До этого обновления система была очень стабильной, проблем не было. Сразу после обновления система начала периодически перезагружаться. (т.е. Ubuntu работает и работает, ничего или фактически ничего, и я вижу экран BIOS).
После поиска информации я нашел людей, которые говорили: “Сделайте чистую установку”. Я сохранил резервную копию своего /home/user и /etc и переустановил 24.04 заново. При переустановке я взял только свою старую конфигурацию samba из /etc и пользовался своими файлами из /home/user, после чего начал заново настраивать и использовать свою новую установленную машину с Ubuntu. К моему удивлению, она снова начала периодически перезагружаться. Многие разы машина просто стояла без дела, и происходила перезагрузка.
Я озадачен этим, так как она ведет себя так, как будто есть проблема с аппаратным обеспечением, но изменений в оборудовании не было ни до, ни после обновления. Машина обладает хорошей вентиляцией, и нет причин подозревать, что происходит перегрев. Во многих случаях она просто простаивает, когда перезагружается.
Мои попытки разрешить или изолировать проблему до сих пор включают (не обязательно в порядке очереди):
- Обновление BIOS до последней версии. (Материнская плата – ASUS ROG STRIX B550-F (wi-fi))
- Полное тестирование памяти memtest86. Заняло 2 часа 28 минут, чтобы полностью протестировать 128 ГБ, работая в SMP. Я думал, что SMP хорошо, потому что он должен тестировать несколько ядер процессора. Не было сбоев.
- Нагрузочный тест процессора, где я нагружал свой процессор (AMD Ryzen 5 5600X) немного. Не было сбоев.
- Проверил последние графические драйверы для видеокарты (AMD Radeon RX 580)
- Провел тест GPU с использованием Unigine valley. Не было сбоев.
- Отключил функции Wi-Fi и Bluetooth на материнской плате. Непредсказуемая перезагрузка все еще происходила.
- Заменил блок питания на новый. Непредсказуемая перезагрузка все еще происходила.
- Я включил ведение журнала отладки ядра (по-моему), добавив:
kernel.printk = 7 7 1 7в /etc/sysctl.conf, а затем подтвердил, что это было включено, используяcat /proc/sys/kernel/printk
Мне не удалось изолировать ничего, что последовательно происходило в журналах. Например, если я возьму вывод last reboot и посмотрю на недавние:
reboot system boot 6.8.0-48-generic Wed Nov 20 16:01 still running
reboot system boot 6.8.0-48-generic Wed Nov 20 15:43 still running
reboot system boot 6.8.0-48-generic Wed Nov 20 15:25 - 15:43 (00:17)
reboot system boot 6.8.0-48-generic Wed Nov 20 14:49 - 15:43 (00:53)
reboot system boot 6.8.0-48-generic Wed Nov 20 14:40 - 14:48 (00:08)
reboot system boot 6.8.0-48-generic Wed Nov 20 13:23 - 14:48 (01:24)
reboot system boot 6.8.0-48-generic Wed Nov 20 12:19 - 14:48 (02:28)
reboot system boot 6.8.0-48-generic Wed Nov 20 11:36 - 14:48 (03:12)
Эти времена представляют собой перезагрузку системы. Обычно указывается “по-прежнему работает”, когда происходит сбой и перезагрузка, но затем происходит какая-то очистка. Почти все вышеперечисленное представляет собой непредсказуемые перезагрузки с исключением, возможно, 2 случаев, когда я настраивал конфигурацию и хотел убедиться, что она активна.
Если я перейду к /var/log/kern.log и начну искать назад “Linux version” (первый журнал перезагрузки), я могу увидеть журналы, которые произошли прямо перед перезагрузкой. Кажется, нет ничего последовательного в причине. Например, вот 16:01.
2024-11-20T15:44:48.904343-07:00 svr kernel: audit: type=1400 audit(1732142688.903:192): apparmor="DENIED" operation="capable" class="cap" profile="/usr/lib/snapd/snap-confine" pid=4428 comm="snap-confine" capability=38 capname="perfmon"
2024-11-20T16:01:55.246557-07:00 svr kernel: Linux version 6.8.0-48-generic (buildd@lcy02-amd64-010) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #48-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 27 14:04:52 UTC 2024 (Ubuntu 6.8.0-48.48-generic 6.8.12)
и вот 15:43
2024-11-20T15:43:09.543269-07:00 svr kernel: exe="/usr/bin/dbus-daemon" sauid=101 hostname=? addr=? terminal=?'
2024-11-20T15:43:35.769171-07:00 svr kernel: Linux version 6.8.0-48-generic (buildd@lcy02-amd64-010) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #48-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 27 14:04:52 UTC 2024 (Ubuntu 6.8.0-48.48-generic 6.8.12)
Обратите внимание, что существует значительный разрыв в журналах между записями. Например, в 16:01 был 15-минутный разрыв между последним журнальным сообщением ядра и перезагрузкой. В то время как в 15:43, участок “тишины” составил около 20 секунд. Я видел другие перезагрузки, где до перезагрузки в журналах было двоичное мусорное содержимое, например:
2024-11-19T11:00:56.597426-07:00 svr kernel: exe="/usr/bin/dbus-daemon" sauid=101 hostname=? addr=? terminal=?'
^@^@^@[много ^@ вырезано]^@2024-11-19T11:03:04.550077-07:00 svr kernel: Linux version 6.8.0-48-generic (buildd@lcy02-amd64-010) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #48-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 27 14:04:52 UTC 2024 (Ubuntu 6.8.0-48.48-generic 6.8.12)
2024-11-19T11:03:04.550299-07:00 svr kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.8.0-48-generic root=UUID=60c9acc4-90f4-4d74-acdc-ad21be5bbc15 ro quiet splash vt.handoff=7
Я в замешательстве по поводу того, что может происходить. Эта машина была замечательной и стабильной несколько лет на 22.04. И затем сразу же после установки 24.04 она начала случайным образом перезагружаться. В промежутках между этими случайными перезагрузками она прекрасно работает. 🙁
Если кто-то может сказать мне “включите эту настройку” и посмотрите этот журнал, и мы сможем узнать, в чем причина перезагрузки, я был бы очень признателен!!!
Одна часть откровенных данных (то, что выходит на свет в конце долгих сессий по устранению неполадок):
У моего сына была материнская плата/процессор в его машине, работающей на Windows, и у меня было другое оборудование в моей машине. Что-то произошло, и его Windows упала — ужасно. Я не смог его восстановить с помощью обычных средств USB Windows, поэтому я полностью обнулил его жесткий диск, загрузившись с Ubuntu USB, используя dd от /dev/zero до его диска. Я пытался много раз и разными способами переустановить Windows 10, но это не сработало, хотя это была фактически новая система.
Мой окончательный вывод заключался в том, что я возьму эту материнскую плату/процессор и поменяю с тем, что у меня была в машине. Работало отлично, пока я не установил Ubuntu 24.04.
Учитывая странный характер этой проблемы, моя лучшая догадка: где-то произошел небольшой аппаратный сбой на материнской плате таким образом, что Windows не могла работать или устанавливаться. Ubuntu 22.04 работала и функционировала нормально, потому что, возможно, она не использовала этот участок оборудования??? А затем какое-то изменение в ядре/ПО Ubuntu 24.04 теперь использует это оборудование и теперь все работает? Странно, что у меня был такой большой успех с 22.04 так долго.
У меня есть еще два сына, один работает на Windows 10, а другой на Ubuntu 24.04 на этой же материнской плате и процессоре. Без проблем.
Поскольку это не блок питания, может быть что-то ненадежное в каком-то компоненте на материнской плате, и мне следует просто хорошенько поплакать над этим и выкладывать $$$ на новую?
Ответ или решение
К сожалению, вы столкнулись с серьезной и непростой проблемой — случайными перезагрузками вашей системы после обновления с Ubuntu 22.04 до 24.04. Это означает, что идея о том, что проблема может заключаться в аппаратной части, всё более становится вероятной, учитывая, что вы предприняли множество шагов по диагностике программного обеспечения. Давайте рассмотрим потенциальные причины и решения данной проблемы.
1. Анализ аппаратных компонентов
Материнская плата и процессор
Поскольку у вас уже возникали проблемы с материнской платой ASUS ROG STRIX B550-F и процессором AMD Ryzen 5 5600X в прошлом, стоит обратить особое внимание на их состояние. Возможно, материнская плата имеет скрытые дефекты или поврежденные компоненты, которые только сейчас проявляются под нагрузкой.
Память и охлаждение
Хотя вы уже провели тестирование памяти с помощью Memtest86, рекомендуется повторно проверить состояние охлаждения системы. Проверьте, не забиты ли вентиляторы пылью и обеспечивают ли они адекватный воздухообмен. Будьте внимательны к температурным показателям процессора и других компонентов.
Блок питания
Вы упомянули, что заменили блок питания на новый, однако стоит убедиться, что он действительно достаточно мощный для вашей конфигурации. Распределение мощности может оказаться неравномерным из-за использованных компонентов, особенно если ваш блок питания находится на грани своих возможностей.
2. Программное обеспечение и настройки ядра
Обновление ядра
Поскольку проблема могла начаться после обновления до 24.04, возможно, вам стоит рассмотреть возможность отката к предыдущей версии ядра, чтобы проверить, сохраняется ли проблема. Это можно сделать с помощью загрузчика GRUB, выбрав более раннюю версию ядра.
Настройки параметров ядра
Похоже, вы уже предприняли шаги для включения отладки ядра, но стоит также протестировать систему с вашими текущими конфигурациями, изменяя некоторые параметры. Попробуйте отключить параметры, такие как quiet splash, чтобы получить больше информации в процессе загрузки.
3. Логи и события системы
Вы уже проверили журналы /var/log/kern.log, но рекомендуется собрать больше данных. Используйте команды dmesg и journalctl -b -1 для анализа сообщений ядра и системных сообщений до последнего перезагрузки. Это может подсказать наличие каких-либо ошибок или конфликтов.
4. Устранение конфликта программного обеспечения
Иногда обновление может приводить к конфликтам в программном обеспечении или драйверах. Рекомендуется:
- Протестировать систему без дополнительных драйверов графической карты, используя режим «Режим для восстановления» (recovery mode).
- Удалить или временно деактивировать любые дополнительные пакеты или конфигурации, которые могли быть перенесены с 22.04.
- Проверить наличие обновлений и исправлений для всех пакетов и драйверов, особенно для графической карты Radeon RX 580.
5. Рассмотрите полный сброс
Если вышеуказанные шаги не приводят к решению, возможно, стоит рассмотреть возможность полной переустановки системы, убедившись в том, что вы используете только самые основные пакеты. Это позволит вам исключить любую возможность конфликта программного обеспечения, который мог быть перенесен с предыдущей установки.
Заключение
Ваши попытки решения проблемы демонстрируют глубокое понимание аппаратной и программной архитектуры системы. Тем не менее, учитывая, что система была стабильной на Ubuntu 22.04 и началась нестабильная работа после перехода к 24.04, проблема действительно может заключаться в какой-то несоответствии аппаратных компонентов. Если все предложенные шаги будут безуспешны, возможно, разумно будет рассмотреть замену материнской платы.
Надеюсь, эти рекомендации помогут вам в нахождении и решении проблемы.