minilzo fails to build on a number of Debian release architectures
(armel, mips64el, mipsel, ppc64el) with errors such as:
../../grub-core/lib/minilzo/minilzo.c: In function 'lzo_memops_get_le16':
../../grub-core/lib/minilzo/minilzo.c:3479:11: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
3479 | * (lzo_memops_TU2p) (lzo_memops_TU0p) (dd) = * (const lzo_memops_TU2p) (const lzo_memops_TU0p) (ss); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../grub-core/lib/minilzo/minilzo.c:3530:5: note: in expansion of macro 'LZO_MEMOPS_COPY2'
3530 | LZO_MEMOPS_COPY2(&v, ss);
| ^~~~~~~~~~~~~~~~
The latest upstream version is 2.10, so updating to it seems like a good
idea on general principles, and it fixes builds on all the above
architectures.
The update procedure documented in the GRUB Developers Manual worked; I
just updated the version numbers to make it clear that it's been
executed recently.
Signed-off-by: Colin Watson <cjwatson@debian.org>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Use the Git Book as a reference for documentation on Git as no other link
was provided. Other links were broken because they used @url instead of
@uref and needed a comma separator between link and link text.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Add a section with minimal description on setting up and running the test
suite with a link to the INSTALL documentation which is a little more
detailed in terms of package requirements.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The GRUB btrfs implementation can't handle two very basic btrfs
file layouts:
1. Mixed inline/regualr extents
# mkfs.btrfs -f test.img
# mount test.img /mnt/btrfs
# xfs_io -f -c "pwrite 0 1k" -c "sync" -c "falloc 0 4k" \
-c "pwrite 4k 4k" /mnt/btrfs/file
# umount /mnt/btrfs
# ./grub-fstest ./grub-fstest --debug=btrfs ~/test.img hex "/file"
Such mixed inline/regular extents case is not recommended layout,
but all existing tools and kernel can handle it without problem.
2. NO_HOLES feature
# mkfs.btrfs -f test.img -O no_holes
# mount test.img /mnt/btrfs
# xfs_io -f -c "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/btrfs/file
# umount /mnt/btrfs
# ./grub-fstest ./grub-fstest --debug=btrfs ~/test.img hex "/file"
NO_HOLES feature is going to be the default mkfs feature in the incoming
v5.15 release, and kernel has support for it since v4.0.
The way GRUB btrfs code iterates through file extents relies on no gap
between extents.
If any gap is hit, then GRUB btrfs will error out, without any proper
reason to help debug the bug.
This is a bad assumption, since a long long time ago btrfs has a new
feature called NO_HOLES to allow btrfs to skip the padding hole extent
to reduce metadata usage.
The NO_HOLES feature is already stable since kernel v4.0 and is going to
be the default mkfs feature in the incoming v5.15 btrfs-progs release.
When there is a extent gap, instead of error out, just try next item.
This is still not ideal, as kernel/progs/U-boot all do the iteration
item by item, not relying on the file offset continuity.
But it will be way more time consuming to correct the whole behavior than
starting from scratch to build a proper designed btrfs module for GRUB.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 23e39f50ca7a (disk/ldm: Make sure comp data is freed before exiting from
make_vg()) fixed several spots in make_vg() where comp data was leaking memory
when an error was being handled but missed one. To avoid leaking memory, comp
should be freed when an error is being handled after comp has been successfully
allocated memory in the for loop.
Fixes: 23e39f50ca7a (disk/ldm: Make sure comp data is freed before exiting from make_vg())
Fixes: CID 73804
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Commit 1fc860bb76bb (commands/probe: Fix a resource leak when probing disks),
missed other cases where grub_device_close() should be called before a return
statement is called. Also found that grub_disk_close() wasn't being called when
an error is being returned. To avoid conflict with grub_errno, grub_error_push()
should be called before either grub_device_close() or grub_disk_close() is
called and grub_error_pop() should be called before grub_errno is returned.
Fixes: 1fc860bb76bb (commands/probe: Fix a resource leak when probing disks)
Fixes: CID 292443
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The POSIX locale is default or native operating system's locale
identical to the C locale, so no translation to human speaking languages
are provided. For this reason we should filter out LANG=POSIX as well as
LANG=C upon generating grub.cfg to avoid looking up for it's gettext's
message catalogs that will consequently result in an unpleasant message:
error: file `/boot/grub/locale/POSIX.gmo' not found
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In huft_build() it is possible to reach the for loop where "r" is being
assigned to "q[j]" without "r.v" ever being initialized.
Fixes: CID 314024
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In zap_leaf_array_get() the chunk size passed in is considered tainted
by Coverity, and is being used before it is tested for validity. To fix
this the assignment of "la" is moved until after the test of the value
of "chunk".
Fixes: CID 314014
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the function write_font_pf2() memory is allocated for font_name to
construct a new name, but it is not released before returning from the
function, leaking the allocated memory.
Fixes: CID 314015
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the function cmd_cmp() within the while loop, srcnew and destnew are
being allocated but are never freed either before leaving scope or in
the recursive calls being made to cmd_cmp().
Fixes: CID 314032
Fixes: CID 314045
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the function write_part(), the value of inname is not used beyond
the grub_util_fopen() call, so it should be freed to avoid leakage.
Fixes: CID 314028
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The copy_all() function skips a section of code using continue, but
fails to free the memory in srcf first, leaking it.
Fixes: CID 314026
Signed-off-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Prior to this change, the GRUB would only indicate that the check had
been failed, but not by what module. This made it difficult to track
down either the problem module, or debug the false positive further.
Before performing the license check, resolve the module name so that
it can be printed if the license check fails.
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Adding the conditional to debug log messages allows the GRUB user to
construct the $debug variable without needing to consult the source to
find the conditional (especially useful for situations where the source
is not readily available).
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Many tests abort due to not being root or missing tools, for instance mkfs
commands for file system tests. The tests are exited with code 77, which
means they were skipped. A skipped test is a test that should not be run,
e.g. a test specific to ARM64 should not be run on an x86 build. These aborts
are actually a hard error, code 99. That means that the test could not be
completed, but not because what was supposed to be tested failed, e.g. in
these cases where a missing tool prevents the running of a test.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A recent refactoring of CUDA command code has exposed a bug in OpenBIOS [1]
which was causing system powerdown and system reset to fail, thus causing
the QEMU instance to hang. This in turn caused the grub-shell command to
timeout causing it to return an error code when the test actually completed
successfully.
Since it could be a while before the patch fixing this issue in OpenBIOS
filters down to the average distro, switch to PMU to allow powerdowns and
reboots to work as expected.
[1] https://gitlab.com/qemu-project/qemu/-/issues/624
Signed-off-by: Glenn Washburn <development@efficientek.com>
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
GET_ARRAY_INFO's info.nr_disks does not map to GET_DISK_INFO's
disk.number, which is an internal kernel index. If an array has had drives
added, removed, etc., there may be gaps in GET_DISK_INFO's results. But
since the consumer of devicelist cannot tolerate gaps (it expects to walk
a NULL-terminated list of device name strings), the devicelist index (j)
must be tracked separately from the disk.number index (i).
As part of this, since GRUB wants to only examine active (i.e. present
and non-failed) disks, the count of remaining disks (remaining) must be
tracked separately from the devicelist index (j).
Additionally, drop a line with empty spaces only.
Fixes: 49de079bbe1c (... (grub_util_raid_getmembers): Handle "removed" disks)
Fixes: 2b00217369ac (... Added support for RAID and LVM)
Fixes: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1912043
Fixes: https://savannah.gnu.org/bugs/index.php?59887
Signed-off-by: Kees Cook <kees@ubuntu.com>
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Many of the prerequisites for exercising the full "make check" test suite
have not been documented. This adds them along with a note that some tests
require elevated privileges to run.
Add an incomplete list of cross compiling toolchain packages for Debian
and trusted sources for other distros.
Add statement at the start of the document to clarify that package names
are from Debian 11.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The filesystem images created for the filesystem test can be useful when
debugging why a filesystem test failed. So, keep them around and let the
user clean them up.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Allow the HFS tests to not be skipped if the mac_roman modules is loaded in
the kernel, but not accessible to modprobe.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The ";", semi-colon, character is not a valid character for a FAT filesystem
label. This test used to succeed because prior to v4.2 of dosfstools
mkfs.vfat did not enforce the character restrictions for volume labels. So,
change the volume label string to be valid but contain symbol characters to
test odd volume labels.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Apparently there used to be a -B option for mkfs.minix to create a volume
with a specified block size. This version is hard to come by and does not
appear to be available in Debian distributions. So, remove support for
testing a variety of blocks sizes for MINIX3. This allows the MINIX tests
to run because they were being skipped due to not finding a mkfs.minix with
the -B option.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This bring this test in line with the rest of the test scripts.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
These tests were not performed and therefore did not pass, nor fail. This
fixes misleading test exit code where, for instance, the pseries_test will
pass on i386-pc, which is not a pseries architecture.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
A test exiting with code 99 means that there was an error in the test itself
and not a failure in the thing being tested (also known as a hard error).
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When a test program fails because it failed to setup the test properly, this
does not indicate a failure in what is attempting to be tested because the
test is never run. So exit with a hard error exit status to note this
difference. This will allow easier detection of tests that are not actually
being run and those that are really failing.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The script grub-shell does the bulk of the testing. If it returns an error
code, that means that the test failed and the test should immediately exit
with that error code. When grub-shell is used as a non-terminating command
in a pipeline, e.g. when data needs to be extracted from its output, its
error code will be occluded by the last command in the pipeline. Refactor
tests so that the shell will error with the exit code of grub-shell by
breaking up pipelines such that grub-shell is always the last command in
the pipeline that it is used in.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using the output of a subshell as input, its error code is ignored in
the context of "set -e". Many test scripts use grub-shell in a subshell with
output used as an argument to the test command to test for expected output.
Refactor these tests so that the subshell output goes to a shell variable,
so that if the subshell errors the script will immediately exit with an
error code.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This helps to ensure that error codes do not get ignored.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently, the filesystem timestamp check in grub-fs-tester uses the
squashfs image file's last modified timestamp and checks to see if that
time stamp is within 3 seconds of the superblock timestamp as determined by
grub. The image file's timestamp could be more than 3 seconds off if
mksquashfs takes more than 3 seconds to generate the image, as is the case
on a virtual machine. Instead use squashfs tools to get the filesystem
timestamp directly.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Perhaps using a newer UEFI firmware is the reason for the created test disk
showing up as hd2 instead of hd3.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The following procedure to build xen/pvgrub is broken.
git clone https://git.savannah.gnu.org/git/grub.git
cd grub
./bootstrap
mkdir build-xen
cd build-xen
../configure --with-platform=xen
make
It fails with the message:
/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
section .note.gnu.property VMA [0000000000400158,0000000000400187]
overlaps section .bss VMA [000000000000f000,000000000041e1af]
The most significant factor is that new assembler (GNU as) generates the
.note.gnu.property section as default. This note section overlaps with
.bss because it doesn't reposition with -Wl,-Ttext,0 with which the base
address of .text section is set, rather the address of .note.gnu.property
is calculated for some reason from 0x400000 where the ELF executable
defaults to start.
Using -Ttext-segment doesn't help either, though it is said to set the
address of the first byte of the text segment according to "man ld".
What it actually does is to override the default 0x400000, aka the image
base address, to something else. The entire process can be observed in
the default linker script used by gcc [1]. Therefore we can't expect it
to achieve the same thing as -Ttext given that the first segment where
.text resides is offset by SIZEOF_HEADERS plus some sections may be
preceding it within the first segment. The end result is .text always
has to start with non-zero address with -Wl,-Ttext-segment,0 if using
default linker script.
It is also worth mentioning that binutils upstream apparently doesn't
seem to consider this as a bug [2] and proposed to use -Wl,-Ttext-segment,0
which is not fruitful as what has been tested by Gentoo [3].
As long as GRUB didn't use ISA information encoded in .note.gnu.property,
we can safely drop it via -Wa,-mx86-used-note=no assembler option to
fix the linker error above.
This is considered a better approach than using custom linker script to
drop the .note.gnu.property section because object file manipulation can
also be hampered one way or the other in that linker script may not be
helpful. See also this commit removing the section in the process of objcopy.
6643507ce build: Fix GRUB i386-pc build with Ubuntu gcc
[1] In /usr/lib64/ldscripts/elf_x86_64.x or use 'gcc -Wl,--verbose ...'
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=27377
[3] https://bugs.gentoo.org/787221
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Currently the grub_diskfilter_memberlist() function returns all physical
volumes added to a volume group to which a logical volume (LV) belongs.
However, this is suboptimal as it doesn't fit the intended behavior of
returning underlying devices that make up the LV. To give a clear
picture, the result should be identical to running commands below to
display the logical volumes with underlying physical volumes in use.
localhost:~ # lvs -o lv_name,vg_name,devices /dev/system/root
LV VG Devices
root system /dev/vda2(512)
localhost:~ # lvdisplay --maps /dev/system/root
--- Logical volume ---
...
--- Segments ---
Logical extents 0 to 4604:
Type linear
Physical volume /dev/vda2
Physical extents 512 to 5116
As shown above, we can know system-root LV uses only /dev/vda2 to
allocate it's extents, or we can say that /dev/vda2 is the member device
comprising the system-root LV.
It is important to be precise on the member devices, because that helps
to avoid pulling in excessive dependency. Let's use an example to
demonstrate why it is needed.
localhost:~ # findmnt /
TARGET SOURCE FSTYPE OPTIONS
/ /dev/mapper/system-root ext4 rw,relatime
localhost:~ # pvs
PV VG Fmt Attr PSize PFree
/dev/mapper/data system lvm2 a-- 1020.00m 0
/dev/vda2 system lvm2 a-- 19.99g 0
localhost:~ # cryptsetup status /dev/mapper/data
/dev/mapper/data is active and is in use.
type: LUKS1
cipher: aes-xts-plain64
keysize: 512 bits
key location: dm-crypt
device: /dev/vdb
sector size: 512
offset: 4096 sectors
size: 2093056 sectors
mode: read/write
localhost:~ # vgs
VG #PV #LV #SN Attr VSize VFree
system 2 3 0 wz--n- 20.98g 0
localhost:~ # lvs -o lv_name,vg_name,devices
LV VG Devices
data system /dev/mapper/data(0)
root system /dev/vda2(512)
swap system /dev/vda2(0)
We can learn from above that /dev/mapper/data is an encrypted volume and
also gets assigned to volume group "system" as one of it's physical
volumes. And also it is not used by root device, /dev/mapper/system-root,
for allocating extents, so it shouldn't be taking part in the process of
setting up GRUB to access root device.
However, running grub-install reports error as volume group "system"
contains encrypted volume.
error: attempt to install to encrypted disk without cryptodisk
enabled. Set `GRUB_ENABLE_CRYPTODISK=y' in file `/etc/default/grub'.
Certainly we can enable GRUB_ENABLE_CRYPTODISK=y and move on, but that
is not always acceptable since the server may need to be booted unattended.
Additionally, typing passphrase for every system startup can be a big
hassle of which most users would like to avoid.
This patch solves the problem by returning exact physical volume, /dev/vda2,
rightly used by system-root from the example above, thus grub-install will
not error out because the excessive encrypted device to boot the root device
is not configured.
Signed-off-by: Michael Chang <mchang@suse.com>
Tested-by: Olav Reinert <seroton10@gmail.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When a file on ext4 is stored as sparse the data belonging to
zero-filled blocks is not written to storage and the extent map is
missing entries for these blocks. Such case can happen both for depth
0 extents (leafs) as well as higher-level tables.
Consider a scenario of a file which has a zero-filled beginning (e.g.
ISO image). In such case real data starts at block 8. If such a file is
stored using 2-level extent structure the extent list in the inode will
be depth 1 and will have an entry to a depth 0 (leaf) extent header for
blocks 8-n.
Unfortunately existing GRUB2 ext2 driver is only able to handle missing
entries in leaf extent tables, for which the grub_ext2_read_block()
function returns 0. In case the whole leaf extent list is missing for
a block the function fails with "invalid extent" error.
The fix for this problem relies on the grub_ext4_find_leaf() helper
function to distinguish two error cases: missing extent and error
walking through the extent tree. The existing error message is raised
only for the latter case, while for the missing leaf extent zero is
returned from grub_ext2_read_block() indicating a sparse block.
Signed-off-by: Krzysztof Nowicki <krzysztof.nowicki@nokia.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Open Hack'Ware was the only user. It added a lot of complexity.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Open Hack'Ware was an alternative firmware of powerpc under QEMU.
The last commit to any Open Hack'Ware repo I can find is from 2014 [1].
Open Hack'Ware was used for the QEMU "prep" machine type, which was
deprecated in QEMU in commit 54c86f5a4844 (hw/ppc: deprecate the
machine type 'prep', replaced by '40p') in QEMU v3.1, and had reportedly
been broken for years before without anyone noticing. Support was removed
in February 2020 by commit b2ce76a0730e (hw/ppc/prep: Remove the
deprecated "prep" machine and the OpenHackware BIOS).
Open Hack'Ware's limitations require some messy code in GRUB. This
complexity is not worth carrying any more.
Remove detection of Open Hack'Ware. We will clean up the feature flags
in following commits.
[1]: https://github.com/qemu/openhackware and
https://repo.or.cz/w/openhackware.git are QEMU submodules. They have
only small changes on top of OHW v0.4.1, which was imported into
QEMU SCM in 2010. I can't find anything resembling an official repo
any more.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
