When booting from NVME SSD with 4k sector size, it fails with the message.
error: attempt to read or write outside of partition.
This patch fixes the problem by fixing overflow in converting partition start
and length into 512B blocks.
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When reading data off a disk, sector values are based on the disk sector
length.
Within grub_util_fd_open_device(), the start of the partition was taken
directly from grub's partition information structure, which uses the
internal sector length (currently 512b), but never transformed to the
disk's sector length.
Subsequent calculations were all wrong for devices that have a diverging
sector length and the functions eventually skipped to the wrong stream
location, reading invalid data.
Signed-off-by: Mihai Moldovan <ionic@ionic.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
gentpl.py is python2/3-agnostic, but there's no way to cause it
to be run with any interpreter other than 'python', it's just
hard-coded into Makefile.common that way. Adjust that to use
AM_PATH_PYTHON (provided by automake) to find an interpreter
and run gentpl.py with that instead. This makes grub buildable
when `python` does not exist (but rather `python3` or `python2`
or `python2.7`, etc.) Minimum version is set to 2.6 as this is
the first version with `__future__.print_function` available.
Note, AM_PATH_PYTHON respects the PYTHON environment variable
and will treat its value as the *only* candidate for a valid
interpreter if it is set - when PYTHON is set, AM_PATH_PYTHON
will not try to find any alternative interpreter, it will only
check whether the interpreter set as the value of PYTHON meets
the requirements and use it if so or fail if not. This means
that when using grub's `autogen.sh`, as it too uses the value
of the PYTHON environment variable (and if it is not set, just
sets it to 'python') you cannot rely on AM_PATH_PYTHON
interpreter discovery. If your desired Python interpreter is
not just 'python', you must set the PYTHON environment variable,
e.g. 'PYTHON=/usr/local/bin/python3 ./autogen.sh'. The specified
interpreter will then be used both by autogen.sh itself and by
the autotools-driven build scripts.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
pkg-config is apparently preferred over freetype-config these days (see
the BUGS section of freetype-config(1)). pkg-config support was added
to FreeType in version 2.1.5, which was released in 2003, so it should
comfortably be available everywhere by now.
We no longer need to explicitly substitute FREETYPE_CFLAGS and
FREETYPE_LIBS, since PKG_CHECK_MODULES does that automatically.
Fixes Debian bug #887721.
Reported-by: Hugh McMaster <hugh.mcmaster@outlook.com>
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Using FREETYPE_CFLAGS and FREETYPE_LIBS is more in line with the naming
scheme used by pkg-config macros.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Code later on checks if variables inside the struct are
0 to see if they have been set, like if there were addresses
in the bootpath.
The variables were not initialized however, so the check
might succeed with uninitialized data, and a new interface
with random addresses and the same name is added. This causes
$net_default_mac to point to the random one, so, for example,
using that variable to load per-mac config files fails.
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1785859
Signed-off-by: Julian Andres Klode <julian.klode@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The "for the next boot only" property of grub-reboot is dependent upon
GRUB being able to clear the next_entry variable in the environment
block. However, GRUB cannot write to devices using the diskfilter
and lvm abstractions.
Ref: https://lists.gnu.org/archive/html/grub-devel/2009-12/msg00276.html
Ref: https://bugs.launchpad.net/bugs/788298
Signed-off-by: dann frazier <dann.frazier@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is a cryptographically signed message in MIME format.
Date: Thu, 9 Aug 2018 07:27:35 +0200
Currently, the GRUB payload for coreboot does not detect the Western
Digital hard disk WDC WD20EARS-60M AB51 connected to the ASRock E350M1,
as that takes over ten seconds to spin up.
```
disk/ahci.c:533: port 0, err: 0
disk/ahci.c:539: port 0, err: 0
disk/ahci.c:543: port 0, err: 0
disk/ahci.c:549: port 0, offset: 120, tfd:80, CMD: 6016
disk/ahci.c:552: port 0, err: 0
disk/ahci.c:563: port 0, offset: 120, tfd:80, CMD: 6016
disk/ahci.c:566: port: 0, err: 0
disk/ahci.c:593: port 0 is busy
disk/ahci.c:621: cleaning up failed devs
```
GRUB detects the drive, when either unloading the module *ahci*, and
then loading it again, or when doing a warm reset.
As the ten second time-out is too short, increase it to 32 seconds,
used by SeaBIOS. which detects the drive successfully.
The AHCI driver in libpayload uses 30 seconds, and that time-out was
added in commit 354066e1 (libpayload: ahci: Increase timeout for
signature reading) with the description below.
> We can't read the drives signature before it's ready, i.e. spun up.
> So set the timeout to the standard 30s. Also put a notice on the
> console, so the user knows why the signature reading failed.
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
1. move relocator related code more close to each other
2. use variable "len" since it has correct assignment, and keep coding
style with upper code
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
qemu 2.12 removed the -usbdevice option. Use a more modern spelling
instead, in line with other USB-related tests.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
SeaBIOS 1.11.0 added support for VGA emulation over a serial port, which
interferes with grub-shell. Turn it off.
Signed-off-by: Colin Watson <cjwatson@ubuntu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Make it so that when grub-module-verifier complains of an issue, it tells you
which module the issue was with.
Signed-off-by: Peter Jones <pjones@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Delete local copy of function to determine required buffer size for the
UEFI memory map, use helper in kern/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 0ba90a7f01 ("efi: Move grub_reboot() into kernel") broke
the build on i386-efi - genmoddep.awk bails out with message
grub_reboot in reboot is duplicated in kernel
This is because both lib/i386/reset.c and kern/efi/efi.c now provide
this function.
Rather than explicitly list each i386 platform variant in
Makefile.core.def, include the contents of lib/i386/reset.c only when
GRUB_MACHINE_EFI is not set.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The 32-bit arm Linux kernel is built as a zImage, which self-decompresses
down to near start of RAM. In order for an initrd/initramfs to be
accessible, it needs to be placed within the first ~768MB of RAM.
The initrd loader built into the kernel EFI stub restricts this down to
512MB for simplicity - so enable the same restriction in grub.
For arm64, the requirement is within a 1GB aligned 32GB window also
covering the (runtime) kernel image. Since the EFI stub loader itself
will attempt to relocate to near start of RAM, force initrd to be loaded
completely within the first 32GB of RAM.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The 32-bit arm efi port now shares the 64-bit linux loader, so delete
the now unused bits from the 32-bit linux loader.
This in turn leaves the grub-core/kern/arm/efi/misc.c unused, so
delete that too.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The arm64 and arm linux kernel EFI-stub support presents pretty much
identical interfaces, so the same linux loader source can be used for
both architectures.
Switch 32-bit ARM UEFI platforms over to the existing EFI-stub aware
loader initially developed for arm64.
This *WILL* stop non-efistub Linux kernels from booting on arm-efi.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In preparation for using the linux loader for 32-bit and 64-bit platforms,
rename grub_arm64*/GRUB_ARM64* to grub_armxx*/GRUB_ARMXX*.
Move prototypes for now-common functions to efi/efi.h.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Since ARM platforms do not have a common memory map, add a helper
function that finds the lowest address region with the EFI_MEMORY_WB
attribute set in the UEFI memory map.
Required for the arm64 efi linux loader to restrict the initrd
location to where it will be accessible by the kernel at runtime.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
There are several implementations of this function in the tree.
Add a central version in grub-core/efi/mm.c.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI Graphics Output Protocol can return a 64-bit
linear frame buffer address in some firmware/BIOS
implementations. We currently only store the lower
32-bits in the lfb_base. This will eventually be
passed to Linux kernel and the efifb driver will
incorrectly interpret the framebuffer address as
32-bit address.
The Linux kernel has already added support to handle
64-bit linear framebuffer address in the efifb driver
since quite some time now.
This patch adds the support for 64-bit linear frame
buffer address in GRUB to address the above mentioned
scenario.
Signed-off-by: Arindam Nath <arindam.nath@amd.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Clean up code for matching IS_ARM64 slightly by making use of struct
linux_arm64_kernel_header and GRUB_LINUX_ARM64_MAGIC_SIGNATURE.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Clean up code for matching IS_ARM slightly by making use of struct
linux_arm_kernel_header and GRUB_LINUX_ARM_MAGIC_SIGNATURE.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Most 8" or 7" x86 Windows 10 tablets come with volume up/down buttons and
a power-button. In their UEFI these are almost always mapped to arrow
up/down and enter.
Pressing the volume buttons (sometimes by accident) will stop the
menu countdown, but the power-button / "enter" key was not being recognized
as enter, so the user would be stuck at the grub menu.
The problem is that these tablets send scan_code 13 or 0x0d for the
power-button, which officialy maps to the F3 key. They also set
unicode_char to 0x0d.
This commit recognizes the special case of both scan_code and unicode_char
being set to 0x0d and treats this as an enter key press.
This fixes things getting stuck at the grub-menu and allows the user
to choice a grub-menu entry using the buttons on the tablet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Variable "root" is initialized after root device probing and is null in
current place, so, drop it.
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Without that fix we have:
In file included from ../../include/grub/command.h:25:0,
from ../../grub-core/loader/multiboot.c:30:
../../grub-core/loader/multiboot_elfxx.c: In function 'grub_multiboot_load_elf64':
../../grub-core/loader/multiboot_elfxx.c:130:28: error: 'relocatable' undeclared (first use in this function)
"load_base_addr=0x%x\n", relocatable,
This happens due to mistake in the commit 14ec665
(mbi: Use per segment a separate relocator chunk).
So, let's fix it.
Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@no-log.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
When booting an arm* system on UEFI with an empty device tree (currently
only when hardware description comes from ACPI), we don't currently set
default to 1 cell (32 bits).
Set both of these properties, to 2 cells (64 bits), to resolve issues
with kexec on some platforms.
This change corresponds with linux kernel commit ae8a442dfdc4
("efi/libstub/arm*: Set default address and size cells values for an empty dtb")
and ensures booting through grub does not behave differently from booting
the stub loader directly.
See also https://patchwork.kernel.org/patch/9561201/
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To be able to resuse the prop_entry_size macro, move it to
<grub/fdt.h> and rename it grub_fdt_prop_entry_size.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
If something else on the system is using loopback devices, then the
device that's free at the call to `losetup -f` may not be free in the
following call to try to use it. Instead, find and use the first free
loopback device in a single call to losetup.
Signed-off-by: Will Thompson <wjt@endlessm.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Instead of setting up a all comprising relocator chunk for all segments,
use per segment a separate relocator chunk.
Currently, if the ELF is non-relocatable, a single relocator chunk will
comprise memory (between the segments) which gets overridden by the relst()
invocation of the movers code in grub_relocator16/32/64_boot().
The overridden memory may contain reserved ranges like VGA memory or ACPI
tables, which may lead to crashes or at least to strange boot behaviour.
Signed-off-by: Alexander Boettcher <alexander.boettcher@genode-labs.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 51be337 (templates: Update grub script template files)
lacked one "]", so, add it.
Reported-by: Philip <philm@manjaro.org>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
The sparse inode metadata format became a mkfs.xfs default in
xfsprogs-4.16.0, and such filesystems are now rejected by grub as
containing an incompatible feature.
In essence, this feature allows xfs to allocate inodes into fragmented
freespace. (Without this feature, if xfs could not allocate contiguous
space for 64 new inodes, inode creation would fail.)
In practice, the disk format change is restricted to the inode btree,
which as far as I can tell is not used by grub. If all you're doing
today is parsing a directory, reading an inode number, and converting
that inode number to a disk location, then ignoring this feature
should be fine, so I've added it to XFS_SB_FEAT_INCOMPAT_SUPPORTED
I did some brief testing of this patch by hacking up the regression
tests to completely fragment freespace on the test xfs filesystem, and
then write a large-ish number of inodes to consume any existing
contiguous 64-inode chunk. This way any files the grub tests add and
traverse would be in such a fragmented inode allocation. Tests passed,
but I'm not sure how to cleanly integrate that into the test harness.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Tested-by: Chris Murphy <lists@colorremedies.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>
Rounding up the bufio->block_size to meet power of 2 to facilitate next_buf
calculation in grub_bufio_read().
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update grub-mkconfig.in and 10_linux.in to support grub-probe's new
partuuid target. Update grub.texi documentation. The following table
shows how GRUB_DISABLE_LINUX_UUID, GRUB_DISABLE_LINUX_PARTUUID, and
initramfs detection interact:
Initramfs GRUB_DISABLE_LINUX_PARTUUID GRUB_DISABLE_LINUX_UUID Linux Root
detected Set Set ID Method
false false false part UUID
false false true part UUID
false true false dev name
false true true dev name
true false false fs UUID
true false true part UUID
true true false fs UUID
true true true dev name
Note: GRUB_DISABLE_LINUX_PARTUUID and GRUB_DISABLE_LINUX_UUID equate to
'false' when unset or set to any value other than 'true'.
GRUB_DISABLE_LINUX_PARTUUID defaults to 'true'.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add PARTUUID detection support grub-probe for MBR and GPT partition schemes.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Rename grub_gpt_part_type to grub_gpt_part_guid and update grub_gpt_partentry
to use this type for both the partition type GUID string and the partition GUID
string entries. This change ensures that the two GUID fields are handled more
consistently and helps to simplify the changes needed to add Linux partition
GUID support.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Define print_gpt_guid(), so there is a central function for printing
GUID strings. This change is a precursor for later patches which rely
on this logic.
Signed-off-by: Nicholas Vinson <nvinson234@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
With --disable-nls no locales exist.
Avoid runtime error by moving code that copies locales into its own
function. Return early in case nls was disabled. That way the compiler
will throw away unreachable code, no need to put preprocessor
conditionals everywhere to avoid warnings about unused code.
Fix memleak by freeing srcf and dstf.
Convert tabs to spaces in moved code.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
diskboot.img now is loaded at 0x8000 and is jumped to with 0:0x8000.
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
"F2FS (Flash-Friendly File System) is flash-friendly file system which was merged
into Linux kernel v3.8 in 2013.
The motive for F2FS was to build a file system that from the start, takes into
account the characteristics of NAND flash memory-based storage devices (such as
solid-state disks, eMMC, and SD cards).
F2FS was designed on a basis of a log-structured file system approach, which
remedies some known issues of the older log structured file systems, such as
the snowball effect of wandering trees and high cleaning overhead. In addition,
since a NAND-based storage device shows different characteristics according to
its internal geometry or flash memory management scheme (such as the Flash
Translation Layer or FTL), it supports various parameters not only for
configuring on-disk layout, but also for selecting allocation and cleaning
algorithm.", quote by https://en.wikipedia.org/wiki/F2FS.
The source codes for F2FS are available from:
http://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.githttp://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs-tools.git
This patch has been integrated in OpenMandriva Lx 3.
https://www.openmandriva.org/
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When building with GCC 8, there are several errors regarding packed-not-aligned.
./include/grub/gpt_partition.h:79:1: error: alignment 1 of ‘struct grub_gpt_partentry’ is less than 8 [-Werror=packed-not-aligned]
This patch fixes the build error by cleaning up the ambiguity of placing
aligned structure in a packed one. In "struct grub_btrfs_time" and "struct
grub_gpt_part_type", the aligned attribute seems to be superfluous, and also
has to be packed, to ensure the structure is bit-to-bit mapped to the format
laid on disk. I think we could blame to copy and paste error here for the
mistake. In "struct efi_variable", we have to use grub_efi_packed_guid_t, as
the name suggests. :)
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Michael Chang <mchang@suse.com>
Tested-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A GPU inserted into a PCIe I/O slot disappears during system startup.
The problem centers around GRUB and a specific VGA init function in
efi_uga.c. This causes an LER (Link Error Recorvery) because the MMIO
memory has not been enabled before attempting access.
The fix is to add the same coding used in other VGA drivers, specifically
to add a check to insure that it is indeed a VGA controller. And then
enable the MMIO address space with the specific bits.
Signed-off-by: Mike Travis <mike.travis@hpe.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Read from NULL pointer canon in function grub_machine_get_bootlocation().
Function grub_ieee1275_canonicalise_devname() may return NULL.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Split up some of the functionality in grub_machine_get_bootlocation into
grub_ieee1275_get_boot_dev. This will allow for code reuse in a follow on
patch.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
