VLAN configuration seems to have never worked on little-endian systems.
This is likely because VLANTAG_IDENTIFIER is not byte-swapped before
copying into the net buffer, nor is inf->vlantag. We can resolve this by
using grub_cpu_to_be16{_compile_time}() and its inverse when copying
VLAN info to/from the net buffer.
Signed-off-by: Chad Kimes <chkimes@github.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The EFI_IMAGE_SECURITY_DATABASE_GUID is used for the image execution
information table (cf. UEFI specification 2.9, 32.5.3.1 Using The Image
Execution Information Table).
The lsefisystab command is used to display installed EFI configuration
tables. Currently it only shows the GUID but not a short text for the
table.
Provide a short text for the EFI_IMAGE_SECURITY_DATABASE_GUID.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
To prevent infinite recursion when grub_mm_debug is on, disable it when
calling grub_vprintf(). One such call loop is:
grub_vprintf() -> parse_printf_args() -> parse_printf_arg_fmt() ->
grub_debug_calloc() -> grub_printf() -> grub_vprintf().
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In GNU ld and ld.lld, -d is used with -r to allocate space to COMMON symbols.
This behavior is presumably to work around legacy projects which inspect
relocatable output by themselves and do not handle COMMON symbols. The GRUB
does not do this.
See https://github.com/llvm/llvm-project/issues/53660
-d is quite useless and ld.lld 15.0.0 will make -d no-op.
COMMON symbols have special symbol resolution semantics which can cause surprise
(see https://maskray.me/blog/2022-02-06-all-about-common-symbols). GCC<10 and
Clang<11 defaulted to -fcommon. Just use -fno-common to avoid COMMON symbols.
Signed-off-by: Fangrui Song <maskray@google.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When using --no-floppy and a floppy was encountered, iterate_device()
was returning 1, causing the iteration to stop instead of continuing.
Signed-off-by: Renaud Métrich <rmetrich@redhat.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This is causing the test grub_cmd_date() to fail because the returned
date is one day more than it should be.
This reverts commit 607d66116 (iee1275/datetime: Fix off-by-1 error.).
Signed-off-by: Glenn Washburn <development@efficientek.com>
Tested-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In commit 178ac5107389 (affs: Fix memory leaks), fixes were made to
grub_affs_iterate_dir() to prevent memory leaks from occurring after it
returns without freeing node. However, there were still some instances
where node was causing a memory leak when the function returns after
calling grub_affs_create_node(). In this function, new memory is
allocated to node but doesn't get freed until the hook() function is
called near the end. Before hook() is called, node should be freed in
grub_affs_create_node() before returning out of it.
Fixes: 178ac5107389 (affs: Fix memory leaks)
Fixes: CID 73759
Signed-off-by: Alec Brown <alec.r.brown@oracle.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Allow the use of HTTP servers listening on ports other 80. This is done
with an extension to the http notation:
(http[,server[,port]])
- or -
(http[,server[:port]])
Signed-off-by: Stephen Balousek <sbalousek@wickedloop.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Sometimes you only know which debug logging facility names you want to
turn off, not necessarily all the ones you want enabled. This patch allows
the debug string to contain facility names in the $debug variable which are
prefixed with a "-" to disable debug log messages for that conditional. Say
you want all debug logging on except for btrfs and scripting, then do:
"set debug=all,-btrfs,-scripting"
Note, that only the last occurrence of the facility name with or without a
leading "-" is considered. So simply appending ",-facilityname" to the
$debug variable will disable that conditional. To illustrate, the command
"set debug=all,-btrfs,-scripting,btrfs" will enable btrfs.
Also, add documentation explaining this new behavior.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The Coverity output is:
*** CID 366905: Memory - illegal accesses (USE_AFTER_FREE)
/grub-core/disk/cryptodisk.c: 1064 in grub_cryptodisk_scan_device_real()
1058 cleanup:
1059 if (askpass)
1060 {
1061 cargs->key_len = 0;
1062 grub_free (cargs->key_data);
1063 }
>>> CID 366905: Memory - illegal accesses (USE_AFTER_FREE)
>>> Using freed pointer "dev".
1064 return dev;
1065 }
1066
1067 #ifdef GRUB_UTIL
1068 #include <grub/util/misc.h>
1069 grub_err_t
Here the "dev" variable can point to a freed cryptodisk device if the
function grub_cryptodisk_insert() fails. This can happen only on a OOM
condition, but when this happens grub_cryptodisk_insert() calls grub_free on
the passed device. Since grub_cryptodisk_scan_device_real() assumes that
grub_cryptodisk_insert() is always successful, it will return the device,
though the device was freed.
Change grub_cryptodisk_insert() to not free the passed device on failure.
Then on grub_cryptodisk_insert() failure, free the device pointer. This is
done by going to the label "error", which will call cryptodisk_close() to
free the device and set the device pointer to NULL, so that a pointer to
freed memory is not returned.
Fixes: CID 366905
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_mm_init_region() does some things that seem magical, especially
around region merging. Make it a bit clearer.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The grub_free() possesses a surprising number of quirks, and also
uses single-letter variable names confusingly to iterate through
the free list.
Document what's going on.
Use prev and cur to iterate over the free list.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Small allocations move the region's *first pointer. The comment
says that this happens for allocations under 64K. The code says
it's for allocations under 32K. Commit 45bf8b3a7549 changed the
code intentionally: make the comment match.
Fixes: 45bf8b3a7549 (* grub-core/kern/mm.c (grub_real_malloc): Decrease cut-off of moving the)
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When iterating through the singly linked list of free blocks,
grub_real_malloc() uses p and q for the current and previous blocks
respectively. This isn't super clear, so swap to using prev and cur.
This makes another quirk more obvious. The comment at the top of
grub_real_malloc() might lead you to believe that the function will
allocate from *first if there is space in that block.
It actually doesn't do that, and it can't do that with the current
data structures. If we used up all of *first, we would need to change
the ->next of the previous block to point to *first->next, but we
can't do that because it's a singly linked list and we don't have
access to *first's previous block.
What grub_real_malloc() actually does is set *first to the initial
previous block, and *first->next is the block we try to allocate
from. That allows us to keep all the data structures consistent.
Document that.
Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Up to now GRUB can only embed to the first 64 KiB before primary
superblock of btrfs, effectively limiting the GRUB core size. That
could consequently pose restrictions to feature enablement like
advanced zstd compression.
This patch attempts to utilize full unused area reserved by btrfs for
the bootloader outlined in the document [1]:
The first 1MiB on each device is unused with the exception of primary
superblock that is on the offset 64KiB and spans 4KiB.
Apart from that, adjacent sectors to superblock and first block group
are not used for embedding in case of overflow and logged access to
adjacent sectors could be useful for tracing it up.
This patch has been tested to provide out of the box support for btrfs
zstd compression with which GRUB has been installed to the partition.
[1] https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs(5)#BOOTLOADER_SUPPORT
Signed-off-by: Michael Chang <mchang@suse.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Call grub_partition_get_name() unconditionally to initialize the part
variable. Then part will only be NULL when grub_partition_get_name() errors.
Note that when source->partition is NULL, then grub_partition_get_name()
returns an allocated empty string. So no comma or partition will be printed,
as desired.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Note that cargs.search_uuid does not need to be initialized in various parts
of the cryptomount argument parsing, just once when cargs is declared with
a struct initializer. The previous code used a global variable which would
retain the value across cryptomount invocations.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The crypto device modules should only be setting up the crypto devices and
not getting user input. This has the added benefit of simplifying the code
such that three essentially duplicate pieces of code are merged into one.
Add documentation of passphrase option for cryptomount as it is now usable.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Previously, the cryptomount arguments were passed by global variable and
function call argument, neither of which are ideal. This change passes data
via a grub_cryptomount_args struct, which can be added to over time as
opposed to continually adding arguments to the cryptodisk scan and
recover_key.
As an example, passing a password as a cryptomount argument is implemented.
However, the backends are not implemented, so testing this will return a not
implemented error.
Also, add comments to cryptomount argument parsing to make it more obvious
which argument states are being handled.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
When a cryptmount is specified with a UUID, but no cryptodisk backends find
a disk with that UUID, return a more detailed message giving telling the
user that they might not have a needed cryptobackend module loaded.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Update such that "cryptomount -u UUID" will not print two error messages
when an invalid passphrase is given and the most relevant error message
will be displayed.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
This displays an error notifying the user that they'll want to load
a backend module to make cryptomount useful.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
The global "have_it" was never used by the crypto-backends, but was used to
determine if a crypto-backend successfully mounted a cryptodisk with a given
UUID. This is not needed however, because grub_device_iterate() will return
1 if and only if grub_cryptodisk_scan_device() returns 1. And
grub_cryptodisk_scan_device() will now only return 1 if a search_uuid has
been specified and a cryptodisk was successfully setup by a crypto-backend or
a cryptodisk of the requested UUID is already open.
To implement this grub_cryptodisk_scan_device_real() is modified to return
a cryptodisk or NULL on failure and having the appropriate grub_errno set to
indicated failure. Note that grub_cryptodisk_scan_device_real() will fail now
with a new errno GRUB_ERR_BAD_MODULE when none of the cryptodisk backend
modules succeed in identifying the source disk.
With this change grub_device_iterate() will return 1 when a crypto device is
successfully decrypted or when the source device has already been successfully
opened. Prior to this change, trying to mount an already successfully opened
device would trigger an error with the message "no such cryptodisk found",
which is at best misleading. The mount should silently succeed in this case,
which is what happens with this patch.
Signed-off-by: Glenn Washburn <development@efficientek.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
Create a library function for CloseProtocol() and use it for the SNP driver.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
In the context of the implementation of the EFI_LOAD_FILE2_PROTOCOL for
the initial ramdisk it was observed that opening the SNP protocol failed.
https://lists.gnu.org/archive/html/grub-devel/2021-10/msg00020.html
This is due to an incorrect call to CloseProtocol().
The first parameter of CloseProtocol() is the handle, not the interface.
We call OpenProtocol() with ControllerHandle == NULL. Hence we must also
call CloseProtcol() with ControllerHandel == NULL.
Each call of OpenProtocol() for the same network card handle is expected to
return the same interface pointer. If we want to close the protocol which
we opened non-exclusively when searching for a card, we have to do this
before opening the protocol exclusively.
As there is no guarantee that we successfully open the protocol add checks
in the transmit and receive functions.
Reported-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
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>
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>
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>
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>
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>
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>
