---
grub-core/fs/zfs/zfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/grub-core/fs/zfs/zfs.c b/grub-core/fs/zfs/zfs.c
index f9e755197..a29db8827 100644
--- a/grub-core/fs/zfs/zfs.c
+++ b/grub-core/fs/zfs/zfs.c
@@ -1881,8 +1881,8 @@ zio_read (blkptr_t *bp, grub_zfs_endi
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 74719416c..dba38d731 100644
--- a/configure.ac
+++ b/configure.ac
@@ -362,7 +362,7 @@ gl_EARLY
AC_PROG_CXX
AM_PROG_CC_C_O
AM_PROG_AS
-AM_PATH_PYTHON([2.6])
+AM_PATH_PYTHON([2.6
---
grub-core/lib/LzmaEnc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grub-core/lib/LzmaEnc.c b/grub-core/lib/LzmaEnc.c
index 52b331558..4636a9ffe 100644
--- a/grub-core/lib/LzmaEnc.c
+++ b/grub-core/lib/LzmaEnc.c
@@ -1358,7 +1358,7 @@ static UInt32 GetOptimum(CLzmaEnc *p
Hello,
I built GRUB on OpenBSD 6.9 over the weekend, and ran into a few
issues. The minor ones attached were easy enough to
fix. Unfortunately, once installed, it merely prints "Grub Loading"
(or something similar) and reboots. In trying to recover from this, I
wiped out the MBR and that's when I
On PowerVM, the first time we boot a Linux partition, we may only get
256MB of real memory area, even if the partition has more memory.
This isn't really enough. Fortunately, the Power Architecture Platform
Reference (PAPR) defines a method we can call to ask for more memory.
This is part of the b
On powerpc-ieee1275, we are running out of memory trying to verify
anything. This is because:
- we have to load an entire file into memory to verify it. This is
extremely difficult to change with appended signatures.
- We only have 32MB of heap.
- Distro kernels are now often around 30MB.
S
HEAP_MAX_ADDR is confusing. Currently it is set to 32MB, except
on ieee1275 on x86, where it is 64MB.
There is a comment which purports to explain it:
/* If possible, we will avoid claiming heap above this address, because it
seems to cause relocation problems with OSes that link at 4 MiB */
I've posted a couple of RFC patches that attempted to claim some more
memory on ieee1275 platforms, which is necessary for the verifiers to
do their work. The RFCs were a bit unsatisfactory and also it turns
out they broke in some corner cases.
This, I believe, is a proper, upstream-worthy solutio
On Tue, May 18, 2021 at 3:48 AM Jan (janneke) Nieuwenhuizen
wrote:
>
> This fixes cross-compiling to x86 (e.g., the Hurd) from x86-linux.
>
> To reproduce, update the Grub source description in your local Guix
> archive and run
>
>./pre-inst-env guix build --system=i686-linux --target=i586-pc-
On 5/18/21 4:35 PM, John Paul Adrian Glaubitz wrote:
> So I'm not sure what kind of host system we are talking about here? This looks
> more like a configuration issue of the distribution in question which
> deliberately
> builds its 32-bit toolchain without 64-bit support.
Hmm, I just noticed th
Hi Daniel!
On 5/18/21 4:26 PM, Daniel Kiper wrote:
> When I was looking at the issue first time I thought in the same way.
> Though after some thinking I realized that it is perfectly valid to
> start 64-bit kernel from 32-bit bootloader which was build in 32-bit
> environment. So, I think it make
Hey Adrian,
On Tue, May 18, 2021 at 12:58:07PM +0200, John Paul Adrian Glaubitz wrote:
> Hello Jan!
>
> On 5/18/21 12:47 PM, Jan (janneke) Nieuwenhuizen wrote:
> > or install an x86 cross-build environment on x86-linux (32bit!) and
> > configure to cross build and make, e.g., do something like
>
>
On 5/17/21 7:34 PM, Daniel Kiper wrote:
Did you test your patch outside of username login prompt, e.g. CLI or
menu entry editing? I am afraid your patch breaks at least these cases.
Daniel
Indeed I tested it with both CLI and menu entry editing and it works fine.
Thank you for taking the time
On Wed, May 12, 2021 at 08:24:44PM +0100, Dimitri John Ledkov wrote:
> Refactor clean_grub_dir to create a backup of all the files, instead
> of just irrevocably removing them as the first action. If available,
> register atexit handle to restore the backup if errors occur before
> point of no retu
Hello Jan!
On 5/18/21 12:47 PM, Jan (janneke) Nieuwenhuizen wrote:
> or install an x86 cross-build environment on x86-linux (32bit!) and
> configure to cross build and make, e.g., do something like
Are we talking about a toolchain which exclusively supports 32-bit builds
only? If yes, wouldn't it
Indeed I tested it with both CLI and menu entry editing and it works fine.
Thank you for taking the time to answer me.
PS Sorry if you received this message more than once.
Egor
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mail
This fixes cross-compiling to x86 (e.g., the Hurd) from x86-linux.
To reproduce, update the Grub source description in your local Guix
archive and run
./pre-inst-env guix build --system=i686-linux --target=i586-pc-gnu grub
or install an x86 cross-build environment on x86-linux (32bit!) and
co
Hello Jan!
On 5/18/21 7:05 AM, Jan Nieuwenhuizen wrote:
>>> Sure, sent separately to bug-grub.
>>
>> I cannot find your updated patch.
>
> It's here:
>
> https://lists.gnu.org/archive/html/bug-grub/2021-05/msg9.html
>
>> May I ask you to send it using "git-send-email" to grub-devel@gnu.
18 matches
Mail list logo
