(Linux Mint 18 x64) Компьютер перезагружается вместо выключения
Здравствуйте! Установил только сегодня Linux Mint на ноут Acer Aspire V5. По нажатию кнопки «Выключить» компьютер перезагружается. Винда 10 выключалась нормально, проблема наверное в Linux. Как это решить? Лучше окончательно. (Приложения: Wine, PlayOnLinux, Steam, Civilization V)
Какой кнопки? Физической на корпусе или графической?
Fodro , если ты действительно хочешь получить ответ, не следует отписываться от темы, так ты не будешь получать уведомления.
Ещё не совсем разобрался с итерфейсом, отписался случайно
Какое именно у тебя DE и битность? Cinnamon, Mate, Xfce, KDE; 64 или 32 бита?
Попробуй выключить его командой
Если выключился нормально, то проблема в GUI, если тоже перезагружается, то глубже.
Поставил ту же ось в виртуалку, обновился до предела, поставил wine и steam.
Кнопка выключения работает корректно, а вот стим не запускается, вайн не проверял.
Попробуй выключиться через терминал и сообщи результат (команду я написал выше).
Перепробывал все известные мне команды выключения компьютера через терминал, работает только halt, система просто останавливается на определённом моменте и можно безболезненно выключить компьютер удерживанием кнопки питания (аварийное отключение). Хотелось бы нормального выключения.
На десктопе подобная ерунда бывает из-за кривых настроек BIOS/EFI.
Поддерживаю оратора выше, это точно UEFI.
Рекомендую отключить его нахрен с секурбутом, и переставить систему.
UEFI я отключил ещё до установки, т.к. SecureBoot мешал загрузке с установочной флешки. Какой примерно пункт настроек BIOS искать?
BIOS тоже отключить?
Ты эту тему для начала на минтовском форуме читал?
Попробуй все советы оттуда, а потом уже пиши сюда. Сейчас тебе местные специалисты по всему досоветуют до полного сноса.
Сейчас тебе местные специалисты по всему досоветуют до полного сноса.
Рекомендую отключить его нахрен с секурбутом, и переставить систему.
Я имел ввиду отключить загрузку с носителей в EFI-режиме, оставив только BIOS-режим.
Хватит придираться к словам, ты тоже говоришь «процессор», хотя это корректнее называть SoC.
Нет, не корректно. SoC это SoC, процессор это процессор
Да, но i3, например, многие называют процессором, хотя это явно SoC, там ведь есть встроенная видеокарта, а в последних версиях — и звуковая.
Скорее всего все эти вещи не при чем.
У меня есть некоторое кол-во RHEL6 на ESXi
poweroff вызывает ребут, это серверы, которые перегружаются редко. грешил на ESXi, но теперь призадумался
WOL causes spontaneous power on after shutdown [SOLVED]
https://bbs.archlinux.org/viewtopic.php?id=173648
У меня такая же шляпа на одной из машин, причём с дефолтными настройками.
Ни один из советов не помог.
Дело не в WOL, т.к. я его отрубил
Распиши что конкретно делал, и
система просто останавливается на определённом моменте и можно безболезненно выключить компьютер удерживанием кнопки
На каком? Сравни выдачу или скинь лог тоже сюда
WOL ты уже проверил, да?
Сори, не заметил сразу.
Какой конкретно лог? Я в этом не сильно разбираюсь
Для начала нужно разобраться – «корректно» ли происходит отключение. Если да – то должна быть запись в last, проверь (вывод last -x shutdown). Если нет, то отладочную инфу придется искать в логах ядра.
И еще:
UEFI я отключил ещё до установки, т.к. SecureBoot мешал загрузке с установочной флешки. Какой примерно пункт настроек BIOS искать?
И что стоит в boot mode? Legacy? И SecureBoot установлен в disabled, я правильно понимаю?
В Boot Mode: Legacy BIOS, secure boot отсутствует как функция
Вот вывод: shutdown system down 4.4.0-47-generic Sun Nov 20 14:33 — 16:12 (01:39) shutdown system down 4.4.0-47-generic Sun Nov 20 14:30 — 14:30 (00:00) shutdown system down 4.4.0-47-generic Sun Nov 20 13:58 — 13:58 (00:00) shutdown system down 4.4.0-47-generic Sun Nov 20 13:54 — 13:57 (00:02) shutdown system down 4.4.0-47-generic Sun Nov 20 13:28 — 13:28 (00:00) shutdown system down 4.4.0-47-generic Sun Nov 20 13:16 — 13:16 (00:00) shutdown system down 4.4.0-47-generic Sun Nov 20 13:07 — 13:07 (00:00) shutdown system down 4.4.0-47-generic Sun Nov 20 13:03 — 13:04 (00:01) shutdown system down 4.4.0-47-generic Sun Nov 20 12:44 — 12:44 (00:00) shutdown system down 4.4.0-47-generic Sun Nov 20 12:42 — 12:42 (00:00) shutdown system down 4.4.0-47-generic Sun Nov 20 12:38 — 12:39 (00:00) shutdown system down 4.4.0-21-generic Sun Nov 20 11:49 — 11:50 (00:00) shutdown system down 4.4.0-21-generic Sun Nov 20 11:48 — 11:48 (00:00) shutdown system down 4.4.0-21-generic Sun Nov 20 11:46 — 11:46 (00:00) shutdown system down 4.4.0-21-generic Sun Nov 20 11:44 — 11:44 (00:00) shutdown system down 4.4.0-21-generic Sat Nov 19 22:10 — 22:10 (00:00) shutdown system down 4.4.0-21-generic Sat Nov 19 22:09 — 22:09 (00:00) shutdown system down 4.4.0-21-generic Sat Nov 19 16:38 — 16:38 (00:00)
wtmp begins Sat Nov 19 16:26:29 2016
shutdown system down 4.4.0-21-generic Sat Nov 19 16:38 — 16:38 (00:00)
Последнее «нормальное» завершение было в 16:38 19 ноября? Все правильно?
Добавьте туда же плиз и вывод ребутов Только, пожалуйста, оборачивайте вывод в lorcode, возможно понадобится и syslog, а читать _это_ достаточно сложно.
Еще рекомендую обратить внимания на эту тему.
Здесь, как видно проблема абсолютно аналогичная, только бубунта вместо минта и aser aspire es1-512, выступающий в качестве больного.
Вопрос решен с помощью добавления в /etc/default/grub
Based on these suggestions, I made the following changes to my grub file:
GRUB_CMDLINE_LINUX_DEFAULT=«quiet splash noapic irqpoll»
Lo and Behold. it shuts down and powers off.
Нет полной уверенности, т.к. у ОПа EFI, но рекомендую попробовать. В любом случае это не аппаратная проблема, ведь ваша ситуация аналогична приведенной – шинда ведет себя абсолютно адекватно.
Добавление нужной строчки в /etc/default/grub. сработало! Спасибо большое за помощь, а то я уж думал возвращаться на эту отвратную Винду.
Компьютер два раза выключился штатно, теперь проблема вернулась!
Проблема вернулась. Вот вывод:
reboot system boot 4.4.0-47-generic Mon Nov 21 21:25 still running
shutdown system down 4.4.0-47-generic Mon Nov 21 21:25 — 21:25 (00:00)
reboot system boot 4.4.0-47-generic Mon Nov 21 21:19 — 21:25 (00:05)
shutdown system down 4.4.0-47-generic Mon Nov 21 21:19 — 21:19 (00:00)
reboot system boot 4.4.0-47-generic Mon Nov 21 21:18 — 21:19 (00:01)
shutdown system down 4.4.0-47-generic Mon Nov 21 21:17 — 21:18 (00:00)
reboot system boot 4.4.0-47-generic Mon Nov 21 20:15 — 21:17 (01:02)
reboot system boot 4.4.0-47-generic Mon Nov 21 13:52 — 21:17 (07:25)
shutdown system down 4.4.0-47-generic Mon Nov 21 13:49 — 13:52 (00:02)
reboot system boot 4.4.0-47-generic Mon Nov 21 13:44 — 13:49 (00:04)
shutdown system down 4.4.0-47-generic Sun Nov 20 18:24 — 13:44 (19:20)
reboot system boot 4.4.0-47-generic Sun Nov 20 16:53 — 18:24 (01:31)
shutdown system down 4.4.0-47-generic Sun Nov 20 16:34 — 16:53 (00:18)
reboot system boot 4.4.0-47-generic Sun Nov 20 16:12 — 16:34 (00:21)
shutdown system down 4.4.0-47-generic Sun Nov 20 14:33 — 16:12 (01:39)
reboot system boot 4.4.0-47-generic Sun Nov 20 14:30 — 14:33 (00:02)
shutdown system down 4.4.0-47-generic Sun Nov 20 14:30 — 14:30 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:58 — 14:30 (00:31)
shutdown system down 4.4.0-47-generic Sun Nov 20 13:58 — 13:58 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:57 — 13:58 (00:01)
shutdown system down 4.4.0-47-generic Sun Nov 20 13:54 — 13:57 (00:02)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:37 — 13:54 (00:17)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:31 — 13:54 (00:23)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:28 — 13:54 (00:26)
shutdown system down 4.4.0-47-generic Sun Nov 20 13:28 — 13:28 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:16 — 13:28 (00:12)
shutdown system down 4.4.0-47-generic Sun Nov 20 13:16 — 13:16 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:07 — 13:16 (00:08)
shutdown system down 4.4.0-47-generic Sun Nov 20 13:07 — 13:07 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 13:04 — 13:07 (00:02)
shutdown system down 4.4.0-47-generic Sun Nov 20 13:03 — 13:04 (00:01)
reboot system boot 4.4.0-47-generic Sun Nov 20 12:47 — 13:03 (00:15)
reboot system boot 4.4.0-47-generic Sun Nov 20 12:44 — 13:03 (00:18)
shutdown system down 4.4.0-47-generic Sun Nov 20 12:44 — 12:44 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 12:42 — 12:44 (00:01)
shutdown system down 4.4.0-47-generic Sun Nov 20 12:42 — 12:42 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 12:39 — 12:42 (00:02)
shutdown system down 4.4.0-47-generic Sun Nov 20 12:38 — 12:39 (00:00)
reboot system boot 4.4.0-47-generic Sun Nov 20 12:37 — 12:38 (00:01)
reboot system boot 4.4.0-21-generic Sun Nov 20 11:50 — 12:38 (00:48)
shutdown system down 4.4.0-21-generic Sun Nov 20 11:49 — 11:50 (00:00)
reboot system boot 4.4.0-21-generic Sun Nov 20 11:48 — 11:49 (00:00)
shutdown system down 4.4.0-21-generic Sun Nov 20 11:48 — 11:48 (00:00)
reboot system boot 4.4.0-21-generic Sun Nov 20 11:46 — 11:48 (00:01)
shutdown system down 4.4.0-21-generic Sun Nov 20 11:46 — 11:46 (00:00)
reboot system boot 4.4.0-21-generic Sun Nov 20 11:44 — 11:46 (00:01)
shutdown system down 4.4.0-21-generic Sun Nov 20 11:44 — 11:44 (00:00)
reboot system boot 4.4.0-21-generic Sun Nov 20 11:42 — 11:44 (00:01)
reboot system boot 4.4.0-21-generic Sun Nov 20 11:39 — 11:44 (00:04)
reboot system boot 4.4.0-21-generic Sat Nov 19 22:10 — 11:44 (13:33)
shutdown system down 4.4.0-21-generic Sat Nov 19 22:10 — 22:10 (00:00)
reboot system boot 4.4.0-21-generic Sat Nov 19 22:09 — 22:10 (00:01)
shutdown system down 4.4.0-21-generic Sat Nov 19 22:09 — 22:09 (00:00)
reboot system boot 4.4.0-21-generic Sat Nov 19 16:38 — 22:09 (05:30)
shutdown system down 4.4.0-21-generic Sat Nov 19 16:38 — 16:38 (00:00)
reboot system boot 4.4.0-21-generic Sat Nov 19 16:26 — 16:38 (00:11)
wtmp begins Sat Nov 19 16:26:29 2016
P.S. Попытался обернуть в lorcode
Кстати, перед тем как проблема вернулась, были установлены Gparted и VirtualBox, может дело в них?
Проблема решена полностью установкой Седьмой Винды, другого решения я не нашёл
Источник
ИТ База знаний
Курс по Asterisk
Полезно
— Узнать IP — адрес компьютера в интернете
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Калькулятор инсталляции IP — АТС Asterisk
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Как узнать причину перезагрузки Linux
Что вызвало ребут?
4 минуты чтения
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев.
Проверка времени перезагрузки
Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last
Проверка системных журналов
Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями.
Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages , а для систем Ubuntu/Debian — по адресу /var/log/syslog . Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор.
Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root . Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину.
Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов:
Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы.
Проверка журнала auditd
Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch . Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита.
Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN , за которым следует SYSTEM_BOOT , все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT , то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим:
В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT , которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала.
Анализ журнала systemd
Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf , либо создать каталог самостоятельно с помощью следующих команд:
После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется.
Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала:
Вот его выходные данные на моем сервере:
Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте:
Здесь
В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются.
Заключение
Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины.
Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.
Мини — курс по виртуализации
Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена
Источник
