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 bugzilla.redhat.com.
Bug 1654225 - kernel fails to boot on edk2 (via efi stub) on arm (32bit).
Summary: kernel fails to boot on edk2 (via efi stub) on arm (32bit).
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-28 09:56 UTC by Gerd Hoffmann
Modified: 2019-02-21 21:13 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-21 21:13:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
kernel log file (8.55 KB, text/plain)
2018-11-28 09:56 UTC, Gerd Hoffmann
no flags Details

Description Gerd Hoffmann 2018-11-28 09:56:25 UTC
Created attachment 1509423 [details]
kernel log file

Description of problem:
$subject

Version-Release number of selected component (if applicable):
edk2-arm-20180815gitcb5f4f45ce-2.fc28.noarch
kernel-core-4.19.3-200.fc28.armv7hl

How reproducible:
100%

Steps to Reproduce:
#!/bin/sh

# config
qemu="qemu-system-arm"
proc="cortex-a15"
type="virt,accel=tcg,usb=off"
code="/usr/share/edk2/arm/QEMU_EFI-pflash.raw"
tmpl="/usr/share/edk2/arm/vars-template-pflash.raw"
vars="$(mktemp ${TMPDIR-/tmp}/efi-vars-XXXXXXXX.raw)"

# setup writable efi vars
trap 'rm -f "$vars"' EXIT
cp -v "$tmpl" "$vars"

fwargs=""
fwargs="$fwargs -drive file=${code},format=raw,if=pflash,readonly=on"
fwargs="$fwargs -drive file=${vars},format=raw,if=pflash"
kernel="/boot/vmlinuz-$(uname -r)"
append="console=ttyAMA0 earlycon"

set -ex
$qemu   -nographic              \
        -m 1G                   \
        -machine ${type}        \
        -cpu ${proc}            \
        $fwargs                 \
        \
        -kernel "$kernel"       \
        -append "$append"       \
        \
        "$@"

Actual results:
see attached log

Comment 1 Gerd Hoffmann 2018-11-28 10:00:58 UTC
possibly this is something in edk2, so cc'ing Laszlo.

Comment 2 Laszlo Ersek 2018-11-28 12:23:01 UTC
Hi Gerd,

(+Eric,)

I think this is a duplicate of bug 1633328. Using virt-3.0+ machine types, if your 32-bit ARM guest kernel lacks LPAE, then you need to specify "-machine highmem=off" explicitly.

In comment #0 you mention the "kernel-core" package. Can you perhaps retry with "kernel-lpae-core"? Thanks.

*** This bug has been marked as a duplicate of bug 1633328 ***

Comment 3 Gerd Hoffmann 2018-11-29 09:31:21 UTC
> In comment #0 you mention the "kernel-core" package. Can you perhaps retry
> with "kernel-lpae-core"? Thanks.

The lpae kernel crashes the same way, and "-machine highmem=off" doesn't help either.

Comment 4 Laszlo Ersek 2018-11-29 09:40:35 UTC
OK, thanks; different issue then.

Comment 5 Laszlo Ersek 2018-11-29 09:44:09 UTC
I think I'll ask Ard to take a look; the backtrace might ring a bell with him.

Comment 7 Justin M. Forbes 2019-01-29 16:25:13 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs.

Fedora 28 has now been rebased to 4.20.5-100.fc28.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29.

If you experience different issues, please open a new bug report for those.

Comment 8 Justin M. Forbes 2019-02-21 21:13:13 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.


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