]>
Commit | Line | Data |
---|---|---|
93f6b84a SI |
1 | [[sysboot]] |
2 | Host Bootloader | |
3 | --------------- | |
93f6b84a | 4 | |
8378a1eb | 5 | {pmg} currently uses one of two bootloaders depending on the disk setup |
93f6b84a SI |
6 | selected in the installer. |
7 | ||
8 | For EFI Systems installed with ZFS as the root filesystem `systemd-boot` is | |
9 | used, unless Secure Boot is enabled. All other deployments use the standard | |
10 | GRUB bootloader (this usually also applies to systems which are installed on | |
11 | top of Debian). | |
12 | ||
13 | ||
14 | [[sysboot_installer_part_scheme]] | |
15 | Partitioning Scheme Used by the Installer | |
16 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
17 | ||
8378a1eb | 18 | The {pmg} installer creates 3 partitions on all disks selected for |
93f6b84a SI |
19 | installation. |
20 | ||
21 | The created partitions are: | |
22 | ||
23 | * a 1 MB BIOS Boot Partition (gdisk type EF02) | |
24 | ||
25 | * a 512 MB EFI System Partition (ESP, gdisk type EF00) | |
26 | ||
27 | * a third partition spanning the set `hdsize` parameter or the remaining space | |
28 | used for the chosen storage type | |
29 | ||
30 | Systems using ZFS as root filesystem are booted with a kernel and initrd image | |
31 | stored on the 512 MB EFI System Partition. For legacy BIOS systems, and EFI | |
32 | systems with Secure Boot enabled, GRUB is used, for EFI systems without | |
33 | Secure Boot, `systemd-boot` is used. Both are installed and configured to point | |
34 | to the ESPs. | |
35 | ||
36 | GRUB in BIOS mode (`--target i386-pc`) is installed onto the BIOS Boot | |
37 | Partition of all selected disks on all systems booted with GRUB | |
38 | footnote:[These are all installs with root on `ext4` or `xfs` and installs | |
39 | with root on ZFS on non-EFI systems]. | |
40 | ||
41 | ||
42 | [[sysboot_proxmox_boot_tool]] | |
43 | Synchronizing the content of the ESP with `proxmox-boot-tool` | |
44 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
45 | ||
46 | `proxmox-boot-tool` is a utility used to keep the contents of the EFI System | |
47 | Partitions properly configured and synchronized. It copies certain kernel | |
48 | versions to all ESPs and configures the respective bootloader to boot from | |
49 | the `vfat` formatted ESPs. In the context of ZFS as root filesystem this means | |
50 | that you can use all optional features on your root pool instead of the subset | |
51 | which is also present in the ZFS implementation in GRUB or having to create a | |
52 | separate small boot-pool footnote:[Booting ZFS on root with GRUB | |
53 | https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS]. | |
54 | ||
55 | In setups with redundancy all disks are partitioned with an ESP, by the | |
56 | installer. This ensures the system boots even if the first boot device fails | |
57 | or if the BIOS can only boot from a particular disk. | |
58 | ||
59 | The ESPs are not kept mounted during regular operation. This helps to prevent | |
60 | filesystem corruption to the `vfat` formatted ESPs in case of a system crash, | |
61 | and removes the need to manually adapt `/etc/fstab` in case the primary boot | |
62 | device fails. | |
63 | ||
64 | `proxmox-boot-tool` handles the following tasks: | |
65 | ||
66 | * formatting and setting up a new partition | |
67 | * copying and configuring new kernel images and initrd images to all listed ESPs | |
68 | * synchronizing the configuration on kernel upgrades and other maintenance tasks | |
69 | * managing the list of kernel versions which are synchronized | |
70 | * configuring the boot-loader to boot a particular kernel version (pinning) | |
71 | ||
72 | ||
73 | You can view the currently configured ESPs and their state by running: | |
74 | ||
75 | ---- | |
76 | # proxmox-boot-tool status | |
77 | ---- | |
78 | ||
79 | [[sysboot_proxmox_boot_setup]] | |
80 | .Setting up a new partition for use as synced ESP | |
81 | ||
82 | To format and initialize a partition as synced ESP, e.g., after replacing a | |
83 | failed vdev in an rpool, or when converting an existing system that pre-dates | |
84 | the sync mechanism, `proxmox-boot-tool` from `proxmox-kernel-helper` can be used. | |
85 | ||
86 | WARNING: the `format` command will format the `<partition>`, make sure to pass | |
87 | in the right device/partition! | |
88 | ||
89 | For example, to format an empty partition `/dev/sda2` as ESP, run the following: | |
90 | ||
91 | ---- | |
92 | # proxmox-boot-tool format /dev/sda2 | |
93 | ---- | |
94 | ||
95 | To setup an existing, unmounted ESP located on `/dev/sda2` for inclusion in | |
8378a1eb | 96 | {pmg}'s kernel update synchronization mechanism, use the following: |
93f6b84a SI |
97 | |
98 | ---- | |
99 | # proxmox-boot-tool init /dev/sda2 | |
100 | ---- | |
101 | ||
102 | or | |
103 | ||
104 | ---- | |
105 | # proxmox-boot-tool init /dev/sda2 grub | |
106 | ---- | |
107 | ||
108 | to force initialization with GRUB instead of `systemd-boot`, for example for | |
109 | Secure Boot support. | |
110 | ||
111 | Afterwards `/etc/kernel/proxmox-boot-uuids` should contain a new line with the | |
112 | UUID of the newly added partition. The `init` command will also automatically | |
113 | trigger a refresh of all configured ESPs. | |
114 | ||
115 | [[sysboot_proxmox_boot_refresh]] | |
116 | .Updating the configuration on all ESPs | |
117 | ||
118 | To copy and configure all bootable kernels and keep all ESPs listed in | |
119 | `/etc/kernel/proxmox-boot-uuids` in sync you just need to run: | |
120 | ||
121 | ---- | |
122 | # proxmox-boot-tool refresh | |
123 | ---- | |
124 | (The equivalent to running `update-grub` systems with `ext4` or `xfs` on root). | |
125 | ||
126 | This is necessary should you make changes to the kernel commandline, or want to | |
127 | sync all kernels and initrds. | |
128 | ||
129 | NOTE: Both `update-initramfs` and `apt` (when necessary) will automatically | |
130 | trigger a refresh. | |
131 | ||
132 | .Kernel Versions considered by `proxmox-boot-tool` | |
133 | The following kernel versions are configured by default: | |
134 | ||
135 | * the currently running kernel | |
136 | * the version being newly installed on package updates | |
137 | * the two latest already installed kernels | |
138 | * the latest version of the second-to-last kernel series (e.g. 5.0, 5.3), if applicable | |
139 | * any manually selected kernels | |
140 | ||
141 | .Manually keeping a kernel bootable | |
142 | ||
143 | Should you wish to add a certain kernel and initrd image to the list of | |
144 | bootable kernels use `proxmox-boot-tool kernel add`. | |
145 | ||
146 | For example run the following to add the kernel with ABI version `5.0.15-1-pve` | |
147 | to the list of kernels to keep installed and synced to all ESPs: | |
148 | ||
149 | ---- | |
150 | # proxmox-boot-tool kernel add 5.0.15-1-pve | |
151 | ---- | |
152 | ||
153 | `proxmox-boot-tool kernel list` will list all kernel versions currently selected | |
154 | for booting: | |
155 | ||
156 | ---- | |
157 | # proxmox-boot-tool kernel list | |
158 | Manually selected kernels: | |
159 | 5.0.15-1-pve | |
160 | ||
161 | Automatically selected kernels: | |
162 | 5.0.12-1-pve | |
163 | 4.15.18-18-pve | |
164 | ---- | |
165 | ||
166 | Run `proxmox-boot-tool kernel remove` to remove a kernel from the list of | |
167 | manually selected kernels, for example: | |
168 | ||
169 | ---- | |
170 | # proxmox-boot-tool kernel remove 5.0.15-1-pve | |
171 | ---- | |
172 | ||
173 | NOTE: It's required to run `proxmox-boot-tool refresh` to update all EFI System | |
174 | Partitions (ESPs) after a manual kernel addition or removal from above. | |
175 | ||
176 | ||
177 | [[sysboot_determine_bootloader_used]] | |
178 | Determine which Bootloader is Used | |
179 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
180 | ||
38d14519 | 181 | [thumbnail="screenshot/boot-grub.png", float="left"] |
93f6b84a SI |
182 | |
183 | The simplest and most reliable way to determine which bootloader is used, is to | |
8378a1eb | 184 | watch the boot process of the {pmg} node. |
93f6b84a SI |
185 | |
186 | You will either see the blue box of GRUB or the simple black on white | |
187 | `systemd-boot`. | |
188 | ||
38d14519 | 189 | [thumbnail="screenshot/boot-systemdboot.png"] |
93f6b84a SI |
190 | |
191 | Determining the bootloader from a running system might not be 100% accurate. The | |
192 | safest way is to run the following command: | |
193 | ||
194 | ||
195 | ---- | |
196 | # efibootmgr -v | |
197 | ---- | |
198 | ||
199 | If it returns a message that EFI variables are not supported, GRUB is used in | |
200 | BIOS/Legacy mode. | |
201 | ||
202 | If the output contains a line that looks similar to the following, GRUB is | |
203 | used in UEFI mode. | |
204 | ||
205 | ---- | |
206 | Boot0005* proxmox [...] File(\EFI\proxmox\grubx64.efi) | |
207 | ---- | |
208 | ||
209 | If the output contains a line similar to the following, `systemd-boot` is used. | |
210 | ||
211 | ---- | |
212 | Boot0006* Linux Boot Manager [...] File(\EFI\systemd\systemd-bootx64.efi) | |
213 | ---- | |
214 | ||
215 | By running: | |
216 | ||
217 | ---- | |
218 | # proxmox-boot-tool status | |
219 | ---- | |
220 | ||
221 | you can find out if `proxmox-boot-tool` is configured, which is a good | |
222 | indication of how the system is booted. | |
223 | ||
224 | ||
225 | [[sysboot_grub]] | |
226 | GRUB | |
227 | ~~~~ | |
228 | ||
229 | GRUB has been the de-facto standard for booting Linux systems for many years | |
230 | and is quite well documented | |
231 | footnote:[GRUB Manual https://www.gnu.org/software/grub/manual/grub/grub.html]. | |
232 | ||
233 | Configuration | |
234 | ^^^^^^^^^^^^^ | |
235 | Changes to the GRUB configuration are done via the defaults file | |
236 | `/etc/default/grub` or config snippets in `/etc/default/grub.d`. To regenerate | |
237 | the configuration file after a change to the configuration run: | |
238 | footnote:[Systems using `proxmox-boot-tool` will call `proxmox-boot-tool | |
239 | refresh` upon `update-grub`.] | |
240 | ||
241 | ---- | |
242 | # update-grub | |
243 | ---- | |
244 | ||
245 | ||
246 | [[sysboot_systemd_boot]] | |
247 | Systemd-boot | |
248 | ~~~~~~~~~~~~ | |
249 | ||
250 | `systemd-boot` is a lightweight EFI bootloader. It reads the kernel and initrd | |
251 | images directly from the EFI Service Partition (ESP) where it is installed. | |
252 | The main advantage of directly loading the kernel from the ESP is that it does | |
8378a1eb | 253 | not need to reimplement the drivers for accessing the storage. In {pmg} |
93f6b84a SI |
254 | xref:sysboot_proxmox_boot_tool[`proxmox-boot-tool`] is used to keep the |
255 | configuration on the ESPs synchronized. | |
256 | ||
257 | [[sysboot_systemd_boot_config]] | |
258 | Configuration | |
259 | ^^^^^^^^^^^^^ | |
260 | ||
261 | `systemd-boot` is configured via the file `loader/loader.conf` in the root | |
262 | directory of an EFI System Partition (ESP). See the `loader.conf(5)` manpage | |
263 | for details. | |
264 | ||
265 | Each bootloader entry is placed in a file of its own in the directory | |
266 | `loader/entries/` | |
267 | ||
268 | An example entry.conf looks like this (`/` refers to the root of the ESP): | |
269 | ||
270 | ---- | |
271 | title Proxmox | |
272 | version 5.0.15-1-pve | |
8378a1eb | 273 | options root=ZFS=rpool/ROOT/pmg-1 boot=zfs |
93f6b84a SI |
274 | linux /EFI/proxmox/5.0.15-1-pve/vmlinuz-5.0.15-1-pve |
275 | initrd /EFI/proxmox/5.0.15-1-pve/initrd.img-5.0.15-1-pve | |
276 | ---- | |
277 | ||
278 | ||
279 | [[sysboot_edit_kernel_cmdline]] | |
280 | Editing the Kernel Commandline | |
281 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
282 | ||
283 | You can modify the kernel commandline in the following places, depending on the | |
284 | bootloader used: | |
285 | ||
286 | .GRUB | |
287 | ||
288 | The kernel commandline needs to be placed in the variable | |
289 | `GRUB_CMDLINE_LINUX_DEFAULT` in the file `/etc/default/grub`. Running | |
290 | `update-grub` appends its content to all `linux` entries in | |
291 | `/boot/grub/grub.cfg`. | |
292 | ||
293 | .Systemd-boot | |
294 | ||
295 | The kernel commandline needs to be placed as one line in `/etc/kernel/cmdline`. | |
296 | To apply your changes, run `proxmox-boot-tool refresh`, which sets it as the | |
297 | `option` line for all config files in `loader/entries/proxmox-*.conf`. | |
298 | ||
299 | A complete list of kernel parameters can be found at | |
300 | 'https://www.kernel.org/doc/html/v<YOUR-KERNEL-VERSION>/admin-guide/kernel-parameters.html'. | |
301 | replace <YOUR-KERNEL-VERSION> with the major.minor version, for example, for | |
302 | kernels based on version 6.5 the URL would be: | |
303 | https://www.kernel.org/doc/html/v6.5/admin-guide/kernel-parameters.html | |
304 | ||
305 | You can find your kernel version by checking the web interface ('Node -> | |
306 | Summary'), or by running | |
307 | ||
308 | ---- | |
309 | # uname -r | |
310 | ---- | |
311 | ||
312 | Use the first two numbers at the front of the output. | |
313 | ||
314 | [[sysboot_kernel_pin]] | |
315 | Override the Kernel-Version for next Boot | |
316 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
317 | ||
318 | To select a kernel that is not currently the default kernel, you can either: | |
319 | ||
320 | * use the boot loader menu that is displayed at the beginning of the boot | |
321 | process | |
322 | * use the `proxmox-boot-tool` to `pin` the system to a kernel version either | |
323 | once or permanently (until pin is reset). | |
324 | ||
325 | This should help you work around incompatibilities between a newer kernel | |
326 | version and the hardware. | |
327 | ||
328 | NOTE: Such a pin should be removed as soon as possible so that all current | |
329 | security patches of the latest kernel are also applied to the system. | |
330 | ||
331 | For example: To permanently select the version `5.15.30-1-pve` for booting you | |
332 | would run: | |
333 | ||
334 | ---- | |
335 | # proxmox-boot-tool kernel pin 5.15.30-1-pve | |
336 | ---- | |
337 | ||
8378a1eb | 338 | TIP: The pinning functionality works for all {pmg} systems, not only those using |
93f6b84a SI |
339 | `proxmox-boot-tool` to synchronize the contents of the ESPs, if your system |
340 | does not use `proxmox-boot-tool` for synchronizing you can also skip the | |
341 | `proxmox-boot-tool refresh` call in the end. | |
342 | ||
343 | You can also set a kernel version to be booted on the next system boot only. | |
344 | This is for example useful to test if an updated kernel has resolved an issue, | |
345 | which caused you to `pin` a version in the first place: | |
346 | ||
347 | ---- | |
348 | # proxmox-boot-tool kernel pin 5.15.30-1-pve --next-boot | |
349 | ---- | |
350 | ||
351 | To remove any pinned version configuration use the `unpin` subcommand: | |
352 | ||
353 | ---- | |
354 | # proxmox-boot-tool kernel unpin | |
355 | ---- | |
356 | ||
357 | While `unpin` has a `--next-boot` option as well, it is used to clear a pinned | |
358 | version set with `--next-boot`. As that happens already automatically on boot, | |
359 | invonking it manually is of little use. | |
360 | ||
361 | After setting, or clearing pinned versions you also need to synchronize the | |
362 | content and configuration on the ESPs by running the `refresh` subcommand. | |
363 | ||
364 | TIP: You will be prompted to automatically do for `proxmox-boot-tool` managed | |
365 | systems if you call the tool interactively. | |
366 | ||
367 | ---- | |
368 | # proxmox-boot-tool refresh | |
369 | ---- | |
370 | ||
371 | [[sysboot_secure_boot]] | |
372 | Secure Boot | |
373 | ~~~~~~~~~~~ | |
374 | ||
8378a1eb | 375 | Since {pmg} 8.1, Secure Boot is supported out of the box via signed packages |
93f6b84a SI |
376 | and integration in `proxmox-boot-tool`. |
377 | ||
378 | The following packages need to be installed for Secure Boot to be enabled: | |
379 | ||
380 | - `shim-signed` (shim bootloader signed by Microsoft) | |
381 | - `shim-helpers-amd64-signed` (fallback bootloader and MOKManager, signed by | |
382 | Proxmox) | |
383 | - `grub-efi-amd64-signed` (GRUB EFI bootloader, signed by Proxmox) | |
384 | - `proxmox-kernel-6.X.Y-Z-pve-signed` (Kernel image, signed by Proxmox) | |
385 | ||
386 | Only GRUB as bootloader is supported out of the box, since there are no other | |
8378a1eb | 387 | pre-signed bootloader packages available. Any new installation of {pmg} will |
93f6b84a SI |
388 | automatically have all of the above packages included. |
389 | ||
390 | More details about how Secure Boot works, and how to customize the setup, are | |
391 | available in https://pve.proxmox.com/wiki/Secure_Boot_Setup[our wiki]. | |
392 | ||
393 | Switching an Existing Installation to Secure Boot | |
394 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
395 | ||
396 | WARNING: This can lead to an unbootable installation in some cases if not done | |
397 | correctly. Reinstalling the host will setup Secure Boot automatically if | |
398 | available, without any extra interactions. **Make sure you have a working and | |
8378a1eb | 399 | well-tested backup of your {pmg} host!** |
93f6b84a SI |
400 | |
401 | An existing UEFI installation can be switched over to Secure Boot if desired, | |
8378a1eb | 402 | without having to reinstall {pmg} from scratch. |
93f6b84a SI |
403 | |
404 | First, ensure all your system is up-to-date. Next, install all the required | |
405 | pre-signed packages as listed above. GRUB automatically creates the needed EFI | |
406 | boot entry for booting via the default shim. | |
407 | ||
408 | .systemd-boot | |
409 | ||
410 | If `systemd-boot` is used as a bootloader (see | |
411 | xref:sysboot_determine_bootloader_used[Determine which Bootloader is used]), | |
8378a1eb | 412 | some additional setup is needed. This is only the case if {pmg} was installed |
93f6b84a SI |
413 | with ZFS-on-root. |
414 | ||
415 | To check the latter, run: | |
416 | ---- | |
417 | # findmnt / | |
418 | ---- | |
419 | ||
420 | If the host is indeed using ZFS as root filesystem, the `FSTYPE` column | |
421 | should contain `zfs`: | |
422 | ---- | |
423 | TARGET SOURCE FSTYPE OPTIONS | |
8378a1eb | 424 | / rpool/ROOT/pmg-1 zfs rw,relatime,xattr,noacl,casesensitive |
93f6b84a SI |
425 | ---- |
426 | ||
427 | Next, a suitable potential ESP (EFI system partition) must be found. This can be | |
428 | done using the `lsblk` command as following: | |
429 | ---- | |
430 | # lsblk -o +FSTYPE | |
431 | ---- | |
432 | ||
433 | The output should look something like this: | |
434 | ---- | |
435 | NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS FSTYPE | |
436 | sda 8:0 0 32G 0 disk | |
437 | ├─sda1 8:1 0 1007K 0 part | |
438 | ├─sda2 8:2 0 512M 0 part vfat | |
439 | └─sda3 8:3 0 31.5G 0 part zfs_member | |
440 | sdb 8:16 0 32G 0 disk | |
441 | ├─sdb1 8:17 0 1007K 0 part | |
442 | ├─sdb2 8:18 0 512M 0 part vfat | |
443 | └─sdb3 8:19 0 31.5G 0 part zfs_member | |
444 | ---- | |
445 | ||
446 | In this case, the partitions `sda2` and `sdb2` are the targets. They can be | |
447 | identified by the their size of 512M and their `FSTYPE` being `vfat`, in this | |
448 | case on a ZFS RAID-1 installation. | |
449 | ||
450 | These partitions must be properly set up for booting through GRUB using | |
451 | `proxmox-boot-tool`. This command (using `sda2` as an example) must be run | |
452 | separately for each individual ESP: | |
453 | ---- | |
454 | # proxmox-boot-tool init /dev/sda2 grub | |
455 | ---- | |
456 | ||
457 | Afterwards, you can sanity-check the setup by running the following command: | |
458 | ---- | |
459 | # efibootmgr -v | |
460 | ---- | |
461 | ||
462 | This list should contain an entry looking similar to this: | |
463 | ---- | |
464 | [..] | |
465 | Boot0009* proxmox HD(2,GPT,..,0x800,0x100000)/File(\EFI\proxmox\shimx64.efi) | |
466 | [..] | |
467 | ---- | |
468 | ||
469 | NOTE: The old `systemd-boot` bootloader will be kept, but GRUB will be | |
470 | preferred. This way, if booting using GRUB in Secure Boot mode does not work for | |
471 | any reason, the system can still be booted using `systemd-boot` with Secure Boot | |
472 | turned off. | |
473 | ||
474 | Now the host can be rebooted and Secure Boot enabled in the UEFI firmware setup | |
475 | utility. | |
476 | ||
477 | On reboot, a new entry named `proxmox` should be selectable in the UEFI firmware | |
478 | boot menu, which boots using the pre-signed EFI shim. | |
479 | ||
480 | If, for any reason, no `proxmox` entry can be found in the UEFI boot menu, you | |
481 | can try adding it manually (if supported by the firmware), by adding the file | |
482 | `\EFI\proxmox\shimx64.efi` as a custom boot entry. | |
483 | ||
484 | NOTE: Some UEFI firmwares are known to drop the `proxmox` boot option on reboot. | |
485 | This can happen if the `proxmox` boot entry is pointing to a GRUB installation | |
486 | on a disk, where the disk itself is not a boot option. If possible, try adding | |
487 | the disk as a boot option in the UEFI firmware setup utility and run | |
488 | `proxmox-boot-tool` again. | |
489 | ||
490 | TIP: To enroll custom keys, see the accompanying | |
491 | https://pve.proxmox.com/wiki/Secure_Boot_Setup#Setup_instructions_for_db_key_variant[Secure | |
492 | Boot wiki page]. | |
493 | ||
494 | Using DKMS/Third Party Modules With Secure Boot | |
495 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
496 | ||
497 | On systems with Secure Boot enabled, the kernel will refuse to load modules | |
498 | which are not signed by a trusted key. The default set of modules shipped with | |
499 | the kernel packages is signed with an ephemeral key embedded in the kernel | |
500 | image which is trusted by that specific version of the kernel image. | |
501 | ||
502 | In order to load other modules, such as those built with DKMS or manually, they | |
503 | need to be signed with a key trusted by the Secure Boot stack. The easiest way | |
504 | to achieve this is to enroll them as Machine Owner Key (`MOK`) with `mokutil`. | |
505 | ||
506 | The `dkms` tool will automatically generate a keypair and certificate in | |
507 | `/var/lib/dkms/mok.key` and `/var/lib/dkms/mok.pub` and use it for signing | |
508 | the kernel modules it builds and installs. | |
509 | ||
510 | You can view the certificate contents with | |
511 | ||
512 | ---- | |
513 | # openssl x509 -in /var/lib/dkms/mok.pub -noout -text | |
514 | ---- | |
515 | ||
516 | and enroll it on your system using the following command: | |
517 | ||
518 | ---- | |
519 | # mokutil --import /var/lib/dkms/mok.pub | |
520 | input password: | |
521 | input password again: | |
522 | ---- | |
523 | ||
524 | The `mokutil` command will ask for a (temporary) password twice, this password | |
525 | needs to be entered one more time in the next step of the process! Rebooting | |
526 | the system should automatically boot into the `MOKManager` EFI binary, which | |
527 | allows you to verify the key/certificate and confirm the enrollment using the | |
528 | password selected when starting the enrollment using `mokutil`. Afterwards, the | |
529 | kernel should allow loading modules built with DKMS (which are signed with the | |
530 | enrolled `MOK`). The `MOK` can also be used to sign custom EFI binaries and | |
531 | kernel images if desired. | |
532 | ||
533 | The same procedure can also be used for custom/third-party modules not managed | |
534 | with DKMS, but the key/certificate generation and signing steps need to be done | |
535 | manually in that case. |