proxmox-mirrors/pve-docs
1
0
Fork 0
mirror of https://git.proxmox.com/git/pve-docs synced 2025-10-04 21:16:32 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

tree-wide: unify spelling of GRUB and systemd-boot

Browse Source 
Especially for GRUB there were a myriad of different casing variants
(e.g. grub, Grub, GRUB), so unify them, with GRUB being the official
casing.

For systemd-boot, fix an instance where it was not typeset as
monospace, like everywhere else.

Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This commit is contained in:
Christoph Heiss 2024-01-25 12:06:31 +01:00 committed by Thomas Lamprecht
parent 83a43f6ee8
commit 7c73a2099c
3 changed files with 35 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
local-zfs.adoc
View File

@ -497,10 +497,9 @@ Changing a failed device
.Changing a failed bootable device .Changing a failed bootable device
Depending on how {pve} was installed it is either using `systemd-boot` or `grub` Depending on how {pve} was installed it is either using `systemd-boot` or GRUB
through `proxmox-boot-tool` through `proxmox-boot-tool` footnote:[Systems installed with {pve} 6.4 or later,
footnote:[Systems installed with {pve} 6.4 or later, EFI systems installed with EFI systems installed with {pve} 5.4 or later] or plain GRUB as bootloader (see
{pve} 5.4 or later] or plain `grub` as bootloader (see
xref:sysboot[Host Bootloader]). You can check by running: xref:sysboot[Host Bootloader]). You can check by running:
---- ----
@ -531,16 +530,16 @@ NOTE: `ESP` stands for EFI System Partition, which is setup as partition #2 on
bootable disks setup by the {pve} installer since version 5.4. For details, see bootable disks setup by the {pve} installer since version 5.4. For details, see
xref:sysboot_proxmox_boot_setup[Setting up a new partition for use as synced ESP]. xref:sysboot_proxmox_boot_setup[Setting up a new partition for use as synced ESP].
NOTE: make sure to pass 'grub' as mode to `proxmox-boot-tool init` if NOTE: Make sure to pass 'grub' as mode to `proxmox-boot-tool init` if
`proxmox-boot-tool status` indicates your current disks are using Grub, `proxmox-boot-tool status` indicates your current disks are using GRUB,
especially if Secure Boot is enabled! especially if Secure Boot is enabled!
.With plain `grub`: .With plain GRUB:
---- ----
# grub-install <new disk> # grub-install <new disk>
---- ----
NOTE: plain `grub` is only used on systems installed with {pve} 6.3 or earlier, NOTE: Plain GRUB is only used on systems installed with {pve} 6.3 or earlier,
which have not been manually migrated to using `proxmox-boot-tool` yet. which have not been manually migrated to using `proxmox-boot-tool` yet.
@ -684,7 +683,7 @@ tank feature@encryption enabled local
---- ----
WARNING: There is currently no support for booting from pools with encrypted WARNING: There is currently no support for booting from pools with encrypted
datasets using Grub, and only limited support for automatically unlocking datasets using GRUB, and only limited support for automatically unlocking
encrypted datasets on boot. Older versions of ZFS without encryption support encrypted datasets on boot. Older versions of ZFS without encryption support
will not be able to decrypt stored data. will not be able to decrypt stored data.
@ -854,16 +853,16 @@ them.
In fact, there are some downsides to enabling new features: In fact, there are some downsides to enabling new features:
* A system with root on ZFS, that still boots using `grub` will become * A system with root on ZFS, that still boots using GRUB will become
unbootable if a new feature is active on the rpool, due to the incompatible unbootable if a new feature is active on the rpool, due to the incompatible
implementation of ZFS in grub. implementation of ZFS in GRUB.
* The system will not be able to import any upgraded pool when booted with an * The system will not be able to import any upgraded pool when booted with an
older kernel, which still ships with the old ZFS modules. older kernel, which still ships with the old ZFS modules.
* Booting an older {pve} ISO to repair a non-booting system will likewise not * Booting an older {pve} ISO to repair a non-booting system will likewise not
work. work.
IMPORTANT: Do *not* upgrade your rpool if your system is still booted with IMPORTANT: Do *not* upgrade your rpool if your system is still booted with
`grub`, as this will render your system unbootable. This includes systems GRUB, as this will render your system unbootable. This includes systems
installed before {pve} 5.4, and systems booting with legacy BIOS boot (see installed before {pve} 5.4, and systems booting with legacy BIOS boot (see
xref:sysboot_determine_bootloader_used[how to determine the bootloader]). xref:sysboot_determine_bootloader_used[how to determine the bootloader]).

4
pve-installation.adoc
View File

@ -114,8 +114,8 @@ Advanced Options: Rescue Boot::
With this option you can boot an existing installation. It searches all attached With this option you can boot an existing installation. It searches all attached
hard disks. If it finds an existing installation, it boots directly into that hard disks. If it finds an existing installation, it boots directly into that
disk using the Linux kernel from the ISO. This can be useful if there are disk using the Linux kernel from the ISO. This can be useful if there are
problems with the boot block (grub) or the BIOS is unable to read the boot block problems with the bootloader (GRUB/`systemd-boot`) or the BIOS/UEFI is unable to
from the disk. read the boot block from the disk.
Advanced Options: Test Memory (memtest86+):: Advanced Options: Test Memory (memtest86+)::

