Manjaro linux зависает при загрузке
Обновлено: 03.07.2024
В Manjaro и Arch Linux некоторые пользователи столкнулись с необычной проблемой: при загрузке системы вместо окна входа показывается практически чёрный экран, иногда с курсором мыши. Если перейти на второй TTY с помощью сочетаний клавиш Ctrl + Alt + F2, то можно выполнить вход. При этом команда проверки статуса менеджера отображения GDM
показывает, что служба загружена работает без ошибок.
Ещё более удивительно то, что если просто нажать Ctrl + Alt + F2, а затем переключиться обратно на TTY 1 с помощью кнопок Ctrl + Alt + F1, то мы вернёмся на tty1 и появится экран входа!
Такое происходит при следующей конфигурации:
- дистрибутив на основе Arch Linux
- GDM в качестве менеджера дисплея
- проприетарные драйвера NVIDIA
В некоторых случаях загрузка происходит нормально, без данной проблемы.
Данная ситуация упоминалась, например, на следующих ветках форума:
При попытке решения данной проблемы было перепробовано множество настроек, установка дополнительных пакетов, откат ядра, изучение и исправление ошибок в файле /var/log/Xorg.0.log, переход на тестовые ветки ПО и прочее.
Полноценного решения в настоящее время нет. Но можно сделать следующее.
Откройте файл /etc/gdm/custom.conf:
В нём будет примерно следующее:
Закомментируйте строку, чтобы получилось:
Сохраните и закройте файл.
После этого один раз загрузка пройдёт нормально, но при второй и последующих загрузках всё вернётся на прежние места: экран входа не будет появляться и содержимое файла опять окажется прежним, с активной строкой WaylandEnable=false.
Чтобы этого избежать, измените файл (закомментируйте строку) и затем выполните команду:
Эта команда заблокирует файл от изменений.
Если вам вновь понадобится изменить этот файл, то выполните:
Wayland всё равно не работает
Строка «WaylandEnable=false» отключает Wayland и делает так, чтобы использовался x11. На самом деле, при любой настройке используется x11, вы можете проверить это командой:
Дело в том, что если не удаётся запустить Wayland, то запускается x11. Но настройка «WaylandEnable=false» по какой-то причине делает так, что не показывается экран входа.
Можно открыть этот файл и закомментировать указанную строку, в результате не будет автоматически меняться файл /etc/gdm/custom.conf. Но кардинально это ничего не поменяет — Wayland всё равно не запустится.
Смотреть как меняются ошибки в зависимости от опций загрузки можно командами:
Пользователи пишут, что данная проблема отсутствует на ядре 5.4 LTS. Видимо, всё дело в какой-то несовместимости последней версии ядра с ПО.
ОБНОВЛЕНИЕ
Проблема решилась. Получилось это так: после очередного обновления (обновился драйвер видеокарты и ядро) ИЛИ после удаления осиротевших пакетов, моя система вовсе перестала запускаться в графический интерфейс.
Причём X сервер запускался:
А GNOME Display Manager не запускался и при попытке перезапуска выдавал множество ошибок:
Я попытался удалить GNOME Display Manager и выяснилось, что этот пакет считается НЕ УСТАНОВЛЕННЫМ. Следовательно, он не мог быть обновлён, а также некоторые его зависимости были удалены как осиротевшие.
Я выполнил следующие команды для принудительной установки, полного удаления и чистой установки GNOME Display Manager:
Зависает Manjaro при запуске. Через раз. Когда нормально запускается, а когда зависает или перезагружается, при этом отключается монитор. Пробовал менять ядра не помогло.
Операционная система: Manjaro Linux, Версия KDE Plasma: 5.18.3, Версия KDE Frameworks: 5.68.0, Версия Qt: 5.14.1, Версия ядра: 5.6.0-1-MANJARO, Архитектура: 64-битная, Процессоры: 3 × AMD Athlon(tm) II X3 460 Processor, Память: 7,8 ГиБ ОЗУ
Что делать? Как определить в чем проблема?
Попробуй позапускать другой дистр, не Манджаро.
А на каком этапе зависает? Только при загрузке или бывает что и рандомно во время работы? Попробуй запустить с параметром memtest=2 , может память сбоит.
Пошарься в журнале. journalctl -b -1 покажет лог предыдущей загрузки.
Видеокарта и видеодрайвер какие?
Видяха, энергосбережение процессора, или бродкомовский вайфай. Это яаще всего встречалось.
Зависает только при загрузке системы. Если загрузиться работает нормально. Память тестировал сбоев не было.
Пробовал поставить Mint, так там так же!
Вот на этом обрывается лог Manjaro:
Как узнать какой видеодрайвер?
Вот на этом обрывается лог Manjaro:
Каждый раз на одном и том же месте?
Драйвер можно узнать из lspci -k и modinfo .
Лог иксов ещё посмотри.
Каждый раз на одном и том же месте?
вот лог другого зависания. место тоже.
Видео драйвер: VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] Subsystem: Micro-Star International Co., Ltd. [MSI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] Kernel driver in use: radeon Kernel modules: radeon
Попробуй как-то загрузиться в консоль, без иксов. Например, добавь к параметрам ядра systemd.unit=multi-user.target . Если всё ок, то, попробуй отключить видеодрайвер, и загрузиться нормально, с иксами. Чтобы отключить драйвер надо в параметры ядра записать module_blacklist=radeon .
Лог иксов не смотрел?
Запусти Artix с live-cd, arch без systemd и AppArmor
One ★★★★★ ( 07.04.20 18:35:37 )Последнее исправление: One 07.04.20 18:35:57 (всего исправлений: 1)
А как я его посмотрю? Когда загрузка зависает, не посмотришь. А когда нормально загружается, то он перезаписывается, и предыдущей загрузки там нет.
вот окончание файла Xorg при ошибке:
Запусти Artix с live-cd, arch без systemd и AppArmor
Скачал дистрибутив artix-plasma-s6-20200210-x86_64, записал на флешку. И там тоже самое, начинается загрузка, выключается монитор и зависает.
Server terminated successfully (0)
Не похоже на зависание. На другие консоли не переключается через Ctrl+Alt+F* ? На SysRq не реагирует? Нажми Alt+PrintScreen+b когда зависнет — должен выполнится хард ресет.
Пробовал без драйвера радеона? У тебя там на флешке, скорее всего, GRUB стоит сейчас. После загрузки его меню нажми e , чтобы отредактировать текущий пункт, и добавь к строке параметров тот, про который я выше писал. Потом F10 .
Когда зависнет на команды клавиатуры не реагирует. Тем более судя по логам он девайсы ввода отключает. Иногда бывает что сам перезагружается, когда как.
В строку параметров добавлял module_blacklist=radeon. Загружается всегда. Консоль работает. StartX не стартует, пишет ошибка, но тут Radeon отключен.
Получается что проблема связана с видео?
Да кто его знает, может и с видео. А может и с иксами. А может и сама карточка того. На винде работает?
У драйверов иногда бывают параметры с которыми можно поиграться. Чтобы узнать их список можно вызвать, например, modinfo radeon . Подробнее надо читать в документации к драйверу.
К параметрам ядра можно добавить loglevel=8 , чтобы побольше инфы в журнал писалось.
Покомпилять другие ядра уж не предлагаю, больно муторное это дело, да и какого-то результата навряд ли можно ожидать.
В качестве временного решения можно настроить иксы на работу без драйвера радеона, посмотри там в логе, чего им не хватает, когда загружаешься без драйвера.
В manjaro вроде другие ядра легко поставить, попробуй sudo pacman -S linux419 linux414 или как там команда, появится в пункте загрузке еще пара ядер.
Исключишь влияние, что не в LTS ядрах что-то у тебя сломали.
В manjaro вроде другие ядра легко поставить
Пробовал ставить ядра 5.4, 5.5, 5.6. Везде виснет. Думаю дело не в ядрах потому что я ставил Linux Mint там так же зависал, видимо везде используется один и тотже видеодрайвер, вот он и глючит. MSI Radeon R5 230 не самая популярная карта, может тестированию на ней уделили мало времени. Или есть какая-то особенность именно у этой MSI, например что у нее нет вентилятора и работает она на пассивном охлаждении.
Под Windows 10 карта работает нормально, никогда не глючила.
А может настройки acpi влияют. Может по разному оборудование настраивается? Как определить в каком месте ошибка?
Самым простым способом определить, где ошибка, наверное, будет вариант запостить багрепорт в багтрекер с максимальной информацией о системе и самыми детальными уровнями логов от ядра, драйвера и иксов.
Кстати, в том багтрекере (старой его версии) есть кое-что на твою тему. Посмотри вот эти репорты, может натолкнёт на какую-то мысль: 108361, 90926, 88364, 102820, 112192.
Ещё, я вижу, для твоей карты есть проприетарный драйвер Catalyst. В AUR’е есть для него PKGBUILD, но работает он, как я понял, только с ядрами <4.17. One, кстати, верно советует, попробовать поставить ядро постарше. В багтрекере в каком-то из репортов упоминалось, что с более старым ядром проблема исчезала. Правда какая это была проблема и в каком из репортов я уже найти не могу :) Возможно даже что это и не в тех, ссылки на которые я привёл.
Документации к драйверу ядра я что-то не могу найти.
Вот здесь ещё глянь, может в разделе Troubleshooting что-то есть.
Нашёл документацию, лол. Ничего интересного.
Try modinfo -p radeon to find up-to-date parameters. To check default values look at drivers/gpu/drm/radeon/radeon_drv.c or drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c in Linux kernel source. To check current values look at /sys/class/drm/card*/device/driver/module/holders/radeon/parameters/ or /sys/class/drm/card/device/driver/module/holders/amdgpu/parameters/*
Дефолтные значения параметров, если вдруг надо:
А как узнать за что эти параметры отвечают?
Например int radeon_msi = -1; Это что msi? У меня видюха тоже изготовлена msi. Это как то связано?
Пробовал убунту там тоже при загрузке через раз виснет. Везде один и тоже видеодрайвер что ли?
Вот логи при зависании системы во время загрузки.
Можете сказать что не так? Почему зависает?
Почитал твой лог загрузки. Какая-то дичь. Комп нормально загружается, без каких-то вопросов, потом уходит зачем-то в сон, потом просыпается и начинается какая-то котовасия. Заканчивается всё то ли перезагрузкой, то ли остановкой системы.
Ты там где-то посмотри, может в биосе, может ещё где-то можно выключить управление питанием через езернет. Либо NetworkManager как-то надо настроить, чтобы он не уводил комп в сон. К слову, NetworkManager тоже во все подряд дистры ставят. Попробуй совсем без него: systemctl disable NetworkManager . Сеть только надо будет поднастроить как-то. Но проверить гипотезу можно и без сети.
Лог иксов нормальный: Server terminated successfully (0) .
Узнать про параметры можно либо из исходников, либо спросив у автора драйвера, что за что там отвечает. Под MSI там, вероятно, имеется в виду это, а не имя производителя. И, судя по логам, у тебя в данный момент MSI включены:
modinfo radeon вкратце напишет тебе про параметры. Если захочешь запустить систему с какой-то опцией драйвера, то допиши к параметрам ядра в GRUB module.param=value ; например: radeon.test=1 .
Видеодрайвер — да, один. Точнее, видеодрайвер входит в состав ядра, которое во всех дистрибутивах одно и то же — Linux.
у тебя /var на отдельном разделе? мне показалось, что «да»…
у тебя /var на отдельном разделе? мне показалось, что «да»…
Нет. Я ничего не переносил. /var так.
Попробуй совсем без него: systemctl disable NetworkManager
Пробовал сетвую карту в биосе отключать. Виснет.
Почитал твой лог загрузки. Какая-то дичь. Комп нормально загружается, без каких-то вопросов, потом уходит зачем-то в сон, потом просыпается и начинается какая-то котовасия. Заканчивается всё то ли перезагрузкой, то ли остановкой системы.
Получается что по каким-то причинам комп в сон уходит при загрузке, а я думал что это видеодрайвер сбоит из-за чего монитор выключался. Как локализовать проблему то? В чем причина такого сбоя может быть?
эта «мелочь» может крови попить… возможно, стоит устранить это установкой haveged.
эта «мелочь» может крови попить… возможно, стоит устранить это установкой haveged.
Установил, все равно виснет при загрузке.
в логах всё то же самое или что-то поменялось?
в логах всё то же самое или что-то поменялось?
а я думал что это видеодрайвер
Опять же, когда ты отключаешь модуль видеокарты, комп не виснет. Но и до загрузки NetworkManager’а, я так понимаю, там тоже не доходит дело. И в тех логах, что ты привёл, такое поведение с внезапным уходом в сон встречается только однажды.
Попробуй ещё ACPI отключить: добавь к параметрам ядра acpi=off .
Есть ещё один способ «ловли блох»: оставить в компе минимально возможную конфигурацию оборудования, то есть отключить всё, без чего компьютер может загрузиться. Можно поотключать в биосе или просто повытаскивать из материнки лишние USB-устройства, диски, PCI-карточки и т.д. Оставить только самый минимум. И потом постепенно добавлять оборудование и загружаться. Но в твоём случае, как я понял, комп виснет не каждый раз, так что загружаться придётся не по разу.
Попробуй ещё ACPI отключить: добавь к параметрам ядра acpi=off.
отключить всё, без чего компьютер может загрузиться
Отключал юсб контроллер в биосе - виснет. Отключал сеть в биосе - виснет.
А вот когда прописывал module_blacklist=radeon, то до консоли грузился всегда.
Как еще можно локализовать проблему?
Ещё можно попробовать загрузиться пошагово, вручную. До multi-user.target , я так понимаю, грузится без проблем. Так вот дальше попробуй сам запустить каждый сервис по отдельности. Но для этого надо знать, что и когда запустить. Можно посмотреть как это делает systemd. А возможно у неё даже есть специальный режим на такой случай. Надо либо читать документацию, либо звать экспертов, типа Ивана.
Чтобы посмотреть все зависимости для дефолтной загрузки, надо выполнить systemctl list-dependencies default.target .
Либо можно без systemd попробовать из командной строки запустить xinit с каким-нибудь openbox’ом. Они весят: один — 80 килобайт, другой — 1.2 мегабайта. Если у тебя нет файла
/.xinitrc , то после установки xorg-xinit’а и openbox’а выполни один раз echo exec openbox >
/.xinitrc . Затем из консоли, которая будет после загрузки в multi-user.target , пиши startx и, по идее, должны будут загружаться иксы с оконным менеджером. Но в этом случае лог иксов надо будет искать в пользовательской директории, если он вдруг понадобится. Что-то типа
На 14 сек искажается экран. В как раз в этом месте виснет(иногда), но этого не видно когда видео драйвер стартует, потому что когда возникает ошибка монитор в спячку уходит.
Что это может быть за сбой на 14 сек. Почему вывод искажается?
видео не смотрел.
переключается на некорректный видеорежим. попробуй задать допустимый в параметрах ядра при загрузке.
переключается на некорректный видеорежим. попробуй задать допустимый в параметрах ядра при загрузке
Как тут задать видео режим? Именно в этот момент иногда происходит зависание. Такое впечатление что обращение в памяти по неправильному адресу.
Где в логах можно увидеть эту ситуацию?
в логах этого нет. как ядро/драйвер узнает, что обращается «по неправильному адресу»… упадёт? тогда будет бектрейс в dmesg.
сейчас посмотреть не могу, позже гляну… может неправильно сванговал…
Да это, скорее всего, тот же самый буфер, только отображённый с другим разрешением. В этом ничего страшного нет. Я не знаю как заставить иксы очищать буфер, поэтому предлагаю добавить к параметрам ядра systemd.show_status=0 , чтобы отключить отображение процесса загрузки в консоль :)
Ну может быть тот же буффер. Но странно что он не очищается при инициализации.
Прописал systemd.show_status=0 экран с искажениями исчез, но зависания остались.
Вот зависания происходят когда разрешение должно изменятся. Это в данный момент x стартует ? Там что то не так?
И еще если в логах видно что xorg сам завершается, то где найти причину по которой он так делает?
Он так делает, судя по логу, потому, что его просит об этом systemd и sddm.
Меня больше волнует почему комп уходит в сон во время загрузки. Это пока самый странный момент.
Попробуй дописать к параметрам ядра systemd.mask=sleep.target и systemd.mask=suspend.target (через запятую почему-то не работает, поэтому два раза systemd.mask= ). Если каждый раз неохота писать, то после удачной загрузки можно выполнить systemctl mask sleep.target suspend.target , но потом, когда проверишь сделай обратно, как было: systemctl unmask sleep.target suspend.target .
Попробуй дописать к параметрам ядра systemd.mask=sleep.target и systemd.mask=suspend.target (через запятую почему-то не работает, поэтому два раза systemd.mask=). Если каждый раз неохота писать, то после удачной загрузки можно выполнить systemctl mask sleep.target suspend.target
Он так делает, судя по логу, потому, что его просит об этом systemd и sddm. Меня больше волнует почему комп уходит в сон во время загрузки. Это пока самый странный момент.
Где то я читал что система может уходить в сон из-за сбоя что бы предотвратить худшие последствия. Это не точно, но кажется информация по этому поводу где то попадалась.
В как-то можно подробный лог видеодрайвер сделать?
Есть опция для модуля, чтобы включить тест: radeon.test=1 , но не знаю, насколько она действенная.
А есть у тебя другая видеокарточка или комп, из которого временно можно выдернуть карту? Попробуй подменить.
Насчёт «аварийного засыпания» — довольно странное поведение, так как оно ничем не помогает, да и в логе, думаю, это как-то бы отображалось более очевидным образом, нежели «Reached target Sleep. Starting Suspend…».
У него правильный драйвер. Пробовать надо module_blacklist=amdgpu.
У него правильный драйвер. Пробовать надо module_blacklist=amdgpu.
Попробовал. Виснет. Думаю что проблема не в выборе драйвера, а в его инициализации. Выбран правильно. Потому что если система стартует, то работает без проблем. Браузер работает, видео нормально воспроизводиться, нет глюков. Проблема именно в инициализации, она работает через раз. Возможно это баг в самом драйвере. А может что то еще. Может другое оборудование вызывает сбой.
Только как можно узнать точно где проблема?
А есть у тебя другая видеокарточка или комп, из которого временно можно выдернуть карту? Попробуй подменить.
Черный экран Manjaro застрял при загрузке. Решение проблем с драйвером видеокарты и источник конфигурации и установка метода ввода Sogou.
QAQ собственный оригинал или оригинал .
Эти два дня были установлены Манджаро, зашло много ям, и теперь я надеюсь помочь другим.
Кстати, IG World Champion действительно классный! !
Ξ В начале это была также самая болезненная проблема: она зависала во время установки, центральный процессор блокировался, а затем переключался по беспроводной сети. Это все банки с графической картой.
Вы можете столкнуться со следующими проблемами:
Решение: во-первых, вы должны войти в интерфейс установки:
- Когда загрузочный диск начнет видеть загрузочное меню, используйте клавиши со стрелками, чтобы перейти к столбцу BOOT.
- Нажмите E, чтобы войти в редактирование, будет driver=free Изменить на driver=intel
- И добавить xdriver=mesa acpi_osi=! acpi_osi="Windows 2009"
- Затем нажмите Ctrl + X или F10, чтобы начать.
При нормальных обстоятельствах вы можете войти в интерфейс установки, продолжить установку и перезапустить после установки, но в это время существует высокая вероятность того, что вы не сможете войти в систему и попасть в тупик.
- После входа в интерфейс grub перейдите к пункту запуска Manjaro, нажмите E, от второй до последней строки, найдите вполне, добавьте его после acpi_osi=! acpi_osi='Windows 2009' Нажмите F10 для плавного входа в систему.
- После входа в систему и изменения файла grub вы можете сначала решить проблему с видеокартой (в конечном итоге установить драйвер nvidia или Intel).
- Откройте терминал, sudo nano /boot/grub/grub.cfg
- найти linux /boot/vmlinuz-linux root=UUID=38bd539c-692f-44ea-85d6-2155f06f09fc rw quiet Эта строка примерно одинакова и может немного отличаться.
- Добавить после довольно xdriver=mesa acpi_osi=! acpi_osi="Windows 2009"
- Как это выглядит после добавления linux /boot/vmlinuz-linux root=UUID=38bd539c-692f-44ea-85d6-2155f06f09fc rw quiet xdriver=mesa acpi_osi=! acpi_osi="Windows 2009"
- Перезагрузка в порядке.
- Наконец, откройте менеджер настроек Manjaro и установите драйвер.
Автоустановить проприетарный драйвер можно ----------------------------------
SourceНастройте источник pacman:
$ sudo pacman-mirrors -i -c China -m rank
После всплывающего окна выберите несколько.
SourceНастройте источник archlinuxcn:
$ sudo nano /etc/pacman.conf
Добавьте следующее в конце:
$ sudo pacman -S archlinuxcn-keyring
Теперь вы можете скачать и установить желаемое программное обеспечение.
Чтобы облегчить установку большого количества программного обеспечения в aur, вы также можете установить yaourt
$ sudo pacman -S yaourt кажется, yaourt перестает развиваться, вы можете попробовать yay
MethodУстановите метод ввода Sogou:
$ sudo pacman -S fcitx-sogoupinyin
$ sudo pacman -S fcitx-im
$ sudo pacman -S fcitx-configtool
Измените файл конфигурации:
Добавьте следующее утверждение в конце:
После повторного входа в систему вы можете изменить метод ввода Sogou, нажав Ctrl + Пробел.
Я написал здесь на этот раз.
Покажите волну хорошего рабочего стола QAQ ----
Программное обеспечение: docky, conky
Учебное пособие было выполнено на недавно установленной системе Ubuntu, но оно должно быть применимо и в других случаях.
На днях я купил ноутбук Acer Predator (партнерская ссылка) для тестирования различных дистрибутивов Linux. Это громоздкий, тяжело сложенный ноутбук, который отличается от того, что мне нравятся небольшие легкие ноутбуки, такие как потрясающий Dell XPS.
Причиной, по которой я выбрал этот игровой ноутбук, хотя я не играю на ПК, является NVIDIA Graphics.
Acer Predator Helios 300 поставляется с NVIDIA Geforce GTX 1050Ti.
Поэтому, когда я решил приобрести новое специализированное устройство для тестирования дистрибутивов Linux, я выбрал ноутбук с графикой NVIDA.
Этот ноутбук поставляется с Windows 10, установленной на 120 ГБ SSD и 1 ТБ жесткого диска для хранения данных.
У меня дуалбут Windows 10 с Ubuntu 18.04.
Установка была быстрой, легкой и безболезненной.
Я загрузился в Ubuntu.
Она показывала знакомый фиолетовый экран, а потом я заметил, что он замерз.
Мышь не двигалась, я ничего не мог набрать, и ничего не мог сделать, кроме как выключить устройство, удерживая кнопку питания.
И это была та же история при следующей попытке входа в систему. Ubuntu просто застревает на фиолетовом экране, даже не дойдя до экрана входа в систему.
Звучит знакомо? Позвольте мне показать вам, как вы можете решить эту проблему с зависанием Ubuntu при входе в систему.
Не пользуетесь Ubuntu?
Обратите внимание, что хотя это руководство было выполнено с Ubuntu 18.04, оно также будет работать на других дистрибутивах на основе Ubuntu, таких как Linux Mint,elementary OS и т. д.
Исправление зависания Ubuntu во время загрузки из-за драйверов NVIDIA
Решение, которое я здесь опишу, работает для систем с графической картой NVIDIA.
Это потому, что ваша система зависает благодаря открытым драйверам NVIDIA Nouveau.
Без дальнейших задержек, давайте посмотрим, как решить эту проблему.
Шаг 1: Редактирование Grub
Когда вы загружаете свою систему, просто остановитесь на экране Grub, как показано ниже.
Если вы не видите этот экран, продолжайте удерживать клавишу Shift во время загрузки.
На этом экране нажмите клавишу «E», чтобы перейти в режим редактирования.
Вы должны увидеть код, подобный приведенному ниже.
Вы должны сосредоточиться на строке, которая начинается с Linux.
Шаг 2: Временное изменение параметров ядра Linux в Grub
Помните, что наша проблема с драйверами NVIDIA Graphics.
Эта несовместимость с открытой версией драйверов NVIDIA стала причиной проблемы, поэтому мы можем отключить эти драйверы.
Теперь есть несколько способов отключить эти драйверы.
Просто добавьте следующий текст в конце строки, начиная с Linux.
Вы должны быть в состоянии вводить данные.
Просто убедитесь, что вы добавляете этот текст в конце строки.
Теперь ваш экран должен выглядеть так:
Нажмите Ctrl + X или F10, чтобы сохранить изменения и выйти.
Теперь вы загрузитесь с недавно измененными параметрами ядра.
Если вы добавляете параметр nomodeset в ядро, он указывает ядру загружать видео / графические драйверы после запуска сервера дисплея.
Другими словами, вы отключили загрузку графического драйвера в это время, и конфликт, который он вызывал, исчез.
Шаг 3: Обновите вашу систему и установите проприетарные драйверы NVIDIA
Не будьте слишком счастливы только потому, что теперь вы можете войти в свою систему.
То, что вы сделали, было временным, и в следующий раз, когда вы загрузитесь в свою систему, ваша система все равно будет зависать, потому что она все равно будет пытаться загрузить драйверы Nouveau.
Значит ли это, что вам всегда придется редактировать ядро с экрана grub?
Здесь вы можете установить дополнительные драйверы в Ubuntu для NVIDIA.
Ubuntu не зависает во время загрузки при использовании этих проприетарных драйверов.
Я предполагаю, что это ваш первый вход в недавно установленную систему.
Это означает, что вы должны обновить Ubuntu, прежде чем делать что-либо еще.
Откройте терминал с помощью сочетания клавиш Ctrl + Alt + T в Ubuntu и используйте следующую команду:
Вы можете попробовать установить дополнительные драйверы в Ubuntu сразу после выполнения вышеупомянутой команды, но, по моему опыту, вам придется перезагрузить систему, прежде чем вы сможете успешно установить новые драйверы.
А при перезапуске вам придется снова изменить параметр ядра так же, как мы делали это раньше.
После обновления и перезапуска системы нажмите на поиск драйверов, чтобы перейти в меню и выполнить поиск программного обеспечения и обновлений.
Теперь перейдите на вкладку «Дополнительные драйверы» и подождите несколько секунд.
Здесь вы увидите проприетарные драйверы, доступные для вашей системы.
Вы должны увидеть драйвера NVIDIA в этом спискеь.
Выберите проприетарный драйвер и нажмите «Применить изменения».
Это займет некоторое время при установке новых драйверов.
Если в вашей системе включена безопасная загрузка UEFI, вас также попросят установить пароль.
Вы можете установить тот пароль, что легко запомнить.
Я покажу вам его последствия позже в шаге 4.
После завершения установки вам будет предложено перезагрузить систему, чтобы изменения вступили в силу.
Шаг 4: Работа с MOK (только для устройств с поддержкой UEFI Secure Boot)
Если вас попросят установить пароль безопасной загрузки, вы увидите синий экран, который говорит о «управлении MOK».
Это сложная тема, и я попытаюсь объяснить ее в более простых терминах.
MOK (Machine Owner Key) необходим из-за функции безопасной загрузки, которая требует подписи всех модулей ядра.
Ubuntu делает это для всех модулей ядра, которые поставляются в ISO.
Поскольку вы установили новый модуль (дополнительный драйвер) или внесли изменения в модули ядра, ваша защищенная система может воспринимать это как нежелательное / постороннее изменение в вашей системе и может отказаться от загрузки.
Следовательно, вы можете либо подписать модуль ядра самостоятельно (указав системе UEFI не паниковать, потому что вы внесли эти изменения), либо просто отключить безопасную загрузку.
Теперь, когда вы немного знаете о безопасной загрузке и MOK, давайте посмотрим, что делать при следующей загрузке, когда вы увидите синий экран при следующей загрузке.
Если вы выберете «Continue boot», скорее всего, ваша система загрузится как обычно, и вам вообще ничего не нужно будет делать.
Но возможно, что не все функции нового драйвера работают правильно.
Вот почему вы должны выбрать Enroll MOK.
Он попросит вас продолжить на следующем экране, а затем попросит пароль.
Используйте пароль, который вы установили при установке дополнительных драйверов на предыдущем шаге.
Вам будет предложено перезагрузить систему.
Шаг 5: Наслаждайтесь Ubuntu Linux с проприетарными драйверами NVIDIA
Как только новый драйвер будет установлен, вам придется перезапустить вашу систему снова.
Теперь все должно быть лучше, и вам больше не нужно редактировать параметры ядра.
Вы сразу загрузитесь в Ubuntu.
Я надеюсь, что это руководство помогло вам решить проблему зависания Ubuntu во время загрузки, и вы смогли загрузить систему Ubuntu.
Если у вас есть какие-либо вопросы или предложения, пожалуйста, дайте мне знать в разделе комментариев ниже.
31 thoughts on “ 🕓 Исправление зависания Ubuntu во время загрузки ”
Спасибо большое, ты просто нереально мне помог. Большооее тебе спасибо
Всегда пожалуйста! Приятно слышать
С наилучшими пожеланиями,
p.s. Картинки на сайте не могу приложить
Добрый день! Вы можете выложить листинг, когда провалились в настройки grub?
Предполагаю, что вам надо прокрутить вниз, чтобы добраться до нужной строки, которую нужно изменить.
В этом отличие.
Вот пролистал вниз и пишу:
linux bootvmlinuz-5.3/0-generic root=UUID=2970b0d2-3fdc\-40ed-9886-7146ef656861 ro quit rootfst vpe=ext4 libahci.ignore sss=1 raid=\noautodetect selinux=0 plvmouth.enable=0 lpi=11232000
И вот чуть ниже строка:
initrd /boot/initrd.img-5.3.0.-46-generic
nomodeset пробовали добавить?
Напишите пожалуйста в этом варианте в какое место это вставлять.
linux bootvmlinuz-5.3/0-generic root=UUID=2970b0d2-3fdc\-40ed-9886-7146ef656861 ro quit nomodeset
Добрый день! Я вчера всё выполнил, как ВЫ рекомендовали, при старте системы все иконки и шрифты были огромного размера, но после рестарта всё встало на свои места. Вечером при просмотре видео онлайн всё было нормально. Утром пришли обновления и в том числе и обновление ядра. После надо было перезагрузить систему. И потом уже при просмотре видео ролика на ютубе произошло зависание экрана, но звук продолжал работать. Комбинации разных вариантов клавишь просто не работали. Пришлось тупо выключить ноутбук. Вот как то так.
Добрый день! что показывает top и df -h ?
Вот то, что Вы просили про top и df -h
vladimir1956@vladimir1956-Satellite-A665:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19216 vladimi+ 20 0 1896008 348380 35960 R 67,3 4,3 119:21.82 terminal.e+
16298 vladimi+ 20 0 29484 12404 1972 R 51,8 0,2 88:51.73 wineserver
2410 vladimi+ 20 0 3919828 140956 76048 S 8,3 1,7 9:49.00 cinnamon
2011 root 20 0 609144 77116 55452 S 3,3 1,0 12:51.40 Xorg
3687 root 20 0 0 0 0 I 1,7 0,0 0:03.40 kworker/u1+
3995 vladimi+ 20 0 3928476 1,046g 128964 S 1,3 13,6 12:19.37 chromium-b+
4661 root 20 0 0 0 0 I 1,3 0,0 0:02.20 kworker/u1+
6320 vladimi+ 20 0 590828 35828 26184 S 1,3 0,4 0:00.97 gnome-term+
902 systemd+ 20 0 146112 3440 2876 S 0,7 0,0 0:00.09 systemd-ti+
6335 vladimi+ 20 0 46716 4200 3520 R 0,7 0,1 0:00.34 top
16320 vladimi+ 20 0 2022288 15488 13176 S 0,7 0,2 0:27.80 winedevice+
779 root -51 0 0 0 0 S 0,3 0,0 1:01.00 irq/39-iwl+
949 root 20 0 503224 11628 8756 S 0,3 0,1 0:21.63 udisksd
950 message+ 20 0 51348 5592 3956 S 0,3 0,1 0:06.20 dbus-daemon
2445 vladimi+ 20 0 661672 37520 29588 S 0,3 0,5 0:04.62 nm-applet
16307 vladimi+ 20 0 1946428 12080 10460 S 0,3 0,1 0:01.59 winedevice+
27453 root 20 0 0 0 0 I 0,3 0,0 0:03.24 kworker/7:+
$ df -h
Файл.система Размер Использовано Дост Использовано% Cмонтировано в
udev 3,9G 0 3,9G 0% /dev
tmpfs 790M 1,5M 788M 1% /run
/dev/sda1 440G 55G 362G 14% /
tmpfs 3,9G 50M 3,9G 2% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
tmpfs 790M 76K 790M 1% /run/user/1000
vladimir1956@vladimir1956-Satellite-A665:
Тут все ок. Сложно сказать причину
Может проблема в видео карте? У меня стоит NVIDIA. Может проблема в настройках именно видеокарты?
Посмотрите логи по времени появления проблем, так можно гадать бесконечно 🙂
Как посмотреть логи? Объсните подробнее, если не трудно!
/var/log/syslog или messages
Не совсем понятно с /var/log/syslog или messages? Эти команды набирать через командную строку или как? Если не трудно, объясните пожалуйста подробнее.
Администрация форума призывает всех пользователей писать правильно названия дистрибутивов, компаний, программ, термины и пр., а так же имена и фамилии.
Например: Arch, Debian, Fedora, Windows, AMD, Baobab, NVidia, , т.е. без транслитерации, а в именах и фамилиях давать её в скобках — Linus Torvalds (Линус Торвальдс)
Это обусловлено настройкой поисковиков по правильным названиям, которые облегчают наши же поиски информации в интернете.
1 Тема от Kamrad 2020-03-28 13:30:01 (2020-03-28 13:30:59 отредактировано Kamrad)
От нечего делать решил попробовать не очень симпатичную мне (из-за кучи разбросанных по разным местам настроек и неожиданных глюков) графическую оболочку KDE5 Plasma. И вот что получается - по непонятным причинам система (даже в Live-CD сессии) произвольно зависает намертво. Была мысль о возможной неисправности в оперативной памяти (а что ещё может "дурить" Live-CD режиме, без обращения к жёсткому диску ?) - поменял на другие "плашки" - благо свободного железа пока хватает - те же "нефаберже". Как тут не вспомнить старый одесский анекдот - "Ну не нрависся ты мне, не нрависся!!"
Операционная система - Mageia Linux 7.1, x64, Mate. Конфигурация - AMD FX-8350/ASUS SABERTOOTH 990FX/ASUS GTS-250 1 Gb/16 Gb RAM2 Ответ от algri14 2020-03-28 16:03:28
решил попробовать не очень симпатичную мне (из-за кучи разбросанных по разным местам настроек и неожиданных глюков) графическую оболочку KDE5 Plasma.
Сначала по поводу KDE5 Plasma — много шуму из ничего, лично меня прекрасно устраивало КДЕ4, но разработчики, следуя всеобщей волне улучшений, глядя на винду, решили создать Plasma. Но "лучшее может быть врагом хорошего", зарекомендованного временем, к тому же привычное окружение для юзера, со своими плюшками. Я не застал КДЕ3, но с ним была та же история - выкинули хорошее и добавили "лучшее", многих это взбесило, но толку то, разрабы "улучшают" чтобы "улучшать", не спрашивая пожеланий.
В итоги опять получили убогие свистелки, которые только напрягают ресурсы железа.
По поводу настроек — вот тут несогласен, они ВСЕ собраны в "Параметрах системы", хотя я назвал бы их "Параметры КДЕ или Plasma". Да, настроек там много, но они вполне понятны даже новичкам.
Про глюки — у меня только один. При сворачивании активного окна (вообще любой программы) оно иногда может самопроизвольно якобы раскрываться вновь, почему якобы, потому что на самом деле оно становится не активным, его невозможно ни свернуть, ни закрыть. Убирается кликом по значку в панели задач.
Имею предположение:
а) барахлит мышка, мог попасть кошачий волосок, частенько вытаскиваю их оттуда (беда характерная, если в доме животное)
б) систему обновлял, а не ставил заново, поэтому вполне возможны какие-то нестыковки после обновления, вот поэтому предпочитаю не обнолять ОСь, а устанавливать заново, конечно это намного трудозатратнее и по времени дольше, зато исключаются предыдущие наслоения ваших шаловливых ручек и экспериментов от чайника.
В остальном 7-ка намного лучше предыдущей версии, особенно вначале (вообще бесила своей недоработанностью). Но хоть и говорят, что в Магее пакеты стабильные, хорошо проверенные, я возражу, это не совсем так, попадаются программы с глюками, например ClamTk не запускался, какие-то библиотеки не работали с Tano, Conky Manager вообще не работает, например в Fedora с ним дела лучше (хотя тоже с проблемами).
Но в целом Mageia со своим КДЕ мне нравится больше, чем Fedora со своим. И вот название ДЕ одинаковое, а по факту много разных нюансов в пользу Mageia.
3 Ответ от Kamrad 2020-03-28 18:52:56 (2020-03-28 19:24:50 отредактировано Kamrad)
Самое забавное, что когда "подвешивается" система, то мышка работает, но ни графика, ни даже выход из графической оболочки путём жмаканья по клавиатуре, никаких последствий не имеют.
Да, на моей памяти, как говорил персонаж из "Властелина колец" Толкиена, прошли все три эпохи - появление KDE 2, с его аскетичным и удобным интерфейсом, потом KDE 3.5, ставшего более "гламурным", но приобредшим несколько врождённых дефектов, вырвиглазный шрифт в KDE4. А вообще моей любимой графической оболочкой был Gnome 2, пока разработчики не угробили его.
4 Ответ от algri14 2020-03-28 19:18:15
Kamrad, в соседней теме был разговор про жёсткие диски, точнее про штекеры, тоже самое могу добавить про ОЗУ и видеокарту.
Со временем окисливаются контакты, поэтому первым делом надо их протереть обыкновенной стирательной резинкой (но без фанатизма), далее спиртиком. И уже потом смотреть/сравнивать как работает системник. А то ведь исправное оборудование выбросишь.
Заодно почистить от пыли и заменить термопасту на процессоре.
5 Ответ от Kamrad 2020-03-28 19:23:50
Жёсткий проверял, осталась только видюха, воткну на пробу "офисную затычку" - Nvidia 710, попробую с ней ещё. Оперативная память новая - 16 Гб, тут проблем быть не должно.
Операционная система - Mageia Linux 7.1, x64, Mate. Конфигурация - AMD FX-8350/ASUS SABERTOOTH 990FX/ASUS GTS-250 1 Gb/16 Gb RAM6 Ответ от algri14 2020-03-29 06:22:29
в соседней теме был разговор про жёсткие диски, точнее про штекеры,
Штекеры SATA — имей ввиду, что они изначально коварны, потому как широкие и если некачественные, то контакта нет даже в новом.
7 Ответ от Kamrad 2020-03-29 11:30:41
Насчёт штекеров - согласен, но тут до них дело даже не доходит - как я уже сказал ранее, система зависает в Live-CD сессии, с флешки.
Операционная система - Mageia Linux 7.1, x64, Mate. Конфигурация - AMD FX-8350/ASUS SABERTOOTH 990FX/ASUS GTS-250 1 Gb/16 Gb RAM8 Ответ от algri14 2020-03-29 12:09:03
Насчёт штекеров - согласен, но тут до них дело даже не доходит
а флешка что, по WiFi подключается
Это я к тому, что надо полностью проверить железо и всякую мелочь пузатую.
Но с ней не хочется возиться, подумаешь там, фигня какая-то, по себе скажу - лень туда лезть и проверять досконально. Так было когда в моём системнике, в кнопке вкл/выкл сломался один(из двух) микровыключателей, целую неделю не мог понять в чём дело. Поверку начинал с программной части, пока на каком-то форуме случайно наткнулся на похожую проблему с кнопкой.
Ведь после 5 лет работы, оборудование склонно к окислению/поломке, оно ведь "железо", это не люди
9 Ответ от Kamrad 2020-03-29 12:40:40 (2020-03-29 12:43:19 отредактировано Kamrad)
Флешку втыкаю в порт "мамы", как бы. Ну что тут можно придумать. Сменить материнскую плату - вариант, но тут действительно срабатывает фактор лени - две другие "мамки" лежат в гараже, а тащиться туда желания нет. Подыхающая флешка? Была тыкая мыслЯ, запускал с другой (и другого порта) - эффекта не было. Ради спортивного интереса "закатал" даже на DVD и попробовал оттуда - "пациент скорее мёртв, чем жив": также зависает.
Операционная система - Mageia Linux 7.1, x64, Mate. Конфигурация - AMD FX-8350/ASUS SABERTOOTH 990FX/ASUS GTS-250 1 Gb/16 Gb RAM10 Ответ от kvv-vp 2020-03-30 10:14:46
причинам система (даже в Live-CD сессии) произвольно зависает намертво.
И что в этом необычного? Это нормальная стандартная ситуация для Live mageia и большинства других. Они не выгружаются полностью в память(даже при 64ГБ ОЗУ), а создают в озу виртуальную ФС куда и "устанавливают" дистрибутив, нужное ПО подгружается по необходимости. Поэтому и жуткие тормоза. Эти Live предназначены не для повседневной работы, а для ознакомления и восстановления. Дистрибутивы типа Puppy изначально разрабатываются для работы в озу, поэтому и работают быстро.
по непонятным причинам систем
В кде есть системный монитор, консольные "топы"( htop и другие). Ищите, что жрет ресурсы.
11 Ответ от kvv-vp 2020-03-30 10:27:01
соседней теме был разговор про жёсткие диски, точнее про штекеры,
Сейчас пайка в "проводах" почти нигде не используется, везде применяется "обжимка". Чтобы потерялся контакт, нужно приложить усилия.
12 Ответ от algri14 2020-03-30 16:26:32
Сейчас пайка в "проводах" почти нигде не используется, везде применяется "обжимка".
Пайка или обжимка в данном случае без разницы, ибо сам штекер имеет широкую конструкцию, а если пластмасс некачественный, то вместо параллельной формы он имеет вид вот этих скобок => () <= , отсюда получается, что в середине контакт плохой, либо его вовсе нет.
Иногда, овальный вид штекера видно даже на глаз, иногда он становится таким после какого-то времени, где покупать? совершенно не понятно, ведь всё из китая, лотерея
13 Ответ от sevo44 2020-04-18 21:18:41
КДЕ плавно помирает о чем свидетельствует отказ от его использования в официальной версии CentOS 8 и крайне хилая поддерка у других.
Переходите на другое, если не хотите получать ловину надвигающихся глюков.
Проще погасить свет чем разогнать тьму!
14 Ответ от algri14 2020-04-18 22:14:06
Да, у меня тоже подвисает и оборудование не при чём, приходится открытое окно программы дёргать в трей и обратно.
Хотя ещё может быть что-то с видеокартой.
15 Ответ от kvv-vp 2020-04-19 08:11:01
КДЕ плавно помирает о чем свидетельствует отказ от его использования в официальной версии CentOS 8 и крайне хилая поддерка у других.
Переходите на другое, если не хотите получать ловину надвигающихся глюков.
16 Ответ от kuguar 2020-04-19 10:13:01
100 раз пробовал КДЕ4 и КДЕ5, обязательно наступает момент когда я его сношу с нехорошими словами.
Перечислять все глюки - язык устанет. Погодный апплет, который съедает 100% оперативы, kshutdown который не выключает ноут, а при при нажатии Power ноут на секунду включается, после чего благополучно вырубается. Не говоря про эпическую битву дельфина с самбой.
Всё это напоминает раздолбанный москвич, у которого весь багажник забит запчастями и который надо всё время чинить.
Mageia 8 MATE, OpenSUSE Leap 15.3 MATE
17 Ответ от Kamrad 2020-04-19 13:02:24
Всё это напоминает раздолбанный москвич, у которого весь багажник забит запчастями и который надо всё время чинить.
Совершенно верно. Я уже неоднократно отмечал и ранее, что лично для меня KDE перестал существовать после версии 3.5 - хотя она была не без багов. Я сейчас пользуюсь Mate и Cinnamon, иногда - XFCE. Всё остальное - не моё.
Операционная система - Mageia Linux 7.1, x64, Mate. Конфигурация - AMD FX-8350/ASUS SABERTOOTH 990FX/ASUS GTS-250 1 Gb/16 Gb RAM18 Ответ от TopE 2020-04-19 14:25:36
kvv-vp, кеды не умерли, но напоминают сейчас какой-то хаос в плане разработки, направлений в разработке, движения одеяла то в одну, то в другую сторону и так далее. Именно потому редхат и забил на его поддержку в своих проектах, что в свою очередь отразилось на количественном составе сообщества, которые не захотели уходить с центоса федоры, рхел. Это снежный ком, который катится на кеды и ситуация ни как не улучшится в ближайшее время.
19 Ответ от algri14 2020-04-19 14:49:14
КДЕ в общем-то хорошее ДЕ, я не застал 3-ю версию, говорят было много полезных плюшек, но и 4-я была нормальная версия.
А вот 5-ю решили "улучшить" ещё сильнее, но все эти новомодные свистелки только убивают это ДЕ
20 Ответ от kvv-vp 2020-04-21 19:51:32
kvv-vp, кеды не умерли, но напоминают сейчас какой-то хаос в плане разработки, н
У меня "кеды" основной рабочий стол уже лет 10. Критичные изменения замечаю только при "мажорном" обновлении. Возможно, из-за того, что стараюсь не привязывать нужное ПО к рабочему столу и ОС в целом. Для меня цвет часов и наличие погодного виджета не критичны, всегда есть альтернатива. С самбой и расширениями виртуалбокс(собственно хостовой системы, а не гостевой) у меня также проблем нет.
Именно потому редхат и забил на его поддержку в своих проектах,
Да просто не хотят кормить конкурента. И, "редхат" это уже торговая марка, они уже ушли в историю, вслед за новелл и другими.
отразилось на количественном составе сообщества, к
CentOS позировался и использовался в, основном, как серверный дистрибутив, так что потеря не велика.
Это снежный ком, который катится на кеды и ситуация ни как не улучшится в ближайшее время.
В этом мире нельзя процветать без конкуренции, "кеды" получат нужную поддержку, возможно, даже с того же счета, но только уже от IBM.
Читайте также: