messages like below,
and the udisks2, udev and dbus daemons eat nearly 100% of CPU
in total. The flood of false messages disappears by removing udisks2
package.
This symptom is also observed with the vanilla upstream kernel.
Best regards, Ryutaroh Matsumoto
monitor will print the received events
Control: severity -1 minor
The bug #979187 was the boot failure from the USB MSD
ID 056e:6a13 Elecom Co., Ltd ESD-EMN.
With the kernel .config
From: Ryutaroh Matsumoto
> CONFIG_RESET_RASPBERRYPI=y
> CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
> CONFIG_SENSORS_RASPBERRYPI_HWMON=y
Kernel mounted
none_arm64
I believe
CONFIG_RESET_RASPBERRYPI=y
CONFIG_ARM_RASPBERRYPI_CPUFREQ=y
CONFIG_SENSORS_RASPBERRYPI_HWMON=y
fix 977694. On the other hand, the other issue 979187 remains.
I will report the situation of 979187 in a separete email.
Best regards, Ryutaroh Matsumoto
[0.00] Booting Linux on phys
> Indeed, CONFIG_DRM_VC4=m has been mistakenly removed from the arm64 kernel
> configuration. I’ll propose a merge request to fix this.
>
> Cheers,
> Vincent
Thank you. I though that the kernel team decided to suspend vc4.ko,
because of the garbled unreadable screen as reported at
in 5.10.5-1,
the above two issues have come back (I unwelcome them...).
Best regards, Ryutaroh Matsumoto
>> 5.10.9-1 is awaiting currently in NEW for beeing processed. Once that
>> enters unstable, can you please check with it, and if so then close
>> this bug with the respective version?
>
> I do not observe 977694 nor 979187 on my self-compiled kernel,
> but 977694 & 979187 remain in 5.10.9-1...
The emails related to this symptom and pathces have appeared in the dri-devel
mailing list as below:
https://lists.freedesktop.org/archives/dri-devel/2021-January/295093.html
https://lists.freedesktop.org/archives/dri-devel/2021-January/295094.html
0.9.txt
Best regards, Ryutaroh Matsumoto
[0.00] Booting Linux on physical CPU 0x00 [0x410fd083]
[0.00] Linux version 5.10.9 (root@raspi4b8gb) (gcc (Debian 10.2.1-6)
10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Fri Jan 22
10:00:50 JST 2021
[0.00]
quot;config.txt" of raspi, as reported at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977642
The latter is actually a bug in the upstream kernel. Today I was told that
it has been fixed upstream at the dri-devel mailing list from Maxime Ripard.
Best regards, Ryutaroh Matsumoto
> On the other hand, vc4.ko gives completely garbled screen to my 4K HDMI
> display, and disable_fw_kms_setup=1 does not help unlike
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977642
I am sorry, with disable_fw_kms_setup=1, vc4.ko works fine.
Without disable_fw_kms_setup=1, vc4.ko gives
Control: tags -1 + fixed-upstream
Self-compiled 5.10.9 does not show this reported symptom,
and I assume this is fixed-upstream. Ryutaroh
Giving module_blacklist=vc4 to the kernel command line helps.
On the other hand, vc4.ko in the upstream 5.10.9 with disable_fw_kms_setup=1
works well, and I expect it will get better with no extra packaging effort.
Best regards, Ryutaroh Matsumoto
/raspi-firmware.
The default 64M does not work for high resolution displays and 5.10 kernel.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64
ics come. Rendering by wayland does not work at all with
> vc4.ko in 5.10.9.
The above symptom is "fixed" by adding
CMA=256M@128M
to the kernel command line.
Then the gdm3 display manager starts up well, and I have
# grep -i cma /proc/meminfo
CmaTotal: 262144 kB
CmaFree: 1
Hi all,
This is an update to
Bug#968181: linux-image-5.7.0-2-arm64: DRM unavailable on Rapsberry Pi 4B
I compiled Linux 5.10.9 by myself, and xinit starts fine without installing
the Debian package xserver-xorg-video-fbdev. When I originally reported this
#968181, the graphics on my raspi can
Control: tags -1 + fixed-upstream
I compiled the upstream kernel 5.10.8 and it can use 4K resolution. Ryutaroh
ests/4
Best regards, Ryutaroh Matsumoto
Control: tags -1 + fixed-upstream
I compiled the upstream kernel 5.10.8, and it boots well from a USB MSD.
5.10.6 and older seem unable to find any USB device connected to
Raspberry Pi 4B 8GB, and 5.10.8 seems to have no problem with
USB on Raspberry Pi 4B 8GB.
Ryutaroh Matsumoto
I am tired of seeing if 5.10.? kernel works normally or not on my
machines.
I have seen little problem in Debian 5.9.* series.
Since 5.10 is LTS, maybe 5.10.10 or 5.10.20 will gets as good as 5.9.15.
I will stick to Debian 5.9.15 kernel on my amd64 notebook and raspi4b
for a while...
Best regards, Ryutaroh Matsumoto
Control: tags -1 + wontfix
I was told that the upstream recognize this as "feature", see
https://github.com/virt-manager/virt-manager/issues/209#issuecomment-758128491
Best regards, Ryutaroh
/209
For detail, please have a look at the upstream report.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-5-amd64
Control: tags -1 + upstream
The upstream author is aware of this issue as
http://git.liw.fi/vmdb2/commit/arm64-uefi.vmdb?id=8317f3f19d1a9a749fe80232bf3729325fc4c6f2
Hi Christian,
Thank you for accepting MR.
>>> I'll try to get some tests done over the weekend. Ryutaroh, given your
>>> experience, if you get a chance to look at ARM side of this, too, I'd be
>>> immensely grateful :-)
>> I will see its behavior on building an arm image by the start of the next
Hi Christian,
Thank you very much for your work!.
> The updated packaging is in my fork on Salsa:
> https://salsa.debian.org/ckk/vmdb2
I have sent an MR regarding
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975024
I have looked at
Hi,
> reportbug linux-image-5.9.0-5-arm64
> while booted with this kernel and select the option to Follow-Up to this
> bug (you might want to have the bug number handy), so that reportbug can
> collect more information about your system.
I wanted to do that, but as the kernel does not boot
Sorry, I forgot to attach the screenshot of boot fail...
Please have a look at
https://photos.app.goo.gl/gCHUEXJB74hsWQtTA
stopped working, while
it boots with another USB MSD from Elecom...
Best regards, Ryutaroh Matsumoto
# lsusb -v
Bus 002 Device 005: ID 056e:6a13 Elecom Co., Ltd ESD-EMN
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 3.20
bDeviceClass0
Control: reassign -1 linux-image-5.10.0-1-arm64 5.10.4-1
Control: retitle -1 5.10.4 Debian kernel does not boot on raspi 4 with ext4
rootfs and usb-msd
I checked the reported symptom with
linux-image-5.10.0-1-arm64 5.10.4-1
The symptom remains the same, unlike
Control: reassign -1 linux-image-5.10.0-1-arm64 5.10.4-1
Control: severity -1 important
I checked the reported symptom with
linux-image-5.10.0-1-arm64 5.10.4-1
It booted with completely garbled screen output.
disable_fw_kms_setup=1 in config.txt did not help.
Removing vc4.ko let the screen
re-confirm that
linux-image-5.9.0-5-amd64 5.9.15-1 boots well and there seems no problem with
it...
Best regards, Ryutaroh Matsumoto
> As I said in debian-private (which, of course, is not read by
> everybody), I am in a [VAC] period. I am having quite limited
> available time, and this will continue at least until the beginning of
> 2021. So, please, if you have an upload to make - NMU the package at
> will!
Hi Gunnar,
CC:
Hi Nicholas,
Thank you very much for your attention!
> Is it possible to shift+page-up to reveal the backtrace? The backtrace
> section ends with "---[ end trace 75435… ]---"
My laptop has combined page-up + arrow-up.
Page-up is "Fn" + "arrow-up".
Shift+"Fn"+"arrow-up" doesn't work.
bsd is shown at the bottom.
Photo of boot console is found at
https://photos.app.goo.gl/WAY2NgXpFsudNQ5CA
Best regards, Ryutaroh Matsumoto
Bus 002 Device 003: ID 056e:6a13 Elecom Co., Ltd ESD-EMN
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB
://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977645
Best regards, Ryutaroh Matsumoto
d at
https://photos.app.goo.gl/A755wZKvqneX1WvY6
We observe that booting fails at btrfs.
To me, 5.10.1 btrfs looks very suspicious...
I will see if what will happen with x86_64 with btrfs rootfs...
Best regards, Ryutaroh Matsumoto
Control: retitle -1 Pls. consider DRM_VC4_HDMI_CEC
I change the issue title following suggestion by Vinent.
From: Ryutaroh Matsumoto
Subject: Re: Bug#977438: linux: Pls. consider DRM_VC4_HDMI_CEC
Date: Fri, 18 Dec 2020 09:30:49 +0900 (JST)
> Hi Vincent,
>
> Thank you for your attenti
this is a bug in raspi-firmware, but config.txt is handled by
raspi-firmware, please consider to add disable_fw_kms_setup=1.
Best regards, Ryutaroh Matsumoto
Hi Vincent,
Thank you for your attention and MR.
> I see that in a follow-up
> email you're asking for more configuration options to be enabled; It
> would probably be better to open a new bug report for those.
I will do so, after a 5.10.x package enters into experimental or unstable,
I built a
K HDMI display
as you wrote at
http://lists.infradead.org/pipermail/linux-rpi-kernel/2020-November/007894.html
Best regards, Ryutaroh Matsumoto
Control: retitle 968181 GPU/DRM acceleration unavailable on Raspberry Pi
I modprobe'ed v3d.ko on vanilla Linux kernel 5.10.1,
but /dev/dri/render* does not appear like
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1880125/comments/14
are disabled now, which seems contradicting...
CONFIG_TOUCHSCREEN_RASPBERRYPI_FW=m
CONFIG_REGULATOR_RASPBERRYPI_TOUCHSCREEN_ATTINY=m
may provide better support of raspi touch screnn.
Best regards, Ryutaroh Matsumoto
.
I will see what will happen with a Debian kernel package 5.10*
both with and without proposed patch, and report it back,
when it arrives in experimental or unstable.
Bes regards, Ryutaroh Matsumoto
- depends on ARCH_BCM || ARCH_BCMSTB || COMPILE_TEST
+ depends on ARCH_BCM || ARCH_BCMSTB || ARCH_BCM2835 || COMPILE_TEST
Best regards, Ryutaroh Matsumoto
Hi Alper,
Thanks for your simpler reproducing procedure.
Several days ago I verified that this symptom also appears with the
latest github source of qemu and reported this to the upstream as
https://bugs.launchpad.net/qemu/+bug/1907952
I pasted your simpler procedure to the upstream report.
This
Control: retitle -1 linux-image-rpi does not boot by qemu-system-arm -machine
raspi0 or raspi1ap
Booting a Debian armel kernel by grub-efi-arm:armel seems unnecessary
to everyone (?). So I changed the title.
If linux-image-rpi can boot on qemu-system-arm, then I can modify
autopkgtest-virt-qemu
se its hardware acceleration, as
https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1850876
Could you consider to enable CONFIG_DRM_V3D for arm64 and possibly
for armhf?
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy
Source: linux
Version: 5.9.11-1
Severity: wishlist
Dear Maintainer,
Could you consider to enable CONFIG_DRM_VC4_HDMI_CEC
for arm64 and possibly armhf?
It should enable cec-client command in Debian cec-util to
control some CEC-capable devices connected via HDMI.
Best regards, Ryutaroh Matsumoto
Hi Arnaud,
> Hi! Docker 20.10 is now in unstable.
Thank you very much for your work!!! Ryutaroh
Hi Ben, I figured out how to collect the kernel panic logs and they are
attached.
I tried both "-machine raspi0,firmware=/usr/lib/u-boot/rpi_0_w/u-boot.bin" and
"-machine raspi1ap,firmware=/usr/lib/u-boot/rpi/u-boot.bin".
Both failed in the same way as attached.
If you think this symptom
Hi Ben,
I found that "qemu-system-arm -machine raspi0",
u-boot-rpi:armel and linux-image-rpi do not seem bootable.
Specifically, I did the following (qemu-system-arm is from Sid):
qemu-system-arm -machine raspi0,firmware=/usr/lib/u-boot/rpi_0_w/u-boot.bin \
-display gtk -sd disk-image.qcow2
In
Hi Ben,
> But linux-image-rpi does not have the virtio driver, this option cannot
> be used (at least for now).
>
> Can you try adding it? You should be able to cross-build the kernel
> package quite easily if you use the profiles "cross,pkg.linux.notools".
> There are generic instructions at
>
Hi Ben, thanks again for your response.
> We used to provide a 'versatile' flavour on armel, for the ARM
> Versatile boards that QEMU has supported for a long time. I removed
> this flavour back in 2016 after finding that it had been broken for a
> while and no-one had reported it. Adding that
> The rpi flavour doesn't have those constraints, though. What would be
> the benefit of booting it in UEFI mode?
Thank you for paying your attention!
I considered extending autopkgtest-virt-qemu to armel (and other archs)
testbeds at
st regards, Ryutaroh Matsumoto
Control: found -1 1:5.2+dfsg-2
Control: retitle -1 with "-display gtk" arrow keys are received as just ^[ on
ttyAMA0
Control: severity minor
I have checked my reported symptom with qemu-system-arm/sid.
With -nographic, arrow keys work just fine.
With -display gtk, arrow keys does not work on
The symptom does not appear when I use virt-manager
instead of using qemu-system-aarch64 directly. Ryutaroh
ter reboot, keyboard-configuration was not installed.
I need to install keyboard-configuration and manually edit
/etc/default/keyboard to correctly use my physical Japanese
keyboard attached to qemu as -device virtio-keyboard-pci.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debi
Control: retitle -1 arrow keys are received as just ^[ on ttyAMA0
Control: reassign -1 qemu-system-arm 1:5.1+dfsg-4+b1
From: Alper Nebi Yasak
Date: Thu, 10 Dec 2020 17:36:20 +0300
> (Just in case, try running "cat -v" and pressing the arrow keys -- it
> prints ^[[A upto ^[[D or ^[0A upto ^[0D
grub-efi-arm:armel almost useless,
so I chose "important" priority.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Kernel: Lin
> The conclusion being that the proposed changes should be first included
> into upstream directly.
According to
http://git.liw.fi/vmdb2/log/?showmsg=1
arm64 support is being developed at the upstream.
armhf, armel, or ppc64el doesn't seem so.
I am willing to submit a merge request like
Control: retitle -1 new upstream version v20.10.0
The much awaited official release v20.10.0 of docker.io
appeared at
https://docs.docker.com/engine/release-notes/#20100
It should fully support cgroup v2.
Best regards, Ryutaroh
Hi everyone interested in vmdb2!
Short comments: David's approach for vmdb2 multi-arch supports
re-uses the architecture specified for qemu-debootstrap for that of "grub:
uefi".
My approach requires a user to specify the architecture twice for
qemu-debootstrap and "grub: uefi".
So, David's
Hi Gunnar,
CC: Christian,
Thank you for your message.
Since I am in To: field of your email,
I assume your last email is somewhat directed to me.
In short, I am not qualified to do NMU, a detailed excuse follows.
I have no right or expertise to NMU...
As your email is publicly appearing to BTS,
> So maybe there should be message "Debian is for SBC, please use
> $OTHER_DISTRO for servers/etc" on d-i website?
Debian Bullseye arm64 disk image for ACPI systems
can be built on an amd64/arm64 Debian host by mmdebstrap
(or probably qemu-debootstrap) and grub-install in grub-efi-arm64
as I did
Hi Alper, thank you for paying attention.
> On that specific question, you use the arrow keys to navigate between
Neither the space bar nor arrow keys worked for me with Alpha 3...
When I tried a weekly build of d-i on November or October,
at least "v" and "^" worked, d-i failed on "tasksel",
=on \
-drive if=pflash,format=raw,unit=1,file=AAVMF_VARS.fd
#-device qemu-xhci -device usb-kbd -device usb-mouse -device ramfb
# -device virtio-gpu-pci
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing
Sorry I forgot to include how I started QEMU:
#!/bin/sh
ARCH=arm64
IMAGE=/var/tmp/qemu-disk-${ARCH}.qcow2
CDROM=/var/tmp/debian-bullseye-DI-alpha3-${ARCH}-netinst.iso
rm -f $IMAGE
qemu-img create -f qcow2 -o compat=1.1 -o lazy_refcounts=on -o
preallocation=off $IMAGE 20G
cd /var/tmp
cp
/Platforms/ARM#virt_machine_graphics
https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64
package has vgabios-ramfb.bin, while
the seabios package has many vgabios-*.bin.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Kernel
l
Subject: Re: Bug#973287: systemd autopkgtest-virt-lxc failure on arm64
Date: Fri, 27 Nov 2020 09:23:31 +0100
> Am Freitag, den 27.11.2020, 12:01 +0900 schrieb Ryutaroh Matsumoto:
>> > > > We probably need to cherry-pick two changes
>> > I released 246.6-5 with
uot;arm_64bit=1" by another computer
fixes the problem.
I did not have this symptom with older version.
So I believe that this is a regression.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'uns
>> > We probably need to cherry-pick two changes
> I released 246.6-5 with those changes the other day.
I run autopkgtest 246.6-5 on amd64 and arm64 VM.
"upstream" sometimes succeeds and sometimes fails, so I assume it
is OK.
"storage" consistently fails on arm64 VM. The reason is simple as
eek, and will become less busy
afterwards...
Best regards, Ryutaroh
From: Michael Biebl
Subject: Re: Bug#973287: systemd autopkgtest-virt-lxc failure on arm64
Date: Tue, 24 Nov 2020 21:21:51 +0100
> Am Montag, den 23.11.2020, 18:09 +0900 schrieb Ryutaroh Matsumoto:
>> Hi Michael,
>>
&g
, arm64, armhf, armel, and ppc64el.
Please have a look, if you have interest...
Best regards, Ryutaroh Matsumoto
ink autopkgtest-virt-qemu should set its child qemu-system-*'s
stdio to reasonable values.
Now we become able to use autopkgtest-virt-qemu for
arm64, armhf, armel, and ppc64el in additon to amd64 and i386!
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT pref
Control: clone -1 -2
Control: retitle -2 vmdb2's support of bootable ppc64el image
Control: severity -2 wishlist
Control: block 926945 by -2
Discussion on ppc64el bootable image may deserve its own bug number,
and I clone 973467. Ryutaroh
Hi Christian, thanks again for your attention.
> * You could enhance the new "arch" field of the grub plugin by not
> defaulting to amd64, but to the native host architecture. You can
> get this using
> subprocess.check_call(['dpkg', '--print-architecture'])
Thank you. I
Summary: After building a ppc64el QEMU testbed, I met a similar symptom to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=973038#40
From: Simon McVittie
Subject: Re: autopkgtest-build-qemu support for ppc64el, arm64, armel, i386 UEFI
Date: Sun, 15 Nov 2020 18:49:36 +
> * #926945 (ppc64el
aw,discard=unmap,detect-zeroes=unmap,media=disk
\
-drive if=pflash,format=raw,unit=0,file=AAVMF_CODE.fd,readonly=on \
-drive if=pflash,format=raw,unit=1,file=AAVMF_VARS.fd
qemu-system-aarch64's version is 1:5.1-dfsg-4+b1
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
** Vers
From: Simon McVittie
Subject: Re: autopkgtest-build-qemu support for ppc64el, arm64, armel, i386 UEFI
Date: Sun, 15 Nov 2020 18:49:36 +
> * As we get new architecture support in OVMF and vmdb2, we can consider
> setting up those architectures in autopkgtest-build-qemu.
I have done it at
Control: tags -1 + patch
Hi Gunnar, in response to your message,
From: Gunnar Wolf
Subject: Re: Bug#973467: vmdb2 tries to install grub-pc or grub-efi-amd64 on
arm64 and does not work on arm64
Date: Sat, 7 Nov 2020 23:33:01 -0600
> As you said here, the workaround is not a fix, as it would
hich seems unnecessary to me.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-2-amd64 (SMP w/12 CPU threads)
Lo
log with vmdb2 --log= is attached as the second attachment.
If I delete "virtual-filesystems", everything goes fine.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental
, Ryutaroh Matsumoto
-- Package-specific info:
** Version:
Linux version 5.9.0-2-arm64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.0-16) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian
5.9.6-1 (2020-11-08)
** Command line:
video=HDMI-A-1:3840x2160M@30,margin_left=48
Control: block -1 by 973038
From: Michael Biebl
Date: Wed, 11 Nov 2020 20:47:42 +0100
> Unfortunately I lack the necessary hardware to reproduce this issue.
> Can you please forward this to upstream yourself at
> https://github.com/systemd/systemd
>
> It's likely that upstream has further
Control: tags -1 + patch
By incorporating the idea at
https://bugzilla.tianocore.org/show_bug.cgi?id=3064#c5
the attached patch completely fixes the reported symptom. Ryutaroh
--- debian-edk2-orig-sourcepkg/edk2-2020.08/debian/rules2020-09-29
04:40:05.0 +0900
+++
Package: src:linux
Followup-For: Bug #974157
Control: tags -1 + buster bullseye sid
Control: found -1 4.19.152-1
Control: found -1 4.19+105+deb10u7
Dear Maintainer,
This symptom is also ovserved with Buster's following packages:
linux-image-4.19.0-12-686-pae 4.19.152-1
linux-image-686-pae
Control: tags -1 - upstream
I removed the tag upstream, because I was told at the upastream
https://bugzilla.tianocore.org/show_bug.cgi?id=3064#c5
that
(1) Ubuntu/Debian packaging of ovmf should be built with -a X64 -a IA32, or
(2) Ubuntu/Debian packaging of qemu-system-x86_64 should include
.
There seems no actual inconvenience by this, though.
Best regards, Ryutaroh Matsumoto
-- Package-specific info:
** Version:
Linux version 5.9.0-2-686-pae (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.0-16) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian
5.9.6-1 (2020-11-08
Control: tags -1 + patch
Control: retitle -1 patch available: support of UEFI secure boot in
autopkgtest-virt-qemu
With secure boot capable OVMF installed,
I verified that the attached modification to autopkgtest-virt-qemu
starts Linux kernel in a testbed in the locked down mode.
Specifically,
Control: tags -1 + upstream
Control: forwarded -1 https://bugzilla.tianocore.org/show_bug.cgi?id=3064
This seems an upstream issue.
I have brought this to the upstream
https://bugzilla.tianocore.org/show_bug.cgi?id=3064
Ryutaroh
corresponding to
grub-efi-arm64-signed, an armhf QEMU guest seems unable to
utilize the secure boot, even when qemu-efi-arm is installed the host.
Best regards, Ryutaroh Matsumoto
: Property '.secure-memory' not found
Aborted
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)
Kernel: Linux 5.9.0-1-arm64 (SMP w/4 CPU threads
/bugreport.cgi?bug=973571#61
UEFI shell showed up.
I wonder if something wrong in OVMF_VARS_4M.ms.fd...
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64
ld be nice if vmdb2 can make UEFI secure bootable image.
Best regards, Ryutaroh Matsumoto
=secure,value=on
With the above procedure, the kernel in QEMU guest is locked down
(I verified it with dmesg).
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture
I also verified that 32-bit version of OVMF_CODE_4M.ms.fd works.
I did
cp /home/ryutaroh/OVMF_VARS_4M.ms.fd /tmp
qemu-system-i386 -m 1024 -smp 1 -nographic -net nic,model=virtio -net
user,hostfwd=tcp:127.0.0.1:10022-:22 \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device
Control: tags -1 + fixed-upstream
Fixed in upstream as
https://github.com/virt-manager/virt-manager/issues/174
Ryutaroh
]: Failed to start Set console font and
keymap.
Best regards, Ryutaroh Matsumoto
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: arm64 (aarch64)
Kernel: Linux 5.9.0-1-arm64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8
rch64-code\.fd", # upstream qemu
],
"armv7l": [
+r".*AAVMF32_CODE\.fd", # Debian
r".*arm/QEMU_EFI.*", # fedora, gerd's firmware repo
r".*edk2-arm-code\.fd" # upstream qemu
],
Best r
101 - 200 of 377 matches
Mail list logo
