]> git.proxmox.com Git - pve-docs.git/blame - system-booting.adoc
sysboot: add a section on how to determine the used bootloader
[pve-docs.git] / system-booting.adoc
CommitLineData
69055103
TL
1[[sysboot]]
2Host Bootloader
3---------------
62de1c14
SI
4ifdef::wiki[]
5:pve-toplevel:
6endif::wiki[]
7
69055103
TL
8{pve} currently uses one of two bootloaders depending on the disk setup
9selected in the installer.
62de1c14
SI
10
11For EFI Systems installed with ZFS as the root filesystem `systemd-boot` is
12used. All other deployments use the standard `grub` bootloader (this usually
13also applies to systems which are installed on top of Debian).
14
48a1482b
AL
15[[sysboot_determine_bootloader_used]]
16Determine which bootloader is used
17~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
18
19[thumbnail="screenshot/boot-grub.png", float="left"]
20
21The simplest and most reliable way to determine which bootloader is used, is to
22watch the boot process of the {pve} node.
23
24You will either see the blue box of `grub` or the simple black on white
25`systemd-boot`.
26
27[thumbnail="screenshot/boot-systemdboot.png"]
28
29Determining the bootloader from a running system might not be 100% accurate. The
30safest way is to run the following command:
31
32
33----
34# efibootmgr -v
35----
36
37If it returns a message that EFI variables are not supported, `grub` is used in
38BIOS/Legacy mode.
39
40If the output contains a line that looks similar to the following, `grub` is
41used in UEFI mode.
42
43----
44Boot0005* proxmox [...] File(\EFI\proxmox\grubx64.efi)
45----
46
47If the output contains a line similar to the following, `systemd-bood` is used.
48
49----
50Boot0006* Linux Boot Manager [...] File(\EFI\systemd\systemd-bootx64.efi)
51----
52
53
69055103 54[[sysboot_installer_part_scheme]]
62de1c14
SI
55Partitioning scheme used by the installer
56~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
57
58The {pve} installer creates 3 partitions on the bootable disks selected for
59installation. The bootable disks are:
60
61* For Installations with `ext4` or `xfs` the selected disk
62
63* For ZFS installations all disks belonging to the first `vdev`:
64** The first disk for RAID0
65** All disks for RAID1, RAIDZ1, RAIDZ2, RAIDZ3
66** The first two disks for RAID10
67
68The created partitions are:
69
70* a 1 MB BIOS Boot Partition (gdisk type EF02)
71
72* a 512 MB EFI System Partition (ESP, gdisk type EF00)
73
74* a third partition spanning the set `hdsize` parameter or the remaining space
75 used for the chosen storage type
76
77`grub` in BIOS mode (`--target i386-pc`) is installed onto the BIOS Boot
78Partition of all bootable disks for supporting older systems.
79
80
69055103 81[[sysboot_grub]]
62de1c14
SI
82Grub
83~~~~
84
85`grub` has been the de-facto standard for booting Linux systems for many years
86and is quite well documented
87footnote:[Grub Manual https://www.gnu.org/software/grub/manual/grub/grub.html].
88
89The kernel and initrd images are taken from `/boot` and its configuration file
90`/boot/grub/grub.cfg` gets updated by the kernel installation process.
91
92Configuration
93^^^^^^^^^^^^^
94Changes to the `grub` configuration are done via the defaults file
95`/etc/default/grub` or config snippets in `/etc/default/grub.d`. To regenerate
96the `/boot/grub/grub.cfg` after a change to the configuration run:
97
98----
99`update-grub`.
100----
101
69055103 102[[sysboot_systemd_boot]]
62de1c14
SI
103Systemd-boot
104~~~~~~~~~~~~
105
106`systemd-boot` is a lightweight EFI bootloader. It reads the kernel and initrd
107images directly from the EFI Service Partition (ESP) where it is installed.
108The main advantage of directly loading the kernel from the ESP is that it does
109not need to reimplement the drivers for accessing the storage. In the context
110of ZFS as root filesystem this means that you can use all optional features on
111your root pool instead of the subset which is also present in the ZFS
112implementation in `grub` or having to create a separate small boot-pool
113footnote:[Booting ZFS on root with grub https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS].
114
115In setups with redundancy (RAID1, RAID10, RAIDZ*) all bootable disks (those
116being part of the first `vdev`) are partitioned with an ESP. This ensures the
117system boots even if the first boot device fails. The ESPs are kept in sync by
118a kernel postinstall hook script `/etc/kernel/postinst.d/zz-pve-efiboot`. The
119script copies certain kernel versions and the initrd images to `EFI/proxmox/`
120on the root of each ESP and creates the appropriate config files in
300655b3
FG
121`loader/entries/proxmox-*.conf`. The `pve-efiboot-tool` script assists in
122managing both the synced ESPs themselves and their contents.
62de1c14
SI
123
124The following kernel versions are configured by default:
125
126* the currently running kernel
127* the version being newly installed on package updates
8152d9b6
FG
128* the two latest already installed kernels
129* the latest version of the second-to-last kernel series (e.g. 4.15, 5.0), if applicable
130* any manually selected kernels (see below)
62de1c14
SI
131
132The ESPs are not kept mounted during regular operation, in contrast to `grub`,
133which keeps an ESP mounted on `/boot/efi`. This helps to prevent filesystem
134corruption to the `vfat` formatted ESPs in case of a system crash, and removes
135the need to manually adapt `/etc/fstab` in case the primary boot device fails.
136
69055103 137[[sysboot_systemd_boot_config]]
62de1c14
SI
138Configuration
139^^^^^^^^^^^^^
140
141`systemd-boot` is configured via the file `loader/loader.conf` in the root
142directory of an EFI System Partition (ESP). See the `loader.conf(5)` manpage
143for details.
144
145Each bootloader entry is placed in a file of its own in the directory
146`loader/entries/`
147
148An example entry.conf looks like this (`/` refers to the root of the ESP):
149
150----
151title Proxmox
152version 5.0.15-1-pve
153options root=ZFS=rpool/ROOT/pve-1 boot=zfs
154linux /EFI/proxmox/5.0.15-1-pve/vmlinuz-5.0.15-1-pve
155initrd /EFI/proxmox/5.0.15-1-pve/initrd.img-5.0.15-1-pve
156----
157
158
159.Manually keeping a kernel bootable
160
161Should you wish to add a certain kernel and initrd image to the list of
f11fb629 162bootable kernels use `pve-efiboot-tool kernel add`.
62de1c14 163
1722c45b
FG
164For example run the following to add the kernel with ABI version `5.0.15-1-pve`
165to the list of kernels to keep installed and synced to all ESPs:
62de1c14 166
1722c45b
FG
167----
168pve-efiboot-tool kernel add 5.0.15-1-pve
169----
170
171`pve-efiboot-tool kernel list` will list all kernel versions currently selected
172for booting:
173
174----
175# pve-efiboot-tool kernel list
176Manually selected kernels:
1775.0.15-1-pve
178
179Automatically selected kernels:
1805.0.12-1-pve
1814.15.18-18-pve
182----
62de1c14 183
1722c45b
FG
184Run `pve-efiboot-tool remove` to remove a kernel from the list of manually
185selected kernels, for example:
62de1c14
SI
186
187----
1722c45b 188pve-efiboot-tool kernel remove 5.0.15-1-pve
62de1c14
SI
189----
190
b74373e4
TL
191NOTE: It's required to run `pve-efiboot-tool refresh` to update all EFI System
192Partitions (ESPs) after a manual kernel addition or removal from above.
1722c45b 193
0daaddbd
FG
194[[sysboot_systemd_boot_setup]]
195.Setting up a new partition for use as synced ESP
196
197To format and initialize a partition as synced ESP, e.g., after replacing a
198failed vdev in an rpool, or when converting an existing system that pre-dates
199the sync mechanism, `pve-efiboot-tool` from `pve-kernel-helpers` can be used.
200
201WARNING: the `format` command will format the `<partition>`, make sure to pass
202in the right device/partition!
203
204For example, to format an empty partition `/dev/sda2` as ESP, run the following:
205
206----
207pve-efiboot-tool format /dev/sda2
208----
209
210To setup an existing, unmounted ESP located on `/dev/sda2` for inclusion in
3fe127c7 211{pve}'s kernel update synchronization mechanism, use the following:
0daaddbd
FG
212
213----
214pve-efiboot-tool init /dev/sda2
215----
216
217Afterwards `/etc/kernel/pve-efiboot-uuids` should contain a new line with the
218UUID of the newly added partition. The `init` command will also automatically
219trigger a refresh of all configured ESPs.
62de1c14 220
69055103 221[[sysboot_systemd_boot_refresh]]
62de1c14
SI
222.Updating the configuration on all ESPs
223
0daaddbd 224To copy and configure all bootable kernels and keep all ESPs listed in
b74373e4
TL
225`/etc/kernel/pve-efiboot-uuids` in sync you just need to run:
226
227----
228 pve-efiboot-tool refresh
229----
f11fb629 230(The equivalent to running `update-grub` on systems being booted with `grub`).
62de1c14 231
0daaddbd 232This is necessary should you make changes to the kernel commandline, or want to
0aebb0d9
SR
233sync all kernels and initrds.
234
235NOTE: Both `update-initramfs` and `apt` (when necessary) will automatically
236trigger a refresh.
62de1c14 237
69055103 238[[sysboot_edit_kernel_cmdline]]
62de1c14
SI
239Editing the kernel commandline
240~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
241
242You can modify the kernel commandline in the following places, depending on the
f11fb629 243bootloader used:
62de1c14
SI
244
245.Grub
246
247The kernel commandline needs to be placed in the variable
248`GRUB_CMDLINE_LINUX_DEFAULT` in the file `/etc/default/grub`. Running
249`update-grub` appends its content to all `linux` entries in
250`/boot/grub/grub.cfg`.
251
252.Systemd-boot
253
0aebb0d9 254The kernel commandline needs to be placed as one line in `/etc/kernel/cmdline`.
ab2bc36e 255To apply your changes, run `pve-efiboot-tool refresh`, which sets it as the
0aebb0d9 256`option` line for all config files in `loader/entries/proxmox-*.conf`.