Ошибка юнита systemd-modules-load.service

2020-04-28-22:47:01_select

Ошибка юнита systemd-modules-load.service

Видели такое при старте системы и не можете понять в чем причина?

А приина в secureboot. Один из модулей ядра у вас не имеет цифровой подписи.

Чаще всего это происходит с модулями, которые собираются через akmod. Среди них virtualbox и nvidia (вроде amd тоже, но у меня нет возможности проверить). В последних релизах федоры что-то сломали и модули больше не подписываются при сборке.

where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT.

И что делать? Можно отключить secureboot?

Можно, но не нужно. Будете страдать от сообщения о несекурной загрузке.

  1. Создаем собственный ключ для подписи модулей и каталог, в котором это будет жить.
# mkdir /root/module-signing
# cd /root/module-signing
# openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=YOUR_NAME/"
# chmod 600 MOK.priv
  1. Регистрируем ключ в системе при помощи mokutils. Нам потребуется задать простой одноразовый пароль, который у нас спросят при перезагрузке.
# mokutil --import /root/module-signing/MOK.der
input password:
input password again:
  1. Перезагружаемся. Выбираем Enroll MOK. После выбираем единственный ключ и вводим пароль из шага выше.
  2. Пишем скрипт для подписания модулей. Помимо виртуалбокса туда можно добавить нужные вам записи.
#!/bin/bash

for modfile in $(dirname $(modinfo -n vboxdrv))/*.ko; do
  echo "Signing $modfile"
  /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \
                                /root/module-signing/MOK.priv \
                                /root/module-signing/MOK.der "$modfile"
done
  1. После обновления ядра\модуля\компонента запускаем скрипт выше, а потом перезагружаем модули.
# ./root/module-signing/sign-vbox-modules
Signing /lib/modules/5.6.6-200.fc31.x86_64/extra/VirtualBox/vboxdrv.ko
Signing /lib/modules/5.6.6-200.fc31.x86_64/extra/VirtualBox/vboxnetadp.ko
Signing /lib/modules/5.6.6-200.fc31.x86_64/extra/VirtualBox/vboxnetflt.ko
# systemctl restart systemd-modules-load.service

Источник

No Bootable Device после обновления дистрибутива

1 - no bootable deviceИменно таким неприятным сообщением может встретить вас ноутбук или стационарный компьютер после казалось бы удачно прошедшего обновления дистрибутива.

Почему? Потому что обновился grub-efi, а скрипт, который добавит запись о новом образе для загрузки не записал должным образом.

$ efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,2001,2002,2003
Boot0001* Linux	PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shimx64-fedora.efi)A01 ..
Boot0002* Unknown Device: 	HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)RC
Boot2001* EFI USB Device	RC
Boot2002* EFI DVD/CDROM	RC
Boot2003* EFI Network	RC

Увы, снять показания я смог только после восстановления работоспособности системы, поэтому на листинге, который приведен выше, мы видим корректный образ под меткой Boot0001 и тот, который был перед обновлением под меткой Boot0002. На разных системах это может выглядеть совершенно различным образом.

Что делать в случае, когда система совершенно не хочет загружаться?

Следует сделать несколько шагов для восстановления работоспособности (не стоит забывать, что для возможности расширенной работы с uefi на многих биосах должен быть установлен административный пароль — только тогда будут видны все элементы меню).

  • зайти в BIOS
  • найти пункт выбора доверенного uefi-файла
  • указать нужный файл на диске (в случае с fedora — это shimx64-fedora.efi)

 

Fedora перестает грузиться на UEFI после обновения (и показывает MOK)

Никогда бы не подумал, но вчера столкнулся с проблемой при которой после обновления fedora начисто отказалась загружаться постоянно выдавая при старте окно MokManager с просьбой добавить ключи или хеши с secureboot.

Что меня больше всего удивило так это то, что efibootmgr -v выдавал кучу записей загрузчиков shim.efi с некорректными uuid разделов на которых они размещены.

$ efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0007,0002,2001,2002,2003
Boot0000* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\Fedora\shim.efi)
Boot0001* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0002* Linux    PciRoot(0x0)/Pci(0x1c,0x4)/Pci(0x0,0x0)/NVMe(0x1,00-00-00-00-00-00-00-00)/HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\BOOT\BOOTX64.EFI)A01 ..
Boot0003* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0004* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0005* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0006* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot0007* Fedora    HD(1,GPT,f627bf87-5440-4997-8310-aa80dba7e383,0x800,0x64000)/File(\EFI\fedora\shim.efi)
Boot2001* EFI USB Device    RC
Boot2002* EFI DVD/CDROM    RC
Boot2003* EFI Network    RC

Конечно в данном листинге уже все верно поскольку он был сделан на рабочей машине, но в оригинальном листинге в идентификаторе HD были прописаны несуществующие uuid разделов. И подобных записей было далеко за 20 штук.

К сожалению мне неизвестна причина по которой система прописывает неверные данные, но мне нужно было оживить машину. Для этого следует сначала зайти в chroot окружение убитой системы.

Далее нам потребуется удалить все записи загрузчика с неверными данными. Это записи вида Boot0ХХХ.

Сначала надо переустановить grub-efi и shim как это рекомендует документация.

# dnf reinstall grub-efi shim

Теперь удаляем невалидные записи. Для их удаления нам потребуется выполнять команду

# efibootmgr -B -b XXXX
  • -B — удалить запись
  • -b XXXX — выбрать активной запись XXXX

В качестве XXXX будут выступать идентификаторы неугодных записей (не трогайте записи, которые начинаются не с нуля — они системные). И конечно же перед каждым удалением следите за состоянием записей (efibootmgr -v).

Последним шагом будет добавление правильной записи.

efibootmgr -c -w -L Fedora -d /dev/nvme0n1 -p 1 -l '\EFI\Fedora\shim.efi'
  • -c — создать запись
  • -w — сделать запись в mbr если это требуется
  • -L Fedora — метка новой записи в загрузчике
  • -d /dev/nvme0n1 — жесткий диск на котором размещен efi-раздел (у вас может быть /dev/sda или любой другой)
  • -p 1 — номер раздела на диске (если efi у вас это /dev/sda1, то 1, sda2 — 2 и т.д.)
  • -l ‘\EFI\Fedora\shim.efi’ — расположение файла загрузчика относительно корня диска efi (а не корня файловой системы в которую он подмонтирован). Обратите внимание, что тут нам обязательно надо указать загрузчик shim.efi, а не что-то другое.

После завершения можно перезагружаться и пробовать войти в систему. Mok Manager больше не должен появляться. Если это не так, то где-то вы допустили ошибку.

Литература