[Bug 1122614] New: armv7 efistub enablement
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614 Bug ID: 1122614 Summary: armv7 efistub enablement Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: armv7 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: guillaume.gardet@arm.com QA Contact: qa-bugs@suse.de CC: afaerber@suse.com, agraf@suse.com, bill@merriam.net, dmueller@suse.com, guillaume.gardet@arm.com, matwey.kornilov@gmail.com, matz@suse.com, mbrugger@suse.com, mchang@suse.com, mhocko@suse.com, ptesarik@suse.com, rguenther@suse.com, tiwai@suse.com, yousaf.kaukab@suse.com Depends on: 1104833 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1104833 +++ While solving initramfs bug (boo#1104833) on armv7, discussions about efistub on armv7 came up. This bug is the new place to discuss it, as original bug is fixed. Background: efistub has been enabled in kernel 4.20. To use it, we need to enable it in grub2, but once enabled, non-efistub kernel will stop to work, as per comment https://bugzilla.opensuse.org/show_bug.cgi?id=1104833#c44 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c1
Andreas Färber
Background: efistub has been enabled in kernel 4.20. To use it, we need to enable it in grub2, but once enabled, non-efistub kernel will stop to work, as per comment https://bugzilla.opensuse.org/show_bug.cgi?id=1104833#c44
We now have kernel 4.20.0 with CONFIG_EFI_STUB=y built in openSUSE:Factory:ARM. Caution: Last _published_ Factory armv7hl kernel packages are still at 4.19.12. @Michael, can you work with Guillaume to a) backport the 32-bit arm efistub patches that were mentioned to our Factory grub2 package (or maybe update it :)) and b) have Arm look into backwards compatibility for non-efistub enabled kernels if still missing? Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c2
--- Comment #2 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c3
--- Comment #3 from Michael Chang
Grub 2.04 has been released: https://lists.gnu.org/archive/html/grub-devel/2019-07/msg00000.html
@Michael, could you update grub accordingly, please? As grub 2.04 has the required patch.
The 2.04 upgrade is currently tracked in the project. https://build.opensuse.org/package/show/home:michael-chang:devel/grub2 I have tested it on ThunderX2 (aarch64) and worked without problem so far. Would it be possible for you to test on the armv7 if you have one around the corner? If not it will take some time from me to find the hardware.
Tumbleweed kernel has CONFIG_EFI_STUB=y since a while, so it is safe to update grub in Tumbleweed.
Thanks for the info, do we still care about backward compatibility (ie booting kernels without efi stub, with what Andreas already mentioned in comment#1) ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c4
Guillaume GARDET
The 2.04 upgrade is currently tracked in the project.
https://build.opensuse.org/package/show/home:michael-chang:devel/grub2
I have tested it on ThunderX2 (aarch64) and worked without problem so far. Would it be possible for you to test on the armv7 if you have one around the corner? If not it will take some time from me to find the hardware.
I will test on armv7 and I will post here the results.
Tumbleweed kernel has CONFIG_EFI_STUB=y since a while, so it is safe to update grub in Tumbleweed.
Thanks for the info, do we still care about backward compatibility (ie booting kernels without efi stub, with what Andreas already mentioned in comment#1) ?
From my point of view, it is not necessary. @andreas, WDYT?
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c5
--- Comment #5 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c6
--- Comment #6 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c7
--- Comment #7 from Michael Chang
armv7 tests results: * qemu armv7 is ok * Raspberry Pi 2, model B is broken, as the Grub menu is not shown on serial anymore, only on HDMI output, and once we want to boot a kernel, we get:
AFAIK, the serial output is redirected to "console" in efi, so it is unclear to me which driver you were talking here? Is it text based "console" (with serial redirection to it) or the native "serial" console ?
EFI stub: Booting Linux Kernel... EFI stub: ERROR: Unable to allocate memory for uncompressed kernel. EFI stub: ERROR: Failed to relocate kernel
The kernel message suggested we got some issues in the new efistub enablement, previously the booting was done by non-efistub entry (zImage) and it did not fail.
My test on RPi2 B has been done by using latest released Tumbleweed image and then updating grub2* 2.04 packages from Michael's home project.
I think in general it would be helpful to verify the upstream build in this regard to see whether a regression in upstream. In this case very much likely as we are much aligned with upstream for armv7. I am currently working on obs project providing vanilla grub package, and will let you know once finished. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c8
--- Comment #8 from Michael Chang
Also broken on Chromebook ARM, but I cannot give much details on this failure as I have no serial on this device and screen goes back to grub menu.
bootarm.efi is very light now, around 170KB instead of 750KB previously.
I compared the kernel.img size between packages in Base:System and 2.04, there's no much difference (88KB vs 87KB). Looks like the comparison is between /boot/grub2/arm-efi/grub.efi and bootarm.efi created by grub2-install. The first is created in OBS with lots of modules builtin, used in boot media, secure boot and so on. The latter is created wrt the runtime system by grub2-install, only with minimum required modules built-in. Hm. Now that it seems to me the serial console problem could be related. Try if this work ? grub2-install --modules=serial
If I re-use the file from /boot/grub2/arm-efi/grub.efi from rootfs partition (not updated apparently) and copy it to (EFI part)/EFI/BOOT/bootarm.efi it does boot again.
If I copy /usr/share/grub2/arm-efi/grub.efi, then it does fail too.
The failure might be in the same efistub, we can check by new kernel update after we have it fixed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c9
Michael Chang
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c10
--- Comment #10 from Guillaume GARDET
Hm. Now that it seems to me the serial console problem could be related. Try if this work ?
grub2-install --modules=serial
It returns: Installing for arm-uboot platform. grub2-install: warning: no hints available for your platform. Expect reduced performance. grub2-install: error: cannot open `/usr/share/grub2/arm-uboot/serial.mod': No such file or directory. And there is no grub.efi in /usr/share/grub2/arm-uboot/ is it expected? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c11
--- Comment #11 from Michael Chang
(In reply to Michael Chang from comment #8)
Hm. Now that it seems to me the serial console problem could be related. Try if this work ?
grub2-install --modules=serial
It returns: Installing for arm-uboot platform. grub2-install: warning: no hints available for your platform. Expect reduced performance. grub2-install: error: cannot open `/usr/share/grub2/arm-uboot/serial.mod': No such file or directory.
And there is no grub.efi in /usr/share/grub2/arm-uboot/ is it expected?
Sorry I think the correct command is : grub2-install --with-platform=arm-efi -no-nvram --removable --modules=serial The default architecture of grub utility we packaged for armv7 is arm-uboot. While running it will detect efi firmware through the presence of /sys/firmware/efi and change the installation to arm-efi architecture accordingly. For the EFI on U-Boot, no efi boot variable on the system so no /sys/firmware/efi, therefore we need to manually specify the platform parameters for grub-install (This is also how update-bootloader handles it) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c12
--- Comment #12 from Gary Ching-Pang Lin
From the error message, it looks like the kernel failed at reserve_kernel_base(). The kernel might try to allocate the memory pages in a memory region other than EFI_BOOT_SERVICE_* and EFI_CONVENTIONAL_MEMORY. What I don't understand is why reserve_kernel_base() couldn't just find a free region and set dram_base accordingly.
https://github.com/torvalds/linux/blob/v5.1/drivers/firmware/efi/libstub/arm... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c13
--- Comment #13 from Guillaume GARDET
Sorry I think the correct command is :
grub2-install --with-platform=arm-efi -no-nvram --removable --modules=serial
The correct command seems to be: grub2-install --target=arm-efi --no-nvram --removable --modules=serial But it does not help. Even copying /usr/share/grub2/arm-efi/grub.efi does not show the grub menu on serial. So, maybe some drivers are missing/broken? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c14
--- Comment #14 from Guillaume GARDET
From the error message, it looks like the kernel failed at reserve_kernel_base(). The kernel might try to allocate the memory pages in a memory region other than EFI_BOOT_SERVICE_* and EFI_CONVENTIONAL_MEMORY. What I don't understand is why reserve_kernel_base() couldn't just find a free region and set dram_base accordingly.
https://github.com/torvalds/linux/blob/v5.1/drivers/firmware/efi/libstub/ arm32-stub.c#L64-L188
Maybe u-boot does not pass the right information? As UEFI based qemu system is fine. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c15
Andreas Färber
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c16
--- Comment #16 from Chester Lin
(In reply to Gary Ching-Pang Lin from comment #12)
From the error message, it looks like the kernel failed at reserve_kernel_base(). The kernel might try to allocate the memory pages in a memory region other than EFI_BOOT_SERVICE_* and EFI_CONVENTIONAL_MEMORY. What I don't understand is why reserve_kernel_base() couldn't just find a free region and set dram_base accordingly.
https://github.com/torvalds/linux/blob/v5.1/drivers/firmware/efi/libstub/ arm32-stub.c#L64-L188
Maybe u-boot does not pass the right information? As UEFI based qemu system is fine.
grub has a 'lsefimmap' command to dump entire EFI memmap, would you mind if you can try it so that we can check if there's any difference between UEFI and U-Boot? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c17
--- Comment #17 from Michael Chang
Michael, can you just drop the non-portable arm-uboot target and default to the arm-efi target like on aarch64?
Sorry, maybe "default" is a bit misleading here. The grub2-install has to support arm-uboot and arm-efi targets. Without any target specified it will try to figure it out via testing the /sys/firmware/efi. (It is therefore more likely a runtime behavior than a platform specific default bounded to configure). The behavior above is common for grub2-install built from ./configure --with-platfomr=efi and /configure --with-platform=uboot. It did not change if we change the packaged grub2-install from uboot to efi. Or do you mean to drop the arm-uboot package ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c18
--- Comment #18 from Michael Chang
But it does not help. Even copying /usr/share/grub2/arm-efi/grub.efi does not show the grub menu on serial. So, maybe some drivers are missing/broken?
The git-log did not reveal upstream serial driver for efi received any change since 2.02
git --no-pager log --oneline 2.02..grub-2.04 -- grub-core/term/serial.c grub-core/term/efi/serial.c
Also the firmware's console driver has no obvious change.
git --no-pager log --oneline 2.02..grub-2.04 -- grub-core/term/efi/console.c edece25a7 efi/console: Fix the "enter" key not working on x86 tablets bdd89d239 core: use GRUB_TERM_ definitions when handling term characters
Also checked the Makefile.core.def, moddep.lst did not change for the platform module in use and dependency wrt arm-efi console/serial driver. Would you please attach grub.cfg for reference ? Maybe can find some clue there. Meanwhile I'll try to get RPI2 to reproduce the problem. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c19
--- Comment #19 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c20
--- Comment #20 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c21
--- Comment #21 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c22
--- Comment #22 from Gary Ching-Pang Lin
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c23
--- Comment #23 from Gary Ching-Pang Lin
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c24
--- Comment #24 from Joey Lee
Just checked the u-boot code, it always marks the first page as WB and RESERVED for its own spin table.
Maybe we can change the logic of get_dram_base() in kernel from
if (md->attribute & EFI_MEMORY_WB) {
to
if (md->attribute & EFI_MEMORY_WB && md->type == EFI_CONVENTIONAL_MEMORY) {
This way, get_dram_base() will always find the first free region.
(In reply to Gary Ching-Pang Lin from comment #23)
Just checked the u-boot code, it always marks the first page as WB and RESERVED for its own spin table.
Maybe we can change the logic of get_dram_base() in kernel from
if (md->attribute & EFI_MEMORY_WB) {
to
if (md->attribute & EFI_MEMORY_WB && md->type == EFI_CONVENTIONAL_MEMORY) {
This way, get_dram_base() will always find the first free region.
As Gary's suggestion, I am building kernel RPM for testing: --- drivers/firmware/efi/libstub/efi-stub-helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/firmware/efi/libstub/efi-stub-helper.c +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c @@ -153,7 +153,7 @@ unsigned long get_dram_base(efi_system_t map.map_end = map.map + map_size; for_each_efi_memory_desc_in_map(&map, md) { - if (md->attribute & EFI_MEMORY_WB) { + if ((md->type == EFI_CONVENTIONAL_MEMORY) && (md->attribute & EFI_MEMORY_WB)) { if (membase > md->phys_addr) membase = md->phys_addr; } -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c25
--- Comment #25 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c26
--- Comment #26 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c27
--- Comment #27 from Andreas Färber
Or do you mean to drop the arm-uboot package ?
Yes. 1) It hardcoded the physical RAM location and would need per-SoC builds. 2) This feature is not enabled in U-Boot by default, unusable with our packages. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c28
--- Comment #28 from Joey Lee
(In reply to Gary Ching-Pang Lin from comment #23) [...snip]
if (md->attribute & EFI_MEMORY_WB && md->type == EFI_CONVENTIONAL_MEMORY) {
This way, get_dram_base() will always find the first free region.
As Gary's suggestion, I am building kernel RPM for testing:
--- drivers/firmware/efi/libstub/efi-stub-helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/firmware/efi/libstub/efi-stub-helper.c +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c @@ -153,7 +153,7 @@ unsigned long get_dram_base(efi_system_t map.map_end = map.map + map_size;
for_each_efi_memory_desc_in_map(&map, md) { - if (md->attribute & EFI_MEMORY_WB) { + if ((md->type == EFI_CONVENTIONAL_MEMORY) && (md->attribute & EFI_MEMORY_WB)) { if (membase > md->phys_addr) membase = md->phys_addr; }
I have pushed this patch to OBS for building kernel RPMs now: https://build.opensuse.org/package/show/home:joeyli:branches:openSUSE:Factor... I didn't environment to test it yet. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c29
--- Comment #29 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c30
--- Comment #30 from Joey Lee
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c31
--- Comment #31 from Joey Lee
I tried the patched kernel with grub 2.04 on Raspberry Pi2 B+ and I get the following message: EFI stub: Booting Linux Kernel... EFI stub: ERROR: reserve_kernel_base(): allocate boot data pass. EFI stub: ERROR: reserve_kernel_base(): allocate boot data success. EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map...
and the system hangs.
Thanks for your testing! The allocation of memory space for kernel is already pass. Then system hands when kernel tries to set FDT, call ExitBootServices then set virtual address map. We must do further debugging. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c32
Michael Chang
(In reply to Michael Chang from comment #17)
Or do you mean to drop the arm-uboot package ?
Yes.
1) It hardcoded the physical RAM location and would need per-SoC builds. 2) This feature is not enabled in U-Boot by default, unusable with our packages.
Thanks for providing the information. Let's drop arm-uboot package if it is no longer supported and also reduce some loads on build service. :) Will you open a bug for dropping the grub2-arm-uboot package ? TIA. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c33
--- Comment #33 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c34
--- Comment #34 from Guillaume GARDET
On Chromebook ARM, your patch fixes the boot.
Retrying kernel 5.1.x without your patch on Chromebook ARM and it just works. The only difference is u-boot version (v2018.11 vs v2019.04). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c35
--- Comment #35 from Joey Lee
On Chromebook ARM, your patch fixes the boot.
On RPi2 it is broken as already reported at https://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c29 I suspect this line of code: dram_base = round_up(dram_base, SZ_128M); from https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/ drivers/firmware/efi/libstub/arm32-stub.c?h=v5.2#n207
which may cause troubles with the first 4K reserved memory.
If dram_base falls in the first reserved region, then the allocation in reserve_kernel_base() will be failed as the original symptom. With patched kernel, the allocation is pass. The new broken is in allocate_new_fdt_and_exit_boot(), Chester Lin is looking at it. Actually, it a bit mess in the allocation logic for kernel on ARM32. For example: The "dram_base + MAX_UNCOMP_KERNEL_SIZE" space be allocated in reserve_kernel_base() as EFI_BOOT_SERVICES_DATA type. But in later efi_relocate_kernel(), it tries to allocate the same space as EFI_LOADER_DATA again. Which means that the efi_low_alloc() will always be performed. Then the first allocation reserve_kernel_base() and efi_relocate_kernel() are useless. I don't think that many people use the EFI stub code path on ARM32. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c36
Michael Chang
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c37
Guillaume GARDET
Hi Guillaume,
Could you please check if you seen the message "Please press 't' to show the boot menu on this console" and pressing the "t" could bring the menu or not ?
No, the last message on serial is: Welcome to GRUB! Whereas with previous grub2.02, I also have the following lines after the welcome message: Waiting for Ethernet connection... done. Please press 't' to show the boot menu on this console
If not working, could you please try modifying /etc/default/grub with:
GRUB_TERMINAL="console"
And run "grub2-mkconfig -o /boot/grub2/grub.cfg" to direct using the firmware console at boot, thus will eliminate the hotkey 't' not being functional. And if still not work, problem might be within the console terminal itself.
GRUB_TERMINAL="console" option allows to have the menu on serial console. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c38
--- Comment #38 from Michael Chang
(In reply to Michael Chang from comment #36)
Hi Guillaume,
Could you please check if you seen the message "Please press 't' to show the boot menu on this console" and pressing the "t" could bring the menu or not ?
No, the last message on serial is: Welcome to GRUB!
Whereas with previous grub2.02, I also have the following lines after the welcome message: Waiting for Ethernet connection... done. Please press 't' to show the boot menu on this console
Is /sys/firmware/efi present on your the system ? It is required to generate the relevant message and hiddenentry in grub.cfg .. [1] https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-SU... Other possibilities could be the timeout setting, would you please attach your grub.cfg here for reference ?
If not working, could you please try modifying /etc/default/grub with:
GRUB_TERMINAL="console"
And run "grub2-mkconfig -o /boot/grub2/grub.cfg" to direct using the firmware console at boot, thus will eliminate the hotkey 't' not being functional. And if still not work, problem might be within the console terminal itself.
GRUB_TERMINAL="console" option allows to have the menu on serial console.
OK, at least good news for the console driver in 2.04 works. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c39
Guillaume GARDET
(In reply to Guillaume GARDET from comment #37)
(In reply to Michael Chang from comment #36)
Hi Guillaume,
Could you please check if you seen the message "Please press 't' to show the boot menu on this console" and pressing the "t" could bring the menu or not ?
No, the last message on serial is: Welcome to GRUB!
Whereas with previous grub2.02, I also have the following lines after the welcome message: Waiting for Ethernet connection... done. Please press 't' to show the boot menu on this console
Is /sys/firmware/efi present on your the system ? It is required to generate the relevant message and hiddenentry in grub.cfg ..
[1] https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2- SUSE-Add-the-t-hotkey.patch?expand=1
There is no /sys/firmware/efi/ as, IIUC, it would require grub2.04 to be installed and when I install it, it still has grub2.02. And grub2.04 fails to boot properly on RPi2 atm, as reported in #c5. If I remove the EFI test condition, it is working fine. \o/ So, it leaves the broken boot of kernel, even with patched kernel for #c28 @jlee, did you or Chester made some progress and/or have something to test on RPi2? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c53
--- Comment #53 from Guillaume GARDET
Created attachment 812450 [details] armv6 data abort after kernel and initrd are loaded.
Forgot to mention that the unpatched kernel has the same 'data abort' problem than the patched kernel. So, the problem is not from the patch, but it may be from grub 2.04 itself. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c70
--- Comment #70 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c71
--- Comment #71 from Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
Guillaume GARDET
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614
http://bugzilla.opensuse.org/show_bug.cgi?id=1122614#c72
Guillaume GARDET
participants (1)
-
bugzilla_noreply@novell.com