Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1974596 - Lenovo Flex 5g ISO bootloop
Summary: Lenovo Flex 5g ISO bootloop
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 34
Hardware: aarch64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
Reported: 2021-06-22 06:49 UTC by Jimmy
Modified: 2021-06-23 09:43 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug

Attachments (Terms of Use)
last output before bootloop with debug=all (180.40 KB, image/jpeg)
2021-06-22 06:49 UTC, Jimmy
no flags Details

Description Jimmy 2021-06-22 06:49:03 UTC
Created attachment 1792895 [details]
last output before bootloop with debug=all

Description of problem:

After creating live USB with dd, I booted from the Aarch64 boot disk on Lenovo Flex 5g. Secure boot was disabled.

The grub menu was displayed. after selecting any option, whether it be safe graphics, or regular, it immediately bootloops back to the grub menu.

I attempted to get information by setting "debug=all". I have attached a screen image below of some of the last debug messages that were shown.

Version-Release number of selected component (if applicable):

How reproducible:
easily reproducible

Steps to Reproduce:
1. Boot a USB of Fedora workstation 34 Aarch64
2. select any boot option

Actual results:
System immediately reboots back to the grub menu

Expected results:
system boots from the USB properly

Additional info:
(screen image attached)

Comment 1 Javier Martinez Canillas 2021-06-22 10:04:34 UTC
By looking at the shared output, GRUB is executed up to when
the control is passed to the kernel by jumping directly to the
PE/COFF entry point:

  pe = (void *)((unsigned long)kernel_addr + lh.hdr_offset);
  handover_offset = pe->opt.entry_addr;

grub_efi_linux_boot (void *kernel_addr, grub_off_t handover_offset,
		     void *kernel_params)
  grub_efi_loaded_image_t *loaded_image = NULL;
  handover_func hf;
  int offset = 0;

#ifdef __x86_64__
  offset = 512;

   * Since the EFI loader is not calling the LoadImage() and StartImage()
   * services for loading the kernel and booting respectively, it has to
   * set the Loaded Image base address.
  loaded_image = grub_efi_get_loaded_image (grub_efi_image_handle);
  if (loaded_image)
    loaded_image->image_base = kernel_addr;
    grub_dprintf ("linux", "Loaded Image base address could not be set\n");

  grub_dprintf ("linux", "kernel_addr: %p handover_offset: %p params: %p\n",
		kernel_addr, (void *)(grub_efi_uintn_t)handover_offset, kernel_params);
  hf = (handover_func)((char *)kernel_addr + handover_offset + offset);
  hf (grub_efi_image_handle, grub_efi_system_table, kernel_params);

  return GRUB_ERR_BUG;

So the issue should be on the boot protocol used by GRUB, or very early in the
kernel boot process. More investigation will be needed to figure that out.

Comment 2 Javier Martinez Canillas 2021-06-23 09:43:58 UTC
Moving this to the kernel component, since as mentioned it hangs after
GRUB has jumped to the Linux PE/COFF entry point.

Note You need to log in before you can comment on or make changes to this bug.