Some UEFI firmware is easily provoked into running out of space in its
variable storage. This is usually due to certain kernel drivers (e.g.
pstore), but regardless of the cause it can cause grub-install to fail
because it currently asks efibootmgr to delete and re-add entries, and
the deletion often doesn't result in an immediate garbage collection.
Writing variables frequently also increases wear on the NVRAM which may
have limited write cycles. For these reasons, it's desirable to find a
way to minimise writes while still allowing grub-install to ensure that
a suitable boot entry exists.
Unfortunately, efibootmgr doesn't offer an interface that would let
grub-install do this. It doesn't in general make very much effort to
minimise writes; it doesn't allow modifying an existing Boot* variable
entry, except in certain limited ways; and current versions don't have a
way to export the expected variable data so that grub-install can
compare it to the current data. While it would be possible (and perhaps
desirable?) to add at least some of this to efibootmgr, that would still
leave the problem that there isn't a good upstreamable way for
grub-install to guarantee that it has a new enough version of
efibootmgr. In any case, it's cumbersome and slow for grub-install to
have to fork efibootmgr to get things done.
Fortunately, a few years ago Peter Jones helpfully factored out a
substantial part of efibootmgr to the efivar and efiboot libraries, and
so it's now possible to have grub-install use those directly. We still
have to use some code from efibootmgr, but much less than would
previously have been necessary.
grub-install now reuses existing boot entries where possible, and avoids
writing to variables when the new contents are the same as the old
contents. In the common upgrade case where nothing needs to change, it
no longer writes to NVRAM at all. It's also now slightly faster, since
using libefivar is faster than forking efibootmgr.
Fixes Debian bug #891434.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Bug-Debian: https://bugs.debian.org/891434
Forwarded: https://lists.gnu.org/archive/html/grub-devel/2019-03/msg00119.html
Last-Update: 2019-03-23
Patch-Name: efi-variable-storage-minimise-writes.patch
zfs-initramfs currently provides extraneous, undesired symlinks to
devices directly underneath /dev/ to satisfy zpool's historical output
of unqualified device names. By including this environment variable to
signal our intent to zpool, zfs-linux packages can drop the symlink
behavior when updating to its upstream or backported output behavior.
Bug: https://savannah.gnu.org/bugs/?43653
Bug-Debian: https://bugs.debian.org/824974
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1527727
Last-Update: 2016-11-01
Patch-Name: zpool-full-device-name.patch
Some powerpc machines require not updating the NVRAM. This can be handled
by existing grub-install command-line options, but it's friendlier to detect
this automatically.
On chrp_ibm machines, use the nvram utility rather than nvsetenv. (This
is possibly suitable for other machines too, but that needs to be
verified.)
Forwarded: no
Last-Update: 2014-10-15
Patch-Name: install-powerpc-machtypes.patch
The functions grub_util_exec_pipe() and grub_util_exec_pipe_stderr()
currently call execvp(). If the call fails for any reason, the child
currently calls exit(127). This in turn executes the parents
atexit() handlers from the forked child, and then the same handlers
are called again from parent. This is usually not desired, and can
lead to deadlocks, and undesired behavior. So, change the exit() calls
to _exit() calls to avoid calling atexit() handlers from child.
Fixes: e75cf4a58 (unix exec: avoid atexit handlers when child exits)
Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This modifies most of the places we do some form of:
X = malloc(Y * Z);
to use calloc(Y, Z) instead.
Among other issues, this fixes:
- allocation of integer overflow in grub_png_decode_image_header()
reported by Chris Coulson,
- allocation of integer overflow in luks_recover_key()
reported by Chris Coulson,
- allocation of integer overflow in grub_lvm_detect()
reported by Chris Coulson.
Fixes: CVE-2020-14308
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
We are often bothered by this sort of lvm warning while running grub-install
every now and then:
File descriptor 4 (/dev/vda1) leaked on vgs invocation. Parent PID 1991: /usr/sbin/grub2-install
The requirement related to the warning is dictated in the lvm man page:
"On invocation, lvm requires that only the standard file descriptors stdin,
stdout and stderr are available. If others are found, they get closed and
messages are issued warning about the leak. This warning can be suppressed by
setting the environment variable LVM_SUPPRESS_FD_WARNINGS."
While it could be disabled through settings, most Linux distributions seem to
enable it by default and the justification provided by the developer looks to
be valid to me: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466138#15
Rather than trying to close and reopen the file descriptor to the same file
multiple times, which is rather cumbersome, for the sake of no vgs invocation
could happen in between. This patch enables the close-on-exec flag (O_CLOEXEC)
for new file descriptor returned by the open() system call, making it closed
thus not inherited by the child process forked and executed by the exec()
family of functions.
Fixes Debian bug #466138.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Various GRUB utilities fail if the current directory doesn't exist,
because grub_find_device() chdirs to a different directory and then
fails when trying to chdir back. Gnulib's save-cwd module uses fchdir()
instead when it can, avoiding this category of problem.
Fixes Debian bug #918700.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Many of GRUB's utilities don't check anywhere near all the possible
write errors. For example, if grub-install runs out of space when
copying a file, it won't notice. There were missing checks for the
return values of write, fflush, fsync, and close (or the equivalents on
other OSes), all of which must be checked.
I tried to be consistent with the existing logging practices of the
various hostdisk implementations, but they weren't entirely consistent
to start with so I used my judgement. The result at least looks
reasonable on GNU/Linux when I provoke a write error:
Installing for x86_64-efi platform.
grub-install: error: cannot copy `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' to `/boot/efi/EFI/debian/grubx64.efi': No space left on device.
There are more missing checks in other utilities, but this should fix
the most critical ones.
Fixes Debian bug #922741.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
On a UEFI system, were no boot entry *grub* is present, currently,
`grub-install` fails with an error.
$ efibootmgr
BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0001,0006,0003,0004,0005
Boot0001 Diskette Drive
Boot0003* USB Storage Device
Boot0004* CD/DVD/CD-RW Drive
Boot0005 Onboard NIC
Boot0006* WDC WD2500AAKX-75U6AA0
$ sudo grub-install /dev/sda
Installing for x86_64-efi platform.
grub-install: error: efibootmgr failed to register the boot entry: Unknown error 22020.
The error code is always different, and the error message (incorrectly)
points to efibootmgr.
But, the error is in GRUB’s function
`grub_install_remove_efi_entries_by_distributor()`, where the variable
`rc` for the return value, is uninitialized and never set, when no boot
entry for the distributor is found.
The content of that uninitialized variable is then returned as the error
code of efibootmgr.
Set the variable to 0, so that success is returned, when no entry needs
to be deleted.
Tested on Dell OptiPlex 7010 with firmware A28.
$ sudo ./grub-install /dev/sda
Installing for x86_64-efi platform.
Installation finished. No error reported.
[1]: https://github.com/rhboot/efibootmgr/issues/100
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This patch ensures that grub-probe will find the root device placed in
/dev/mapper/dm-[0-9]+-.* e.g. device named /dev/mapper/dm-0-luks will be
found and grub.cfg will be updated properly, enabling the system to boot.
Signed-off-by: Oleg Solovyov <mcpain@altlinux.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Code is currently ignoring errors from efibootmgr, giving users
clearly bogus output like:
Setting up grub-efi-amd64 (2.02~beta3-4) ...
Installing for x86_64-efi platform.
Could not delete variable: No space left on device
Could not prepare Boot variable: No space left on device
Installation finished. No error reported.
and then potentially unbootable systems. If efibootmgr fails, grub-install
should know that and report it!
We've been using similar patch in Debian now for some time, with no ill effects.
Signed-off-by: Steve McIntyre <93sam@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The `grub_util_exec_redirect_all` helper function can be used to
spawn an executable and redirect its output to some files. After calling
`fork()`, the parent will wait for the child to terminate with
`waitpid()` while the child prepares its file descriptors, environment
and finally calls `execvp()`. If something in the children's setup
fails, it will stop by calling `exit(127)`.
Calling `exit()` will cause any function registered via `atexit()` to be
executed, which is usually the wrong thing to do in a child. And
actually, one can easily observe faulty behaviour on musl-based systems
without modprobe(8) installed: executing `grub-install --help` will call
`grub_util_exec_redirect_all` with "modprobe", which obviously fails if
modprobe(8) is not installed. Due to the child now exiting and invoking
the `atexit()` handlers, it will clean up some data structures of the
parent and cause it to be deadlocked in the `waitpid()` syscall.
The issue can easily be fixed by calling `_exit(127)` instead, which is
especially designed to be called when the atexit-handlers should not be
executed.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Depending on the OS/libc, device macros are defined in different
headers. This change ensures we include the right one.
sys/types.h - BSD
sys/mkdev.h - Sun
sys/sysmacros.h - glibc (Linux)
glibc currently pulls sys/sysmacros.h into sys/types.h, but this may
change in a future release.
https://sourceware.org/ml/libc-alpha/2015-11/msg00253.html
This makes it impossible to read from stdin without controlling tty:
10:/mnt # echo -e passwd\\npasswd | setsid ./grub-mkpasswd-pbkdf2
Enter password:
Reenter password: ./grub-mkpasswd-pbkdf2: error: failure to read password.
10:/mnt
canonicalize_file_name clashed with gnulib function. Additionally
it was declared in 2 places: emu/misc.h and util/misc.h. Added
grub_ prefix and removed second declaration.
* grub-core/osdep/unix/getroot.c (strip_extra_slashes): Move inside
!defined (__GNU__).
(xgetcwd): Likewise.
* include/grub/emu/hostdisk.h (grub_util_hurd_get_disk_info)
[__GNU__]: Add prototype.
* util/getroot.c (grub_util_biosdisk_get_grub_dev) [__GNU__]: Format
long int using %ld rather than %d.
We need to hide "modprobe efivars" error output to avoid confusion. So
consolidate grub_util_exec_* into single function that can optionally redirect
all three standard descriptors and make all other functions compatibility
wrappers.
Also remove include/grub/osdep/exec_unix.h which does not appear to be used
anywhere.
references to mdadm from otherwise generic code.
(grub_util_exec_pipe): Likewise.
(grub_util_exec_pipe_stderr): Likewise.
* grub-core/osdep/unix/getroot.c (grub_util_pull_lvm_by_command):
This function calls vgs, not mdadm; adjust variable names
accordingly.
Add grub_util_disable_fd_syncs call to turn grub_util_fd_sync calls into
no-ops, and use it in programs that copy files but do not need to take
special care to sync writes (grub-mknetdir, grub-rescue,
grub-mkstandalone).
On my laptop, this reduces partmap_test's runtime from 1236 seconds to
204 seconds.
the function of these files exceeds what can be sanely handled in shell
in posix-comaptible way. Also writing it in C extends the functionality
to non-UNIX-like OS and minimal environments.
