Daniel Kiper on Thu, 2025/05/08 19:02:
> [...] Now all the GRUB2 upstream patches are in
> the GRUB2 git repository [2] too.
>
> [...]
>
> [2] https://git.savannah.gnu.org/gitweb/?p=grub.git
> https://git.savannah.gnu.org/git/grub.git
Does not look like... The last commit is still
4abac0ad5a
Daniel Kiper on Fri, 2025/02/28 13:57:
> On Thu, Feb 27, 2025 at 11:03:44AM +0100, Christian Hesse wrote:
> > Daniel Kiper via Grub-devel on Mon, 2025/02/24
> > 15:34:
> > > > [...]
> > > > The current situation is just insane.
> > >
> >
Daniel Kiper via Grub-devel on Mon, 2025/02/24 15:34:
> > [...]
> > The current situation is just insane.
>
> I can understand your frustration but I am afraid we are not able to do
> much about it at this point. Sorry... We have problems with finding
> people doing security patches, forward po
Glenn Washburn on Fri, 2025/02/21 01:33:
> > It failed for my co-maintainer in 2 cases:
> >
> > - loopback device seems to be broken
> >
> > - encrypted devices is not working anymore for him
>
> These two issues are news to me. Were these failed tests using the
> latest security patch series
Daniel Kiper via Grub-devel on Tue, 2025/02/18 19:00:
> I am posting all the GRUB2 upstream patches which fix all security bugs
> found and reported up until now. Major Linux distros carry or will carry
> soon one form or another of these patches. Now all the GRUB2 upstream
> patches are in the GR
Michael Chang via Grub-devel on Fri, 2025/02/21 15:55:
> > - encrypted devices is not working anymore for him
>
> I have no idea about this. Is there any error message that could help to
> understand how it failed?
Actually I can no longer reproduce. %-p
Last time I had to recover quickly and
)
>
> Signed-off-by: Michael Chang
Tested and it fixes reading from loopback disk on ext4 for me. Thanks!
Tested-by: Christian Hesse
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*
Michael Chang via Grub-devel on Fri, 2025/02/21 15:55:
> On Thu, Feb 20, 2025 at 12:27:12PM +0100, Tobias Powalowski via Grub-devel
> wrote:
> > It failed for my co-maintainer in 2 cases:
> >
> > - loopback device seems to be broken
>
> Is the loopback file placed on an ext2/3/4 file system?
Robin Candau on Fri, 2023/06/16 12:48:
> Le 16/06/2023 à 12:35, Daniel Kiper a écrit :
> > On Fri, Jun 16, 2023 at 09:15:19AM +0200, Robin Candau wrote:
> >> Le 15/06/2023 à 23:36, Christian Hesse a écrit :
> >>> Daniel Kiper on Thu, 2023/06/15 17:05:
Daniel Kiper on Thu, 2023/06/15 16:45:
> The commit bb4aa6e06 (efi: Drop all uses of efi_call_XX() wrappers) did
> not add some __grub_efi_api attributes to the EFI calls. Lack of them
> led to hangs on x86_64-efi target. So, let's add missing __grub_efi_api
> attributes.
>
> Fixes: bb4aa6e06 (ef
Daniel Kiper on Thu, 2023/06/15 17:05:
> > It looks I was able to reproduce this problem. I will be checking what
> > is going on in following days...
>
> Here [1] is the fix. Please test...
Works for me, thanks!
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"C
Ard Biesheuvel on Tue, 2023/05/23 17:31:
> Now that GCC can generate function calls using the correct calling
> convention for us, we can stop using the efi_call_XX () wrappers, and
> just dereference the function pointers directly.
>
> This avoids the untyped variadic wrapper routines, which mea
Daniel Axtens on Sat, 2022/12/03 01:41:
> Please try the following:
>
> diff --git a/grub-core/fs/f2fs.c b/grub-core/fs/f2fs.c
> index df6beb544cbd..855e24618c2b 100644
> --- a/grub-core/fs/f2fs.c
> +++ b/grub-core/fs/f2fs.c
> @@ -650,7 +650,7 @@ get_blkaddr_from_nat_journal (struct grub_f2fs_dat
From: Christian Hesse
In addition to C locale there is also C.UTF-8 locale now. Filter that as
well, by using ${grub_lang}, which contains a stripped value.
This fixes the following message and resulting boot failure:
error: file `/boot/grub/locale/C.gmo' not found.
Signed-o
Daniel Kiper on Wed, 2020/07/29 19:00:
> I am posting all the GRUB2 upstream patches which fixes all security bugs
> found and reported up until now. Major Linux distros carry or will carry
> soon one form or another of these patches. Now all the GRUB2 upstream
> patches are in the GRUB2 git repos
adrian15 on Fri, 2019/04/12 07:37:
> --target="i386-pe" \
No idea if it make a difference, but I guess this should read "i386-pc"?
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-
"Vladimir 'phcoder' Serbinenko" on Tue, 2019/04/09 20:53:
> Hello all. GRUB maintainers team is proud to announce 2.04~rc1 that we
> have just released.
>
> We’re not aware of any of the release-critical bugs but we’re sure
> that there are some so we need your help finding them.
Built an Arch L
Brian Finn on Tue, 2018/07/17 23:42:
> Hey grub-devel,
>
>
> I see that grub2 releases on ftp://ftp.gnu.org/gnu/grub/ have detached
> signatures, but I can't find the corresponding public key anywhere. gpg
> tells me I should be looking for key ID E82E4209. Can any of you point me
> in the right
ther.
> >
> > This also makes a minor update to ensure that UUID partition labels
> > stay disabled when no initrd image is found, even if early images are
> > present.
> >
> > This is a continuation of a previous patch published by Christian
> > Hesse in 201
Theodore Ts'o on Fri, 2017/06/23 15:53:
> +grub-devel
>
> On Sat, Jun 10, 2017 at 04:00:20PM +0200, Felipe A Rodriguez wrote:
> > Upgrading from e2fsprogs-1.42.13 to e2fsprogs-1.43.4 causes the boot
> > loader to fail (unknown filesystem error) on the x86_64 VM I use for
> > initial testing. I t
"Vladimir 'phcoder' Serbinenko" on Fri, 2017/02/03 16:21:
> You're right. Looks like it got truncated. I'm going to repush when I get
> to the hotel
Thanks!
--
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*
Hello everybody,
just wanted to build grub from git master / tag 2.02-rc1. Looks like
checksums.h is truncated... This broke with commit fcb1528d93.
--
main(a){char*c=/*Schoene Gruesse */"C7?Bj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a
Christian Hesse on Mon, 2016/02/08 09:30:
>initrd=
> + for i in ${GRUB_CUSTOM_INITRD}; do
To hardcode know images we could add file names here...
[...]
for i in intel-ucode.img ${GRUB_CUSTOM_INITRD}; do
[...]
--
main(a){char*c=/*Schoene Gruesse */&quo
Signed-off-by: Christian Hesse
---
docs/grub.texi | 6 ++
util/grub-mkconfig.in | 1 +
util/grub.d/10_linux.in | 19 +--
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 0afdd8c..f65647c 100644
--- a/docs
"Vladimir 'phcoder' Serbinenko" on Fri, 2016/02/05 18:23:
> What is the name of ucode? What takes care of putting it under /boot? Can
> we just add ucode if it's under standard name under /boot and not have
> extra config? Ucode is something highly technical and we don't want user to
> bother abou
Andrei Borzenkov on Sat, 2016/02/06 09:51:
> > Nevertheless I have another use case:
> > I do use Yubikeys in challenge/response mode to open my LUKS encrypted
> > partition. [1] (This is not specific for mkinitcpio but works with dracut
> > as well.) The challenges are stored in an extra initramf
Andrei Borzenkov on Fri, 2016/02/05 20:04:
> 05.02.2016 13:43, Christian Hesse пишет:
> > From: Christian Hesse
> >
> > Signed-off-by: Christian Hesse
> > ---
> > docs/grub.texi | 6 ++
> > util/grub-mkconfig.in | 1 +
> > util/gr
From: Christian Hesse
Signed-off-by: Christian Hesse
---
docs/grub.texi | 6 ++
util/grub-mkconfig.in | 1 +
util/grub.d/10_linux.in | 16 +---
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 0afdd8c..f65647c
28 matches
Mail list logo
