From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 55D839D871 for ; Fri, 24 Nov 2023 11:47:10 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B802CCB91 for ; Fri, 24 Nov 2023 11:46:11 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 24 Nov 2023 11:46:10 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 961C843B12 for ; Fri, 24 Nov 2023 11:46:10 +0100 (CET) From: Christoph Heiss To: pve-devel@lists.proxmox.com Date: Fri, 24 Nov 2023 11:46:02 +0100 Message-ID: <20231124104605.320052-8-c.heiss@proxmox.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20231124104605.320052-1-c.heiss@proxmox.com> References: <20231124104605.320052-1-c.heiss@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.003 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [gnu.org] Subject: [pve-devel] [PATCH docs 7/7] tree-wide: unify spelling of GRUB and systemd-boot X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2023 10:47:10 -0000 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 --- local-zfs.adoc | 23 +++++++++++------------ pve-installation.adoc | 4 ++-- system-booting.adoc | 30 +++++++++++++++--------------- 3 files changed, 28 insertions(+), 29 deletions(-) diff --git a/local-zfs.adoc b/local-zfs.adoc index 63de884..ef05697 100644 --- a/local-zfs.adoc +++ b/local-zfs.adoc @@ -497,10 +497,9 @@ Changing a failed device .Changing a failed bootable device -Depending on how {pve} was installed it is either using `systemd-boot` or `grub` -through `proxmox-boot-tool` -footnote:[Systems installed with {pve} 6.4 or later, EFI systems installed with -{pve} 5.4 or later] or plain `grub` as bootloader (see +Depending on how {pve} was installed it is either using `systemd-boot` or GRUB +through `proxmox-boot-tool` footnote:[Systems installed with {pve} 6.4 or later, +EFI systems installed with {pve} 5.4 or later] or plain GRUB as bootloader (see 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 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 -`proxmox-boot-tool status` indicates your current disks are using Grub, +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, especially if Secure Boot is enabled! -.With plain `grub`: +.With plain GRUB: ---- # grub-install ---- -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. @@ -684,7 +683,7 @@ tank feature@encryption enabled local ---- 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 will not be able to decrypt stored data. @@ -854,16 +853,16 @@ them. 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 - 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 older kernel, which still ships with the old ZFS modules. * Booting an older {pve} ISO to repair a non-booting system will likewise not work. 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 xref:sysboot_determine_bootloader_used[how to determine the bootloader]). diff --git a/pve-installation.adoc b/pve-installation.adoc index 635e0a4..b07943e 100644 --- a/pve-installation.adoc +++ b/pve-installation.adoc @@ -113,8 +113,8 @@ Advanced Options: Rescue Boot:: 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 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 -from the disk. +problems with the bootloader (GRUB/`systemd-boot`) or the BIOS/UEFI is unable to +read the boot block from the disk. Advanced Options: Test Memory (memtest86+):: diff --git a/system-booting.adoc b/system-booting.adoc index b8ac15d..646269d 100644 --- a/system-booting.adoc +++ b/system-booting.adoc @@ -10,7 +10,7 @@ selected in the installer. 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 -`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). @@ -32,12 +32,12 @@ The created partitions are: 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 -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 to the ESPs. -`grub` in BIOS mode (`--target i386-pc`) is installed onto the BIOS Boot -Partition of all selected disks on all systems booted with `grub` +GRUB in BIOS mode (`--target i386-pc`) is installed onto the BIOS Boot +Partition of all selected disks on all systems booted with GRUB footnote:[These are all installs with root on `ext4` or `xfs` and installs 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 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 -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 +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 https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS]. 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 ---- -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. 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 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`. [thumbnail="screenshot/boot-systemdboot.png"] @@ -199,10 +199,10 @@ safest way is to run the following command: # 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. -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. ---- @@ -229,13 +229,13 @@ indication of how the system is booted. 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 footnote:[Grub Manual https://www.gnu.org/software/grub/manual/grub/grub.html]. 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 the configuration file after a change to the configuration run: footnote:[Systems using `proxmox-boot-tool` will call `proxmox-boot-tool @@ -468,8 +468,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 -preferred. This way, if booting using Grub in Secure Boot mode does not work for +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 any reason, the system can still be booted using `systemd-boot` with Secure Boot turned off. @@ -484,7 +484,7 @@ can try adding it manually (if supported by the firmware), by adding the file `\EFI\proxmox\shimx64.efi` as a custom boot entry. 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 not a boot option. If possible, try adding the disk as a boot option in the UEFI firmware setup utility and run `proxmox-boot-tool` again. -- 2.42.0