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>
Recent tests have discovered that many of our filesystems have flawed
handling of "." and "..". Rather than attempting to fix it in filesystems
themselves, make the common code fshelp aware of "." and ".." and handle
them in this layer. Add grub_fshelp_find_file_lookup for easy conversion
of BFS, HFS and exFAT which have the same problem and don't use fshelp.
