We already check that jump over 300 bytes gap is 3 bytes in code16-mode.
Some clang versions generate 3-byte opcode for short jumps which makes
boot.img blow over 512-byte limit. Enforce -no-integrated-as in such cases
libgcrypt-grub shouldn't be modified directly anyway. With this patch
tarball without contrib can be unpacked on FAT and stay usable for
out-of-tree compile on full POSIX FS (compile on FAT not tested).
It is not possible to configure encrypted containers on multiple partitions of
the same disk; after the first one all subsequent fail with
disk/cryptodisk.c:978: already mounted as crypto0
Store partition offset in cryptomount descriptor to distinguish between them.
This did not cause real problem but is good for reproducible builds. I hit
it with recent bootinfoscript that displays embedded config; I was puzzled
by random garbage at the end.
Prezero memory buffer used to assemble core.img. This makes individual
memset redundant. Also ensure buffer is filled with zeroes in several other
places.
Also remove redundant zeroing code where we fill in the whole memory block
anyway.
GRUB code expects O32 or N32. N32 is less tested than O32, so we prefer to
compile with O32. Some systems (e.g. GNU Guix) default to using newer
n64 or n32 ABI. Try to find suitable options to force o32.
For GCC this is simply -mabi=32. While clang supports this option as well,
o32 ABI is valid for MIPS target and n32/64 ABI are valid for MIPS64 target
only, so use "-target mips/mipsel -mabi=32".
Reported-By: Mark H Weaver <mhw@netris.org>
Also-By: Mark H Weaver <mhw@netris.org>
From original patch by dann frazier <dann.frazier@canonical.com>:
grub_net_fs_open() saves off a copy of the file structure it gets passed and
uses it to create a bufio structure. It then overwrites the passed in file
structure with this new bufio structure. Since file->name doesn't get set
until we return back to grub_file_open(), it means that only the bufio
structure gets a valid file->name. The "real" file's name is left
uninitialized. This leads to a crash when the progress module hook is called
on it.
grub_net_fs_open() already saved copy of file name as ->net->name, so change
progress module to use it.
Also, grub_file_open may leave file->name as NULL if grub_strdup fails. Check
for it.
Also-By: dann frazier <dann.frazier@canonical.com>
It cannot work anyway because host disk cannot be read. This fixes hostfs access
on native Windows build where filenames start with '\' or do not have initial
separator at all (d:\foo).
Issue was observed when running grub-fstest on Windows. On UNIX image name is
canonicalized to always start with `/' so this was not noticed.
This has side effect of allowing relative path names on host, but this already
was the case with `ls' command, so it just extends it to all commands.
Reported-By: Arch Stack <archstacker@gmail.com>
Also-By: Arch Stack <archstacker@gmail.com>
sun4v vnet devices do not implement the support of duplex and speed
instance attributes. An attempt to open such a device with
the attributes will fail:
ok select net:speed=auto,duplex=auto
Unknown key 'speed'
Unknown key 'duplex'
Manual Configuration: Host IP, boot server and filename must be specified
WARNING: /virtual-devices@100/channel-devices@200/network@0: Can't open OBP standard TFTP package
Can't open device
ok
Therefore, let's not set SUFFIX for such devices.
Signed-off-by: Stanislav Kholmanskikh <stanislav.kholmanskikh@oracle.com>
Incorrect drive name was being passed into grub_util_sparc_setup,
causing the grub-install to fail.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
The EFI spec indicates that get_status() should return the address of the buffer
we passed into transmit to indicate the the buffer was transmitted. However we
have boxes where the firmware returns some arbitrary address instead, which
makes grub think that we've not sent anything. So since we have the SNP stuff
opened in exclusive mode just assume any non-NULL txbuf means that our transmit
occurred properly. This makes grub able to do its networking stuff properly on
our broken firmware. Thanks,
cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>