Package: ovmf
Version: 2020.08-1
Severity: normal
X-Debbugs-Cc: daichi.fuku...@gmail.com
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
When I was trying to boot a Debian image with OVMF_CODE.secboot.fd enabled
in a QEMU virtual machine,
I noticed that the EFI shell didn't show up with curses enabled.
Here is a list of options to boot the image:
$ qemu-system-x86_64 \
--machine q35,smm=on \
-global driver=cfi.pflash01,property=secure,value=on \
-drive
if=pflash,format=raw,unit=0,file=/usr/share/OVMF/OVMF_CODE.secboot.fd,readonly=on
\
-drive if=pflash,format=raw,unit=1,file=/usr/share/OVMF/OVMF_VARS.fd \
-display none -serial mon:stdio -echr 2 -vga none -curses -k en-us \
-drive file=debian-qemu-amd64-2.img,format=raw,index=0,media=disk \
--enable-kvm -m 2048 -net none
* What exactly did you do (or not do) that was effective (or
ineffective)?
To make things clearer, I tested two different firmwares - OVMF_CODE.fd and
OVMF_CODE.secboot.fd - with the same qemu options including '-curses'.
As a result, the EFI shell successfully showed up in curses with
OVMF_CODE.fd, but the EFI shell failed to show up with OVMF_CODE.secboot.fd.
# With OVMF_CODE.fd, the EFI shell prompt successfully appears
$ qemu-system-x86_64 \
-bios /usr/share/OVMF/OVMF_CODE.fd \
-display none -serial mon:stdio \
-echr 2 -vga none -curses -k en-us -net none
[...]
UEFI Interactive Shell v2.2
EDK II
UEFI v2.70 (EDK II, 0x00010000)
Mapping table
BLK0: Alias(s):
PciRoot(0x0)/Pci(0x1,0x1)/Ata(0x0)
Press ESC in 1 seconds to skip startup.nsh or any other key to continue.
Shell>
# With OVMF_CODE.secboot.fd, the EFI shell doesn't show up in curses
$ qemu-system-x86_64 \
-bios /usr/share/OVMF/OVMF_CODE.secboot.fd \
-display none -serial mon:stdio \
-echr 2 -vga none -curses -k en-us -net none
[...]
(Nothing appeared after some minutes)
* What was the outcome of this action?
When a qemu image boots up with OVMF_CODE.secboot.fd provided,
the EFI shell prompt doesn't show up in curses without showing any log
messages.
I suspect that this situation means that there is a bug in the secure boot
firmware, guessing from the result above.
Unfortunately, with OVMF_CODE.secboot.fd in use,
the curses console does not provide any logs, so I could not investigate the
situation further.
I would appreciate it if you could point me to instructions on how to
collect logs in such a situation.
* What outcome did you expect instead?
When a qemu image boots up with OVMF_CODE.secboot.fd provided,
the EFI shell prompt successfully shows up in curses.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.10.0-27-generic (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
-- debconf information excluded
