perform mok management что выбрать
Используем Secure Boot в Linux на всю катушку
Технология Secure Boot нацелена на предотвращение исполнения недоверенного кода при загрузке операционной системы, то есть защиту от буткитов и атак типа Evil Maid. Устройства с Secure Boot содержат в энергонезависимой памяти базу данных открытых ключей, которыми проверяются подписи загружаемых UEFI-приложений вроде загрузчиков ОС и драйверов. Приложения, подписанные доверенным ключом и с правильной контрольной суммой, допускаются к загрузке, остальные блокируются.
Более подробно о Secure Boot можно узнать из цикла статей от CodeRush.
Чтобы Secure Boot обеспечивал безопасность, подписываемые приложения должны соблюдать некоторый «кодекс чести»: не иметь в себе лазеек для неограниченного доступа к системе и параметрам Secure Boot, а также требовать того же от загружаемых ими приложений. Если подписанное приложение предоставляет возможность недобросовестного использования напрямую или путём загрузки других приложений, оно становится угрозой безопасности всех пользователей, доверяющих этому приложению. Такую угрозу представляют загрузчик shim, подписываемый Microsoft, и загружаемый им GRUB.
Чтобы от этого защититься, мы установим Ubuntu с шифрованием всего диска на базе LUKS и LVM, защитим initramfs от изменений, объединив его с ядром в одно UEFI-приложение, и подпишем его собственными ключами.
Ограничения решений «из коробки»
Ubuntu, как и другие распространённые дистрибутивы, предлагает опцию шифрования всего диска с LVM во время установки. Дистрибутив в такой конфигурации без ошибок устанавливается на UEFI с активным Secure Boot.
Но Canonical в первую очередь заинтересована в работоспособности ОС на устройствах с включённым Secure Boot, а не в обеспечении безопасности за счёт него. Если вы хотите использовать Secure Boot как средство безопасности, то вы сами по себе.
Как Ubuntu реализует загрузку в Secure Boot с шифрованием всего диска и что с этим не так?
Red Hat разработали загрузчик shim, чтобы он работал на всех устройствах и служил на благо человечеству, соблюдая строгие предписания стандарта Secure Boot и загружая только доверенные UEFI-приложения. Canonical использует shim как прокси, встраивая в него свой публичный ключ и подписывая у Microsoft. Shim загружает GRUB, подписанный ключём Canonical, который затем загружает ядро, подписанное Canonical.
Начнём с того, что шифруется не весь диск — /boot остаётся незашифрованным, а значит и initramfs в нём. Доступ к initramfs означает root-доступ. Fail.
GRUB должен верифицировать загружаемые ядра и отвергать неверно подписанные. Он этого не делает. Triple Fail.
Что это всё означает?
Согласно политике Microsoft о подписывании UEFI-приложений, все подписанные загрузчики GRUB и shim, используемые для загрузки GRUB, уже должны быть занесены в чёрный список.
Вывод
Необходимо отказаться от чужих ключей. Пользователь должен контролировать Secure Boot. Загрузчик должен быть подписан пользователем, все незашифрованные и доступные для записи элементы в загрузке системы должны верифицироваться. Пользовательские данные должны быть зашифрованы. Чего мы и попытаемся добиться.
Установка Ubuntu с шифрованием всего диска с помощью LUKS и LVM
LUKS — Linux Unified Key Setup — обёртка для криптографической системы dm-crypt, позволяющая создавать виртуальные зашифрованные устройства в файлах и на физических дисках. С помощью LUKS можно зашифровать данные на всём диске для того, чтобы перед загрузкой ОС требовалось ввести пароль.
LVM — Logical Volume Manager — менеджер логических томов, с помощью которого мы разделим криптоконтейнер на тома. Тома LVM автоматически монтируются после ввода пароля к криптоконтейнеру, отдельный ввод пароля для каждого тома не требуется.
Следующие инструкции должны быть применимы к любому дистрибутиву на базе Ubuntu, для других потребуются коррективы. Сперва загрузитесь с Live CD или установочного образа в режиме Try before installing.
Разметка и шифрование
Чтобы загружаться с диска в режиме UEFI, он должен быть размечен в формате GPT. Разметку диска рассмотрим с помощью KDE Partition Manager и GParted. Если у вас их нет, установите один, соответствующий вашей среде.
Запустите редактор разделов и выберите интересующий вас диск, обычно это первый в системе — /dev/sda. Посмотрите свойства диска.
В строке Partition table указана используемая таблица разделов. Если диск размечен в формате dos/msdos (MBR), то его необходимо преобразовать в GPT. Это возможно сделать без потери данных, но здесь я этого описывать не буду, поищите инструкции в интернете. Если на диске нет важных данных и вы хотите форматировать его в GPT, создайте новую таблицу.
На диске должен быть как минимум один раздел ESP (EFI System Partition), в котором будут храниться загрузчики. Если на этом диске установлена ОС в режиме UEFI, то один такой раздел уже есть. В любом случае я рекомендую создать новый размером не меньше 100 МБ. ESP должен быть отформатирован в один из FAT-форматов, предпочтительно в FAT32, а также помечен как загрузочный.
Дальше нужно создать раздел для шифрования. Тем же образом, что и ESP, только без форматирования (unformatted), выставления флагов и размером побольше — так, чтобы вместил систему и раздел подкачки. Создадим в этом разделе криптоконтейнер LUKS через терминал, предварительно перейдя в режим суперпользователя.
Подтвердите форматирование, написав YES, введите пароль. Теперь откройте криптоконтейнер (sda2_crypt — имя для маппинга) и введите тот же пароль.
Контейнер должен стать доступным как блочное устройство /dev/mapper/sda2_crypt. Перейдём к разметке логических томов внутри криптоконтейнера. Инициализируем физический раздел LVM поверх /dev/mapper/sda2_crypt.
Внутри этого физического раздела создадим группу томов с именем ubuntu.
Теперь мы можем создавать логические тома внутри этой группы. Первым делом создадим том для раздела подкачки и инициализируем его. Рекомендуемый размер — от sqrt(RAM) до 2xRAM в гигабайтах.
С разметкой закончено, можно перейти к установке.
Установка
Так как мы планируем создать загрузчик самостоятельно, да и установщик Ubuntu не поддерживает шифрование /boot, запустим установку без создания загрузчика.
На этапе разметки диска выберите Вручную.
Здесь нам необходимо указать точки монтирования. Выберите /dev/mapper/ubuntu-root, укажите использование в качестве журналируемой файловой системы Ext4, точку монтирования (Mount Point) в /, без форматирования. Ubiquity сама подхватит /dev/mapper/ubuntu-swap как раздел подкачки и запомнит один из системных разделов EFI. Экран разметки должен выглядеть так:
Закончите установку и не перезагружайтесь.
Настройка crypttab, fstab и resume
Вам необходимо вручную заполнить /etc/crypttab — файл, описывающий монтируемые при загрузке криптоконтейнеры.
В него нужно добавить запись о /dev/sda2, монтируемом в /dev/mapper/sda2_crypt. Настроим монтирование по UUID, а не по имени устройства. Чтобы узнать UUID /dev/sda2, откройте другой терминал и воспользуйтесь командой:
Проверьте, чтобы в /etc/fstab были правильно описаны монтируемые разделы, а в /etc/initramfs-tools/conf.d/resume указан раздел для пробуждения из гибернации.
После всех изменений обновите образ initramfs.
Создание загрузчика
Ядро Linux поддерживает загрузку напрямую из UEFI, если оно было скомпилировано с параметром CONFIG_EFI_STUB. В таком случае initramfs обычно хранится рядом в ESP, и путь к нему передаётся в аргументах к ядру.
Однако отсутствие верификации initramfs позволяет встроить в него вредоносный код, имея доступ на запись в ESP. Teddy Reed предлагает компилировать ядро, встраивая в него initramfs.
Процесс компиляции ядра достаточно длительный, её придётся производить после каждого изменения initramfs. К счастью, есть другой способ. В пакете systemd (ранее в gummiboot ) находится linuxx64.efi.stub — заготовка UEFI-приложения, в которую можно встроить ядро, initramfs и аргументы, передаваемые ядру. Подписав это UEFI-приложение, мы защитим ядро и initramfs от изменений.
Запишем в /tmp/cmdline аргументы, которые будут передаваться ядру.
В /boot хранятся образы ядра (vmlinuz-*-generic) и initramfs (initrd.img-*-generic). Определите последнюю версию и встройте их в заготовку.
Полученное UEFI-приложение ubuntu.efi необходимо расположить в ESP в каталоге EFI/BOOT/. Установщик Ubuntu должен был определить ESP и настроить монтирование в /boot/efi. Если в этом ESP нет других загрузчиков, то ubuntu.efi можно скопировать в /boot/efi/EFI/BOOT/BOOTX64.EFI, тогда он будет загружаться при выборе этого раздела в меню загрузки UEFI.
UPD: Если в вашу прошивку не встроен UEFI Shell, то скачать его можно отсюда. Положите его в EFI/BOOT/BOOTX64.EFI любого ESP и загружайтесь с отключённым Secure Boot. Чтобы добавить загрузочную запись, введите команду:
Спасибо Prototik за ссылку на UEFI Shell. Список остальных команд можно найти здесь.
Если у вас включён Secure Boot, то загрузиться с ubuntu.efi не получится, так как он не подписан. Временно отключите Secure Boot и загрузитесь, либо продолжите из chroot.
Настройка Secure Boot
Генерацию ключей, их установку в прошивку и подписывание UEFI-приложений описал CodeRush здесь, поэтому я буду считать, что вы всё понимаете и умеете.
Остаётся только подписать созданный нами загрузчик.
Поместите BOOTX64.EFI в каталог EFI/BOOT/ раздела EFI, с которого вы планируете загружаться.
Автоматизация
Чтобы загрузчик автоматически обновлялся и подписывался при обновлении initramfs, создайте скрипт update-efi-loader в /etc/initramfs/post-update.d/, изменив пути где требуется.
Дайте скрипту право на исполнение.
При обновлении ядра придётся произвести эту операцию вручную.
Подписывание драйверов и модулей ядра
Чтобы добавить этот сертификат в прошивку, его необходимо преобразовать в формат PEM, затем в ESL и подписать ключом KEK.
Очевидные советы
Если вашей задачей стоит защита данных на устройстве, то Secure Boot выполнит свою работу и не больше. Остальное возлагается на вас.
Не добавляйте чужих ключей в прошивку. Даже от Microsoft. В первую очередь от Microsoft.
Не подписывайте UEFI Shell, KeyTool или другие приложения, имеющие доступ к записи в NVRAM. Используйте их в Setup Mode.
Не оставляйте устройство включённым без присмотра. Устройство в ждущем режиме (suspend to RAM) содержит в RAM расшифрованные данные и мастер-ключи от криптоконтейнеров.
Установите пароль на UEFI Setup не проще, чем от вашего криптоконтейнера.
При физическом доступе к внутренностям устройства можно отключить Secure Boot, сбросив память NVRAM или повредив её, а также оставить хардварную закладку. Такая атака успешна только тогда, когда она незаметна. Сделайте так, чтобы вы о ней могли узнать: заклейте винты на корпусе трудновоспроизводимыми стикерами, обмажьте их лаком с блёстками. Опечатайте своё устройство.
Поставьте первым в списке загрузки неподписанное приложение. Если вы однажды не увидите сообщение от Secure Boot, то ваше устройство однозначно скомпрометировано.
Надёжнее отключённого от интернета устройства, хранимого в сейфе, всё равно ничего не придумаешь. Уязвимости в реализации Secure Boot в конкретных прошивках не исключены.
Бонус: возвращение гибернации
При шифровании всего диска вместо ждущего режима для сохранения состояния и продолжения работы с места остановки обычно используется гибернация, она же спящий режим или suspend to disk.
Из соображений безопасности разработчики ядра отключили возможность гибернации при включённом верифицировании модулей ядра. Аргументируется это тем, что образ восстановления не верифицируется при пробуждении, раздел подкачки может быть подменён и тогда система проснётся с непроверенным и потенциально вредоносным кодом.
Это верно в том случае, если initramfs не верифицируется и/или раздел подкачки не зашифрован. Однако независимо от использования гибернации при таких условиях initramfs может быть подменён, а чувствительные данные восстановлены из раздела подкачки. В нашей конфигурации initramfs верифицируется, будучи включённым в подписанный загрузочный файл, а раздел подкачки зашифрован. Значит, данное ограничение для нас бессмысленно.
Chung-Yi Lee ещё в 2013 предложил верифицировать образ восстановления, а в 2015 представил реализующий его идею патч. Но воз и ныне там. Поэтому предположим, что мы достаточно защищены с нашим шифрованием, и вернём нам гибернацию без верификации.
Способ 1. Отключить верификацию модулей ядра
Включённая верификация модулей ядра отключает гибернацию. По умолчанию верификация модулей ядра включается вместе с Secure Boot, однако она от Secure Boot не зависит. Её можно отключить, оставив только Secure Boot.
Большого ущерба безопасности это нанести не должно. Модули ядра устанавливаются из доверенного источника вместе с обновлением ядра и хранятся на зашифрованном диске и в верифицируемом initramfs. Сторонние драйвера устанавливаются вручную, и будут они подписаны нами или нет, значения не имеет, ведь мы им уже доверяем. SecureApt для ядра и TLS/HTTPS для сторонних драйверов должны защитить от MiTM, и тогда остаётся только root-доступ к расшифрованному диску. Но в таком случае у злоумышленника уже есть наши данные.
Введите пароль, который затем потребуется посимвольно подтвердить. Теперь нужно загрузиться через shim и выбрать в нём Change Secure Boot state (sic!). Поместите /usr/lib/shim.efi в EFI/BOOT/BOOTX64.EFI на одном из ESP или добавьте загрузочную запись через UEFI Shell. Предварительно отключите Secure Boot, после верните обратно.
UPD 12.01.17: Вместе с shim.efi необходимо сохранять рядом и MokManager. В последних версиях пакета shim.efi и MokManager располагаются в /usr/lib/shim/, shimx64.efi и mmx64.efi.signed соответственно. Нужно переименовать mmx64.efi.signed в mmx64.efi.
Сейчас Secure Boot и гибернация работают, UEFI-приложения верифицируются, но модули ядра нет.
В принципе, shim и mokutil больше не требуются, их можно удалить.
Способ 2. Использовать старую версию ядра
Патч, отключающий гибернацию, появился в версии Ubuntu-4.4.0-18.34. Ubuntu-4.4.0-17.33 должна быть от него свободна. Однако оставаться на старом ядре, игнорируя обновления безопасности, не лучший вариант.
Способ 3. Скомпилировать своё ядро
Если ваше время ничего не стоит, то вы можете скомпилировать своё ядро без этого ограничения. Гарантий, что после долгих мучений вы будете довольны результатом, нет. Но если вы этого очень хотите, хвала Линусу Торвальдсу и GPLv2, у вас есть на это право. Вы можете предварительно протестировать скомпилированное мною ядро, чтобы не тратить зря время.
Получение исходного кода
apt-get
Самый простой способ получить исходный код для ядра вашей версии — скачать его из репозитория.
В /etc/apt/sources.list должны присутствовать указатели на репозитории исходных кодов. Обычно там уже есть закомментированные записи с deb-src. Раскомментируйте их для репозиториев xenial main и xenial-security main, либо добавьте сами, а затем обновите индекс apt.
Загрузите исходный код и перейдите в создавшуюся директорию.
Обратите внимание на то, чтобы apt скачивал актуальную версию исходного кода. Проверьте номер версии у файла .dsc.
Если вы хотите поддерживать ядро в актуальном состоянии и перекомпилировать его по мере выхода обновлений с сохранением своих изменений, выберите git. Первоначальная загрузка займёт продолжительное время.
Создайте локальную копию git-репозитория ядра текущего релиза Ubuntu и перейдите в создавшуюся директорию.
Создайте ветку temp для тега, соответствующего вашей версии, и переключитесь на неё.
Настройка
Загрузите пакеты, требуемые для компиляции (build dependencies).
Убедитесь, что скриптам выставлено право на исполнение, запустите чистку.
Скопируйте старый файл конфигурации в текущую директорию, запустите конфигурацию, выберите Load и загрузите config. Больше изменять ничего не требуется, выйдите и сохраните конфигурацию — Exit → Yes.
Измените файл kernel/power/hibernate.c, убрав проверку secure_modules().
Подготовьте файл к коммиту.
Если вы ещё не совершали коммитов и не вводили свои данные, сделайте это сейчас.
Сделайте коммит, введите комментарий.
Теперь ваши изменения сохранены в новом снимке состояния (snapshot). Если вы захотите обновиться до следующей версии и применить к ней те же самые изменения, используйте git rebase
Скрипты компиляции определяют версию ядра по последней записи в истории изменений (changelog) в директории debian.master. Добавьте новую запись, чтобы изменить версию.
К версии будет добавлен суффикс custom1, что отразится при сборке пакетов .deb и позволит установить их при уже установленных пакетах той же версии без суффикса. Однако этот суффикс распространяется только на имя пакета, но не на его содержимое: ядро и директория с его модулями будут иметь ту же версию 4.4.0-34-generic, и при установке старые файлы перезапишутся новыми. Чтобы этого избежать, измените версию ABI c 34 на, например, 3400.
Компиляция
Запустите чистку ещё раз и скомпилируйте ядро. Если вы не опытный разработчик ядра и не понимаете, как работают проверки ABI и модулей (я вот не понимаю), отключите их (skipabi=true, skipmodule=true), иначе ваша компиляция сломается на одном из последних этапов. Здесь используется многопоточная сборка пакетов с количеством потоков, равным количеству ядер процессора. Цель binary-generic означает компиляцию обычной разновидности ядра, архитектура определяется автоматически.
Снова соберите загрузочный файл.
Гибернация работает, но нестабильно. Как, впрочем, и без Secure Boot.
Способ 4. Отказ от гибернации и использование виртуализации
Если гибернация и работает, то это не делает её надёжным средством сохранения состояния. Это может быть проблемой моего железа, дистрибутива или, что более вероятно, KDE Plasma, но у меня Kubuntu просыпается через раз.
С большей надёжностью придёт и большая защищённость: чувствительные данные можно изолировать от опасной среды. Браузер и песочница для установки стороннних пакетов в одной виртуальной машине, важные персональные данные — в другой. Украсть мастер-ключ от зашифрованного диска в памяти хостовой ОС из гостевой гораздо сложнее. Кажется, для подобного существует Qubes OS. Но она данный момент не поддерживает Secure Boot. Fail.
На этом всё, приветствуются любые дополнения и замечания.
Примечания
↑ Теоретически можно исправить, установив пароль, встроив grub.cfg в образ GRUB с помощью grub-mkstandalone и установив в grub.cfg prefix на невалидный путь, чтобы GRUB не мог найти второй grub.cfg на диске. Но опять же требуется подписывать образ самостоятельно.
↑ А он есть у всех кроме параноиков оправданно озабоченных своей безопасностью пользователей.
↑ У меня загрузиться с USB не даёт. Windows 8 и 10 также без пароля не пускают в безопасный режим или консоль.
↑ Говорят, некоторые прошивки он окирпичивает. Безопаснее создать по ESP на каждый загрузчик.
🕓 Исправление зависания Ubuntu во время загрузки
В этом пошаговом руководстве показано, как справиться с зависанием Ubuntu при загрузке, установив проприетарные драйверы NVIDIA.
Учебное пособие было выполнено на недавно установленной системе Ubuntu, но оно должно быть применимо и в других случаях.
На днях я купил ноутбук Acer Predator (партнерская ссылка) для тестирования различных дистрибутивов Linux. Это громоздкий, тяжело сложенный ноутбук, который отличается от того, что мне нравятся небольшие легкие ноутбуки, такие как потрясающий Dell XPS.
Причиной, по которой я выбрал этот игровой ноутбук, хотя я не играю на ПК, является NVIDIA Graphics.
Acer Predator Helios 300 поставляется с NVIDIA Geforce GTX 1050Ti.
NVIDIA известна своей плохой совместимостью с Linux. Некоторые читатели It FOSS попросили меня помочь с их ноутбуками NVIDIA, и я ничего не мог сделать, потому что у меня не было системы с графической картой NVIDIA.
Поэтому, когда я решил приобрести новое специализированное устройство для тестирования дистрибутивов 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 стала причиной проблемы, поэтому мы можем отключить эти драйверы.
Теперь есть несколько способов отключить эти драйверы.
Мой любимый способ – отключить все видео / видеокарты с помощью nomodeset.
Просто добавьте следующий текст в конце строки, начиная с 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 во время загрузки ”
Спасибо большое, ты просто нереально мне помог. Большооее тебе спасибо
Всегда пожалуйста! Приятно слышать
Прочитал на Вашей странице про зависание экрана:
https://itisgood.ru/2019/04/09/ispravlenie-zavisanija-ubuntu-vo-vremja-zagruzki/
и стал делать так, как у Вас написано: нажимал на клавишу SHIFT при
старте, но у менясовсем другое(картинки прикладываю). Подскажите
пожалуста, как избавиться от зависания экрана в моём случае.
С наилучшими пожеланиями,
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 – 12:42:51 up 4:43, 1 user, load average: 1,72, 1,54, 1,53
Tasks: 250 total, 3 running, 174 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4,7 us, 7,6 sy, 0,0 ni, 86,8 id, 0,0 wa, 0,0 hi, 1,0 si, 0,0 st
КиБ Mem : 8081484 total, 2434240 free, 2786848 used, 2860396 buff/cache
КиБ Swap: 2097148 total, 2097148 free, 0 used. 4937280 avail Mem
Тут все ок. Сложно сказать причину
Может проблема в видео карте? У меня стоит NVIDIA. Может проблема в настройках именно видеокарты?
Посмотрите логи по времени появления проблем, так можно гадать бесконечно 🙂
Как посмотреть логи? Объсните подробнее, если не трудно!
/var/log/syslog или messages
Не совсем понятно с /var/log/syslog или messages? Эти команды набирать через командную строку или как? Если не трудно, объясните пожалуйста подробнее.