If one install FreeBSD on the same machine multiple times in a row or
on different harddrive they have a lot of 'FreeBSD' efi boot entries added.
With this patch we now do :
- If there is no 'FreeBSD' entry we add one like before
- If there is one or more entries we ask the user if they want to delete
them all and add a new one
- If they say yes we do that
- If they say no we prompt them an inputbox so they can enter a different
entry name if they want, it defaults to 'FreeBSD'
Reviewed by: bapt, imp
MFC after: 2 weeks
Sponsored by: Beckhoff Automation GmbH & Co. KG
Differential Revision: https://reviews.freebsd.org/D33330
(cherry picked from commit 40c928e7b8)
It's required to specify a default boot option in order to make
petitboot's autoboot feature work.
Tested on Raptor Blackbird
Reviewed by: imp, luporl
MFC after: 2 days
Sponsored by: Instituto de Pesquisas Eldorado (eldorado.org.br)
Differential Revision: https://reviews.freebsd.org/D32838
(cherry picked from commit b6644f529c)
The bsdinstall script target did not have the infrastructure to fetch
distfiles from a remote server the way the interactive installer does
on e.g. bootonly media. Solve this by factoring out the parts of the
installer that deal with fetching missing distributions into a new
install stage called 'fetchmissingdists', which is called by both the
interactive and scripted installer frontends.
In the course of these changes, cleaned up a few other issues with
the fetching of missing distribution files and added a warning if
fetching the MANIFEST file, which is used to verify the integrity of
the distribution files. We should at some point add cryptographic
signatures to MANIFEST so that it can be fetched safely if not present
on the install media (which it is for bootonly media).
Initial patch by: Vinícius Zavam
PR: 255659, 250928
Reviewed by: dteske
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D27121
(cherry picked from commit 40923b0c81)
images.
Per hier(7), the ESP will be mounted at /boot/efi. On UFS systems,
any existing ESP will be reused and mounted there; otherwise, a new one
will be made. On ZFS systems, space for an ESP is allocated on all disks
in the root pool, but only the partition actually used to boot is set up
and mounted.
This makes future upgrades of the EFI loader easier (upgrade scripts can
just change /boot/efi) and also greatly simplifies the parts of the
installer involved in initialization of the ESP. It also makes the
installer's behavior correspond to the documentation in hier(7).
Reviewed by: imp, tsoome, bdragon
Approved by: re (gjb)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D28897
(cherry picked from commit 0b7472b3d8)
(cherry picked from commit 2c26d77d98)
(cherry picked from commit e77cf2a4ab)
(cherry picked from commit e70eb40271)
Make the installer more useful, by allowing it to create a bootable
installation. Also, enable the menu option for ZFS-on-root.
Like arm64, RISC-V boots by UEFI only, so arm64's partedit
implementation is renamed and shared among the two platforms.
Reviewed by: gjb
(cherry picked from commit 7b08a307e8)
If the installer is creating a new ESP, then this directory will not
exist and the subsequent cp will fail silently. This is usually of no
consequence if /efi/freebsd/loader.efi is set up correctly.
Reviewed by: imp
(cherry picked from commit 676b7d077c)
Too many version of UEFI firmware (so far only confirmed on amd64)
don't really support efibootmgr selection of boot. That's the most
reliable, when it works, since there's no guesswork. However, many do
not save, unmolested, the variables that efibootmgr sets, so as a
fallback we also install loader.efi as bootXXX.efi (where XXX is
either aa64 or x64) if it doesn't already exist in /efi/boot on the
ESP. The standard only defines this for removable devices, but it's
almost ubiquitously used as a fallback. Many BIOSes implement a drive
selection feature that takes over the efibootmgr protocol, rendinering
it useless (either generally, or for those vendors not on the short
list). bootxxx.efi works around this. However, we don't install it
unconditionally there, as that breaks some popular multi-boot setups.
MFC After: 1 week
Differential Revision: https://reviews.freebsd.org/D26428
Pass the list of user selected disks from zfsboot to bootconfig so that
the latter doesn't rely on ESP autodetection that apparently fails for
some cases, e.g. memstick installation with nvme (boot) and sata drives.
While here, fix printing of debug messages in bootconfig.
Reviewed by: bcran, imp, tsoome
Differential Revision: https://reviews.freebsd.org/D21930
When using a gmirror, entries in /dev can be removed. So instead of using
kern.disks, get the list of disks from "gpart status -sg" instead.
We assume that any 'efi' partition that can't be mounted as msdosfs should
be used as an ESP. However, the ESP on the CD/DVD can't be mounted read-write
and so was being treated as if unformatted. Try the mount as read-only
instead, to catch cases like this.
Relnotes: yes
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D18645
Currently, the installer uses pre-created 800KB FAT12 filesystems that
it dd's onto the ESP partition.
This changeset improves that by having the installer generate a FAT32
filesystem directly onto the ESP using newfs_msdos and then copying
loader.efi into /EFI/freebsd.
For live installs it then runs efibootmgr to add a FreeBSD boot entry
in the BIOS.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D17947
Summary:
The kernel reads 'kernelname' to set the kern.bootfile sysctl. By setting this,
'make installkernel' will backup the running kernel as appropriate.
Reviewed by: nwhitehorn
Differential Revision: https://reviews.freebsd.org/D15660
foundation for invoking efibootmgr as part of new-style EFI booting on
x86. On PS3 and PowerNV, which are booted using Linux kexec from petitboot
rather than by loader(8), install the kernel and the rest of /boot to a
FAT partition and set up the appropriate petitboot configuration file
there.
The new bootconfig installer stage can do platform-dependent modifications
more complex than partition layout and installation of boot blocks and can
be used to (as here) set up some special configuration files, run efibootmgr,
or boot0cfg.
MFC after: 1 month
