Bug 1900233 - Grub fails to boot with tpm.c errors
Hi all, Apologies if I'm doing this wrong but I've never had to contact you before. There is a bug that was logged on RedHat Bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1900233 Which a user and myself both have the same issue. I'm running a Lenovo C940 and if I recall he has a C740. The poster thepiguy did a fair bit of back and forth with the Fedora team to identify where and how this was happening but deemed it not a Fedora specific issue as with the right conditions the same issue was present in Arch. I wanted to bring this to your attention as I'd like to help solve this issue if possible as it's a very annoying issue and I don't want to disable my TPM to work around it (As some have suggested on another post in the Fedora forum) https://ask.fedoraproject.org/t/grub-core-error-you-need-to-load-the-kernel-first/14405 Again apologies if I've raised this with you incorrectly and please let me know if there's anything I can do to assist. Kind regards, Bruno ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/2] osdep: Introduce major.h and use it
On Thu, Jul 15, 2021 at 05:35:27PM +0200, Petr Vorel wrote:
> to factor out fix for glibc 2.25 introduced in 7a5b301e3 ("build: Use
> AC_HEADER_MAJOR to find device macros").
>
> NOTE: Once glibc 2.25 is old enough and this fix is not needed also
> AC_HEADER_MAJOR in configure.ac should be removed.
>
> Signed-off-by: Petr Vorel
Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 2/2] linux/hostdisk: use stat() instead of udevadm for partition lookup
On Thu, Jul 15, 2021 at 05:35:28PM +0200, Petr Vorel wrote: > From: Jeff Mahoney > > sysfs_partition_path() calls udevadm to resolve the sysfs path for > a block device. That can be accomplished by stating the device node > and using the major/minor to follow the symlinks in /sys/dev/block/. > > This cuts the execution time of grub-mkconfig to somewhere near 55% on > system without LVM (which uses libdevmapper instead sysfs_partition_path()). > > Signed-off-by: Jeff Mahoney > [ pvorel: remove udevadm fallback as it does not help us more than > calling stat() directly; include , update commit > message. ] > Signed-off-by: Petr Vorel Reviewed-by: Daniel Kiper Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/4] ieee1275: drop HEAP_MAX_ADDR, HEAP_MIN_SIZE
On Tue, Jul 20, 2021 at 05:14:46PM -0400, Stefan Berger wrote:
> From: Daniel Axtens
>
> 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 */
>
> This doesn't make a lot of sense when the constants are well above 4MB
> already. It was not always this way. Prior to
> commit 7b5d0fe4440c ("Increase heap limit") in 2010, HEAP_MAX_SIZE and
> HEAP_MAX_ADDR were indeed 4MB. However, when the constants were increased
> the comment was left unchanged.
>
> It's been over a decade. It doesn't seem like we have problems with
> claims over 4MB on powerpc or x86 ieee1275. (sparc does things completely
> differently and never used the constant.)
>
> Drop the constant and the check.
>
> The only use of HEAP_MIN_SIZE was to potentially override the
> HEAP_MAX_ADDR check. It is now unused. Remove it.
>
> Signed-off-by: Daniel Axtens
> Tested-by: Stefan Berger
Nit, you should add your Signed-off-by after Daniel's one. I can make it
for you if you do not object.
Otherwise: Reviewed-by: Daniel Kiper
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/22] ieee1275: claim more memory
On Fri, Jul 16, 2021 at 05:59:20AM +0200, Patrick Steinhardt wrote: > On Thu, Jul 15, 2021 at 11:51:04PM +0200, Daniel Kiper wrote: > > CC-in a few people who can be interested in this... > > > > On Wed, Jun 30, 2021 at 06:40:11PM +1000, Daniel Axtens wrote: > > > 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. > > > > > > So we want to claim more memory from OpenFirmware for our heap. > > > > AFAICT it is common problem in the GRUB right now. Please take a look at > > [1], [2]. It would be nice to find general solution for all. Of course > > if possible. So, if somebody could take a look at memory management in > > the GRUB and propose a solution for the problem that would be perfect. > > Any volunteers? > > > > Daniel > > > > [1] https://lists.gnu.org/archive/html/grub-devel/2020-06/msg9.html > > [2] https://lists.gnu.org/archive/html/grub-devel/2021-01/msg00031.html > > I think that my [1] should solve the issue generically. Instead of > bumping any of the static limits we have in place, we just drop them > altogether in favor of dynamically requesting additional EFI regions > whenever we realize that the currently mapped regions cannot satisfy our > needs. Like this, we can lower the initially requested regions, but > scale them to the specific needs if need be. > > I had planned to revisit this patch series much earlier, but somehow I > didn't yet find the time. Any comments on my approach would be welcome > though, and if we agree that this may be a viable route to go down then > I'd be happy to further pursue it. Patrick, thanks a lot! I will take a look at the [1] patchset next week. Daniel A., Stefan, may I ask you to take a look at the [1] too and tell us how it will work in your cases? Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2020-06/msg9.html ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 1/4] ieee1275: drop HEAP_MAX_ADDR, HEAP_MIN_SIZE
On 7/21/21 10:36 AM, Daniel Kiper wrote:
On Tue, Jul 20, 2021 at 05:14:46PM -0400, Stefan Berger wrote:
From: Daniel Axtens
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 */
This doesn't make a lot of sense when the constants are well above 4MB
already. It was not always this way. Prior to
commit 7b5d0fe4440c ("Increase heap limit") in 2010, HEAP_MAX_SIZE and
HEAP_MAX_ADDR were indeed 4MB. However, when the constants were increased
the comment was left unchanged.
It's been over a decade. It doesn't seem like we have problems with
claims over 4MB on powerpc or x86 ieee1275. (sparc does things completely
differently and never used the constant.)
Drop the constant and the check.
The only use of HEAP_MIN_SIZE was to potentially override the
HEAP_MAX_ADDR check. It is now unused. Remove it.
Signed-off-by: Daniel Axtens
Tested-by: Stefan Berger
Nit, you should add your Signed-off-by after Daniel's one. I can make it
for you if you do not object.
I do not object.
Otherwise: Reviewed-by: Daniel Kiper
Thanks.
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug 1900233 - Grub fails to boot with tpm.c errors
CC-ing James and Javier... On Wed, Jul 21, 2021 at 09:53:48PM +1000, Bruno Parisi wrote: > Hi all, > > Apologies if I'm doing this wrong but I've never had to contact you before. > There is a bug that was logged on RedHat Bugzilla https://bugzilla.redhat.com/ > show_bug.cgi?id=1900233 > > Which a user and myself both have the same issue. I'm running a Lenovo C940 > and > if I recall he has a C740. > The poster thepiguy did a fair bit of back and forth with the Fedora team to > identify where and how this was happening but deemed it not a Fedora specific > issue as with the right conditions the same issue was present in Arch. > > I wanted to bring this to your attention as I'd like to help solve this issue > if possible as it's a very annoying issue and I don't want to disable my TPM > to > work around it (As some have suggested on another post in the Fedora forum) > https://ask.fedoraproject.org/t/grub-core-error-you-need-to-load-the-kernel- > first/14405 May I ask you to try this patch [1] out. Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2021-02/msg00107.html ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] Adjust deprecated QEMU device name.
On Fri, Jul 16, 2021 at 05:22:42PM +0100, Dimitri John Ledkov wrote:
> On Wed, Jul 7, 2021 at 2:52 PM Daniel Kiper wrote:
> >
> > On Sun, Jun 13, 2021 at 03:11:51PM +0200, Marius Bakke wrote:
> > > The 'ide-drive' device was removed in QEMU 6.0.
> >
> > Could you add your Signed-off-by?
> >
> > > * tests/ahci_test.in (outfile): s/ide-drive/ide-hd/
> >
> > Please drop this.
> >
> > > ---
> > > tests/ahci_test.in | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tests/ahci_test.in b/tests/ahci_test.in
> > > index 7df560462..d844fe680 100644
> > > --- a/tests/ahci_test.in
> > > +++ b/tests/ahci_test.in
> > > @@ -41,7 +41,7 @@ echo "hello" > "$outfile"
> > >
> > > tar cf "$imgfile" "$outfile"
> > >
> > > -if [ "$(echo "nativedisk; source '(ahci0)/$outfile';" | "${grubshell}"
> > > --qemu-opts="-drive id=disk,file=$imgfile,if=none -device ahci,id=ahci
> > > -device ide-drive,drive=disk,bus=ahci.0 " | tail -n 1)" != "Hello World"
> > > ]; then
> > > +if [ "$(echo "nativedisk; source '(ahci0)/$outfile';" | "${grubshell}"
> > > --qemu-opts="-drive id=disk,file=$imgfile,if=none -device ahci,id=ahci
> > > -device ide-hd,drive=disk,bus=ahci.0 " | tail -n 1)" != "Hello World" ];
> > > then
> >
> > Is it possible to check QEMU version here and use correct variant then?
> >
>
> ide-hd has been available for more than 10 years now in qemu, thus
> there shouldn't be any need for backwards compatible names.
OK, Reviewed-by: Daniel Kiper then...
Marius, I will add your Signed-off-by if you do not object.
Thanks,
Daniel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2 02/22] ieee1275: claim more memory
On 7/21/21 10:45 AM, Daniel Kiper wrote: On Fri, Jul 16, 2021 at 05:59:20AM +0200, Patrick Steinhardt wrote: On Thu, Jul 15, 2021 at 11:51:04PM +0200, Daniel Kiper wrote: CC-in a few people who can be interested in this... On Wed, Jun 30, 2021 at 06:40:11PM +1000, Daniel Axtens wrote: 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. So we want to claim more memory from OpenFirmware for our heap. AFAICT it is common problem in the GRUB right now. Please take a look at [1], [2]. It would be nice to find general solution for all. Of course if possible. So, if somebody could take a look at memory management in the GRUB and propose a solution for the problem that would be perfect. Any volunteers? Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2020-06/msg9.html [2] https://lists.gnu.org/archive/html/grub-devel/2021-01/msg00031.html I think that my [1] should solve the issue generically. Instead of bumping any of the static limits we have in place, we just drop them altogether in favor of dynamically requesting additional EFI regions whenever we realize that the currently mapped regions cannot satisfy our needs. Like this, we can lower the initially requested regions, but scale them to the specific needs if need be. I had planned to revisit this patch series much earlier, but somehow I didn't yet find the time. Any comments on my approach would be welcome though, and if we agree that this may be a viable route to go down then I'd be happy to further pursue it. Patrick, thanks a lot! I will take a look at the [1] patchset next week. Daniel A., Stefan, may I ask you to take a look at the [1] too and tell us how it will work in your cases? I will try this later today by replacing Daniel A.'s 3 patches with those in [1] and see what happens. I see a lot of _efi_ in the functions in the 3 patches in [1] ... Daniel [1] https://lists.gnu.org/archive/html/grub-devel/2020-06/msg9.html ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug 1900233 - Grub fails to boot with tpm.c errors
Hi! Thank you so much for getting back to me so quickly. I'd be more than happy to try the patch out, unfortunately I'm not familiar with how to apply it. Would you have instruction for me to follow? I see + & - element so I'm guessing I'm to remove/replace these lines in a file but I see Git commands so am I supposed to download a Git repo and modify the files and then compile? I'm a long time Linux user but only recently started to learn about Git and manual installs. I'm happy to learn and be more helpful in the community but if you could point me in the right direction to understand the how to do this I'd appreciate it 😅😄. Apologies for my lack of knowledge. Kind regards, Bruno On Thu, 22 Jul 2021, 1:05 am Daniel Kiper, wrote: > CC-ing James and Javier... > > On Wed, Jul 21, 2021 at 09:53:48PM +1000, Bruno Parisi wrote: > > Hi all, > > > > Apologies if I'm doing this wrong but I've never had to contact you > before. > > There is a bug that was logged on RedHat Bugzilla > https://bugzilla.redhat.com/ > > show_bug.cgi?id=1900233 > > > > Which a user and myself both have the same issue. I'm running a Lenovo > C940 and > > if I recall he has a C740. > > The poster thepiguy did a fair bit of back and forth with the Fedora > team to > > identify where and how this was happening but deemed it not a Fedora > specific > > issue as with the right conditions the same issue was present in Arch. > > > > I wanted to bring this to your attention as I'd like to help solve this > issue > > if possible as it's a very annoying issue and I don't want to disable my > TPM to > > work around it (As some have suggested on another post in the Fedora > forum) > > > https://ask.fedoraproject.org/t/grub-core-error-you-need-to-load-the-kernel- > > first/14405 > > May I ask you to try this patch [1] out. > > Daniel > > [1] https://lists.gnu.org/archive/html/grub-devel/2021-02/msg00107.html > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