44
system-booting.adoc
View File

@ -10,7 +10,7 @@ selected in the installer.
For EFI Systems installed with ZFS as the root filesystem `systemd-boot` is For EFI Systems installed with ZFS as the root filesystem `systemd-boot` is
used, unless Secure Boot is enabled. All other deployments use the standard used, unless Secure Boot is enabled. All other deployments use the standard
`grub` bootloader (this usually also applies to systems which are installed on GRUB bootloader (this usually also applies to systems which are installed on
top of Debian). top of Debian).
@ -32,12 +32,12 @@ The created partitions are:
Systems using ZFS as root filesystem are booted with a kernel and initrd image Systems using ZFS as root filesystem are booted with a kernel and initrd image
stored on the 512 MB EFI System Partition. For legacy BIOS systems, and EFI stored on the 512 MB EFI System Partition. For legacy BIOS systems, and EFI
systems with Secure Boot enabled, `grub` is used, for EFI systems without systems with Secure Boot enabled, GRUB is used, for EFI systems without
Secure Boot, `systemd-boot` is used. Both are installed and configured to point Secure Boot, `systemd-boot` is used. Both are installed and configured to point
to the ESPs. to the ESPs.
`grub` in BIOS mode (`--target i386-pc`) is installed onto the BIOS Boot GRUB in BIOS mode (`--target i386-pc`) is installed onto the BIOS Boot
Partition of all selected disks on all systems booted with `grub` Partition of all selected disks on all systems booted with GRUB
footnote:[These are all installs with root on `ext4` or `xfs` and installs footnote:[These are all installs with root on `ext4` or `xfs` and installs
with root on ZFS on non-EFI systems]. with root on ZFS on non-EFI systems].
@ -51,8 +51,8 @@ Partitions properly configured and synchronized. It copies certain kernel
versions to all ESPs and configures the respective bootloader to boot from versions to all ESPs and configures the respective bootloader to boot from
the `vfat` formatted ESPs. In the context of ZFS as root filesystem this means the `vfat` formatted ESPs. In the context of ZFS as root filesystem this means
that you can use all optional features on your root pool instead of the subset that you can use all optional features on your root pool instead of the subset
which is also present in the ZFS implementation in `grub` or having to create a which is also present in the ZFS implementation in GRUB or having to create a
separate small boot-pool footnote:[Booting ZFS on root with grub separate small boot-pool footnote:[Booting ZFS on root with GRUB
https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS]. https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS].
In setups with redundancy all disks are partitioned with an ESP, by the In setups with redundancy all disks are partitioned with an ESP, by the
@ -108,7 +108,7 @@ or
# proxmox-boot-tool init /dev/sda2 grub # proxmox-boot-tool init /dev/sda2 grub
---- ----
to force initialization with Grub instead of systemd-boot, for example for to force initialization with GRUB instead of `systemd-boot`, for example for
Secure Boot support. Secure Boot support.
Afterwards `/etc/kernel/proxmox-boot-uuids` should contain a new line with the Afterwards `/etc/kernel/proxmox-boot-uuids` should contain a new line with the
@ -186,7 +186,7 @@ Determine which Bootloader is Used
The simplest and most reliable way to determine which bootloader is used, is to The simplest and most reliable way to determine which bootloader is used, is to
watch the boot process of the {pve} node. watch the boot process of the {pve} node.
You will either see the blue box of `grub` or the simple black on white You will either see the blue box of GRUB or the simple black on white
`systemd-boot`. `systemd-boot`.
[thumbnail="screenshot/boot-systemdboot.png"] [thumbnail="screenshot/boot-systemdboot.png"]
@ -199,10 +199,10 @@ safest way is to run the following command:
# efibootmgr -v # efibootmgr -v
---- ----
If it returns a message that EFI variables are not supported, `grub` is used in If it returns a message that EFI variables are not supported, GRUB is used in
BIOS/Legacy mode. BIOS/Legacy mode.
If the output contains a line that looks similar to the following, `grub` is If the output contains a line that looks similar to the following, GRUB is
used in UEFI mode. used in UEFI mode.
---- ----
@ -226,16 +226,16 @@ indication of how the system is booted.
[[sysboot_grub]] [[sysboot_grub]]
Grub GRUB
~~~~ ~~~~
`grub` has been the de-facto standard for booting Linux systems for many years GRUB has been the de-facto standard for booting Linux systems for many years
and is quite well documented and is quite well documented
footnote:[Grub Manual https://www.gnu.org/software/grub/manual/grub/grub.html]. footnote:[GRUB Manual https://www.gnu.org/software/grub/manual/grub/grub.html].
Configuration Configuration
^^^^^^^^^^^^^ ^^^^^^^^^^^^^
Changes to the `grub` configuration are done via the defaults file Changes to the GRUB configuration are done via the defaults file
`/etc/default/grub` or config snippets in `/etc/default/grub.d`. To regenerate `/etc/default/grub` or config snippets in `/etc/default/grub.d`. To regenerate
the configuration file after a change to the configuration run: the configuration file after a change to the configuration run:
footnote:[Systems using `proxmox-boot-tool` will call `proxmox-boot-tool footnote:[Systems using `proxmox-boot-tool` will call `proxmox-boot-tool
@ -286,7 +286,7 @@ Editing the Kernel Commandline
You can modify the kernel commandline in the following places, depending on the You can modify the kernel commandline in the following places, depending on the
bootloader used: bootloader used:
.Grub .GRUB
The kernel commandline needs to be placed in the variable The kernel commandline needs to be placed in the variable
`GRUB_CMDLINE_LINUX_DEFAULT` in the file `/etc/default/grub`. Running `GRUB_CMDLINE_LINUX_DEFAULT` in the file `/etc/default/grub`. Running
@ -383,10 +383,10 @@ The following packages need to be installed for Secure Boot to be enabled:
- `shim-signed` (shim bootloader signed by Microsoft) - `shim-signed` (shim bootloader signed by Microsoft)
- `shim-helpers-amd64-signed` (fallback bootloader and MOKManager, signed by - `shim-helpers-amd64-signed` (fallback bootloader and MOKManager, signed by
Proxmox) Proxmox)
- `grub-efi-amd64-signed` (Grub EFI bootloader, signed by Proxmox) - `grub-efi-amd64-signed` (GRUB EFI bootloader, signed by Proxmox)
- `proxmox-kernel-6.X.Y-Z-pve-signed` (Kernel image, signed by Proxmox) - `proxmox-kernel-6.X.Y-Z-pve-signed` (Kernel image, signed by Proxmox)
Only Grub as bootloader is supported out of the box, since there are no other Only GRUB as bootloader is supported out of the box, since there are no other
pre-signed bootloader packages available. Any new installation of {pve} will pre-signed bootloader packages available. Any new installation of {pve} will
automatically have all of the above packages included. automatically have all of the above packages included.
@ -405,7 +405,7 @@ An existing UEFI installation can be switched over to Secure Boot if desired,
without having to reinstall {pve} from scratch. without having to reinstall {pve} from scratch.
First, ensure all your system is up-to-date. Next, install all the required First, ensure all your system is up-to-date. Next, install all the required
pre-signed packages as listed above. Grub automatically creates the needed EFI pre-signed packages as listed above. GRUB automatically creates the needed EFI
boot entry for booting via the default shim. boot entry for booting via the default shim.
.systemd-boot .systemd-boot
@ -450,7 +450,7 @@ In this case, the partitions `sda2` and `sdb2` are the targets. They can be
identified by the their size of 512M and their `FSTYPE` being `vfat`, in this identified by the their size of 512M and their `FSTYPE` being `vfat`, in this
case on a ZFS RAID-1 installation. case on a ZFS RAID-1 installation.
These partitions must be properly set up for booting through Grub using These partitions must be properly set up for booting through GRUB using
`proxmox-boot-tool`. This command (using `sda2` as an example) must be run `proxmox-boot-tool`. This command (using `sda2` as an example) must be run
separately for each individual ESP: separately for each individual ESP:
---- ----
@ -469,8 +469,8 @@ Boot0009* proxmox HD(2,GPT,..,0x800,0x100000)/File(\EFI\proxmox\shimx64.ef
[..] [..]
---- ----
NOTE: The old `systemd-boot` bootloader will be kept, but Grub will be NOTE: The old `systemd-boot` bootloader will be kept, but GRUB will be
preferred. This way, if booting using Grub in Secure Boot mode does not work for preferred. This way, if booting using GRUB in Secure Boot mode does not work for
any reason, the system can still be booted using `systemd-boot` with Secure Boot any reason, the system can still be booted using `systemd-boot` with Secure Boot
turned off. turned off.
@ -485,7 +485,7 @@ can try adding it manually (if supported by the firmware), by adding the file
`\EFI\proxmox\shimx64.efi` as a custom boot entry. `\EFI\proxmox\shimx64.efi` as a custom boot entry.
NOTE: Some UEFI firmwares are known to drop the `proxmox` boot option on reboot. NOTE: Some UEFI firmwares are known to drop the `proxmox` boot option on reboot.
This can happen if the `proxmox` boot entry is pointing to a Grub installation This can happen if the `proxmox` boot entry is pointing to a GRUB installation
on a disk, where the disk itself is not a boot option. If possible, try adding on a disk, where the disk itself is not a boot option. If possible, try adding
the disk as a boot option in the UEFI firmware setup utility and run the disk as a boot option in the UEFI firmware setup utility and run
`proxmox-boot-tool` again. `proxmox-boot-tool` again.