Hello.
I'm trying to get grub_func_test PASS and have found, that it depends
on some pregenerated checksums (saved in grub-core/tests/checksums.h),
which itself depends on unifont. In my environment something differs
and checksums doesn't match.
I've found in git log that this file sometimes regen
Have you tried with win 10? Win 7 has problems with real uefi (from win 8). Mensagem original Assunto: AW: Grub2 EFI: compatibility with wimbootDe: jame88f...@gmx.dePara: 'Daniel Kiper' CC: grub-devel@gnu.orgNo it is windows UEFI 64bit on a UEFI 64bit platformit doesn't matter anyw
From: Carlo Caione
Add a new search.fs_type tool to search by GPT partition type UUID.
Signed-off-by: Carlo Caione
Signed-off-by: Will Thompson
---
docs/grub.texi | 14 ---
grub-core/Makefile.core.def | 5 +++
grub-core/commands/search.c | 69 +
This may be useful to locate a root partition by the GUID defined in the
Discoverable Partitions Specification.
https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
Endless moved away from using this technique because we have to support
non-GPT partition tables in some case
No it is windows UEFI 64bit on a UEFI 64bit platform
it doesn't matter anyway because even if I try to boot only Wimboot EFI from
Grub2 EFI without parameters I also get a blackscreen.
I mean:
menuentry "Windows 7" {
linux /boot/wimboot/wimboot
}
I can't get linux16 to work in EFI, can I?
On Wed, 20 Jun 2018 at 10:33 Daniel Kiper wrote:
> On Fri, Jun 15, 2018 at 06:34:04PM +0100, Will Thompson wrote:
> > 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.
On Fri, Jun 15, 2018 at 07:14:29PM +0200, jame88f...@gmx.de wrote:
> Okay,
> wimboot works in Grub2 Legacy for example:
>
> # Successfully boots
> menuentry "Windows 7" {
> set ISOpath="/img/windows_7.iso"
> loopback loop $ ISOpath
> linux16 /boot/wimboot/wimboot
> initrd16
On Thu, Jun 14, 2018 at 08:29:14PM +0200, Alexander Boettcher wrote:
> 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 se
On Fri, Jun 15, 2018 at 06:34:04PM +0100, Will Thompson wrote:
> 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
