[Bug 1219180] New: Missing framebuffer during boot on aarch64
https://bugzilla.suse.com/show_bug.cgi?id=1219180 Bug ID: 1219180 Summary: Missing framebuffer during boot on aarch64 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/3891664/modules/ansi ble/steps/31 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: fvogt@suse.com QA Contact: qa-bugs@suse.de CC: tzimmermann@suse.com Target Milestone: --- Found By: openQA Blocker: --- Unless the initrd is built with the platform native DRM driver (e.g. virtio_gpu), there is no graphical output during boot. This also means that entering a passphrase for unlocking the root fs is not possible. On x86 it uses the EFI framebuffer successfully, but on aarch64 dmesg has no trace of efifb/simplefb/simpledrm. ## Observation openQA test in scenario microos-Tumbleweed-MicroOS-Image-sdboot-aarch64-microos-wizard@aarch64 fails in [ansible](https://openqa.opensuse.org/tests/3891664/modules/ansible/steps/31) ## Test suite description Like MicroOS, but use neither combustion nor ignition for the intial configuration, so jeos-firstboot runs. ## Reproducible Fails since (at least) Build [20231129](https://openqa.opensuse.org/tests/3771195) ## Expected result Last good: [20231127](https://openqa.opensuse.org/tests/3763820) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=aarch64&distri=microos&flavor=MicroOS-Image-sdboot&machine=aarch64&test=microos-wizard&version=Tumbleweed) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 Ivan Ivanov <ivan.ivanov@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ivan.ivanov@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c1 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|kernel-bugs@opensuse.org |tzimmermann@suse.com --- Comment #1 from Fabian Vogt <fvogt@suse.com> --- Ping -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c2 --- Comment #2 from Thomas Zimmermann <tzimmermann@suse.com> --- This uses virtio_gpu. I assume it runs in an emulator or virtual machine? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c3 --- Comment #3 from Fabian Vogt <fvogt@suse.com> --- (In reply to Thomas Zimmermann from comment #2)
This uses virtio_gpu. I assume it runs in an emulator or virtual machine?
Correct. Other emulated hardware didn't work either (IIRC -vga std) -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c4 --- Comment #4 from Thomas Zimmermann <tzimmermann@suse.com> --- (In reply to Fabian Vogt from comment #3)
(In reply to Thomas Zimmermann from comment #2)
This uses virtio_gpu. I assume it runs in an emulator or virtual machine?
Correct. Other emulated hardware didn't work either (IIRC -vga std)
VGA requires a VGA BIOS, which is x86 code. Under regular aarch64 systems (e.g., Rpi) the firmware's framebuffer is listed in the device tree. But there is no DT here; just UEFI. I've installed MicroOS in Aarch64 qemu to test. The kernel config is correct. There is some support for graphics in the early boot stages (GRUB). -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c5 --- Comment #5 from Fabian Vogt <fvogt@suse.com> --- (In reply to Thomas Zimmermann from comment #4)
(In reply to Fabian Vogt from comment #3)
(In reply to Thomas Zimmermann from comment #2)
This uses virtio_gpu. I assume it runs in an emulator or virtual machine?
Correct. Other emulated hardware didn't work either (IIRC -vga std)
VGA requires a VGA BIOS, which is x86 code.
If the firmware interface and GRUB have video output, GOP is present, so this shouldn't matter.
Under regular aarch64 systems (e.g., Rpi) the firmware's framebuffer is listed in the device tree. But there is no DT here; just UEFI.
I've installed MicroOS in Aarch64 qemu to test. The kernel config is correct. There is some support for graphics in the early boot stages (GRUB).
Does efifb need more than just EFI GOP availability? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 Joey Lee <jlee@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlee@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c6 --- Comment #6 from Thomas Zimmermann <tzimmermann@suse.com> --- Here are the results of my investigation so far. The kernel tries to acquire the UEFI boot framebuffer via find_gop() [1]. It fails for all available results at the pixel_format test at [2]. The firmware only supports the BitBlt() EFI call to read/write framebuffer data. It's a boot service, so it's gone after the kernel initialized. We cannot use it. I've tested with kernel's going back to v6.4. It's always reproducible. To fix this problem, we have modify qemu's OVMF firmware to provide a pixel format and a framebuffer to which we can memcpy(). AFAICT a pixel format of PIXEL_BIT_MASK [3] would do this. [1] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/go... [2] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/go... [3] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ef... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 Matthias Brugger <mbrugger@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |afaerber@suse.com, | |mbrugger@suse.com -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c7 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|Kernel |Virtualization:Tools Assignee|tzimmermann@suse.com |virt-bugs@suse.de --- Comment #7 from Fabian Vogt <fvogt@suse.com> --- That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/952b5cf94c8727b65e04d3d507c0134743be2...). virtio-vga is not available in qemu-system-aarch64 though. So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 Charles Arnold <carnold@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|virt-bugs@suse.de |kvm-bugs@suse.de -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c8 Dario Faggioli <dfaggioli@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(fvogt@suse.com) CC| |dfaggioli@suse.com, | |fvogt@suse.com --- Comment #8 from Dario Faggioli <dfaggioli@suse.com> --- (In reply to Fabian Vogt from comment #0)
## Reproducible
Fails since (at least) Build [20231129](https://openqa.opensuse.org/tests/3771195)
## Expected result
Last good: [20231127](https://openqa.opensuse.org/tests/3763820) (or more recent)
So, I'm curious about this part. Does these "Fails since" and "Last good" mean that this was working at some point, and then it broke? I'm asking because, AFAIK, graphical output until virtio-gpu.ko is loaded has always been the case (but I may be wrong, as I'm not much of an expert of ARM)... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c9 --- Comment #9 from Dario Faggioli <dfaggioli@suse.com> --- (In reply to Fabian Vogt from comment #7)
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/ 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. c#L1029). virtio-vga is not available in qemu-system-aarch64 though.
Sorry, but I also am not sure I understand this part. What do you mean with "virtio-vga is not available in qemu-system-aarch64" ? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c11 Claudio Fontana <claudio.fontana@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |claudio.fontana@suse.com --- Comment #11 from Claudio Fontana <claudio.fontana@suse.com> --- (In reply to Dario Faggioli from comment #9)
(In reply to Fabian Vogt from comment #7)
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/ 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. c#L1029). virtio-vga is not available in qemu-system-aarch64 though.
Sorry, but I also am not sure I understand this part.
What do you mean with "virtio-vga is not available in qemu-system-aarch64" ?
As per: https://qemu-project.gitlab.io/qemu/system/arm/virt.html For ARM, "The recommended option is virtio-gpu-pci; this is the only one which will work correctly with KVM." -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c12 Joey Lee <jlee@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(tzimmermann@suse. | |com) --- Comment #12 from Joey Lee <jlee@suse.com> --- Hi Thomas, (In reply to Thomas Zimmermann from comment #6)
Here are the results of my investigation so far. The kernel tries to acquire the UEFI boot framebuffer via find_gop() [1]. It fails for all available results at the pixel_format test at [2]. The firmware only supports the BitBlt() EFI call to read/write framebuffer data. It's a boot service, so it's gone after the kernel initialized. We cannot use it.
I've tested with kernel's going back to v6.4. It's always reproducible.
To fix this problem, we have modify qemu's OVMF firmware to provide a pixel format and a framebuffer to which we can memcpy(). AFAICT a pixel format of PIXEL_BIT_MASK [3] would do this.
[1] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ gop.c#L521 [2] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ gop.c#L489 [3] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ efistub.h#L519
Could you please teach me how to create a qemu of aarch64 with graphics window? I used the following qemu command for launching a aarch64 guest. But it always only shows message on terminal console. Not graphic window: qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -vnc :93 Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c13 --- Comment #13 from Joey Lee <jlee@suse.com> --- (In reply to Joey Lee from comment #12)
Hi Thomas,
[...snip]
Could you please teach me how to create a qemu of aarch64 with graphics window? I used the following qemu command for launching a aarch64 guest. But it always only shows message on terminal console. Not graphic window:
qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -vnc :93
Thanks!
I have removed "-vnc :93" then using sudo to run the above command. But then I got "gtk initialization failed". -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c14 --- Comment #14 from Stefan Dirsch <sndirsch@suse.com> --- For me it worked to use qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ... -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c15 --- Comment #15 from Joey Lee <jlee@suse.com> --- (In reply to Joey Lee from comment #13)
(In reply to Joey Lee from comment #12)
Hi Thomas,
[...snip]
Could you please teach me how to create a qemu of aarch64 with graphics window? I used the following qemu command for launching a aarch64 guest. But it always only shows message on terminal console. Not graphic window:
qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -vnc :93
Thanks!
I have removed "-vnc :93" then using sudo to run the above command. But then I got "gtk initialization failed".
After removed "-serial mon:stdio", the qemu window is opened. But the installation of MicroOS iso is NOT started. With "-serial mon:stdio", the installation process is started. How could I open an qemu window with root account? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c16 --- Comment #16 from Claudio Fontana <claudio.fontana@suse.com> --- (In reply to Joey Lee from comment #12)
Hi Thomas,
(In reply to Thomas Zimmermann from comment #6)
Here are the results of my investigation so far. The kernel tries to acquire the UEFI boot framebuffer via find_gop() [1]. It fails for all available results at the pixel_format test at [2]. The firmware only supports the BitBlt() EFI call to read/write framebuffer data. It's a boot service, so it's gone after the kernel initialized. We cannot use it.
I've tested with kernel's going back to v6.4. It's always reproducible.
To fix this problem, we have modify qemu's OVMF firmware to provide a pixel format and a framebuffer to which we can memcpy(). AFAICT a pixel format of PIXEL_BIT_MASK [3] would do this.
[1] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ gop.c#L521 [2] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ gop.c#L489 [3] https://elixir.bootlin.com/linux/v6.8/source/drivers/firmware/efi/libstub/ efistub.h#L519
Could you please teach me how to create a qemu of aarch64 with graphics window? I used the following qemu command for launching a aarch64 guest. But it always only shows message on terminal console. Not graphic window:
qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \
Hi @joey, any reason why you are running with cortex-a57 and TCG? The supported environment for AArch64 is KVM, with cpu host. Here is again the set of recommendations for ARM KVM from the QEMU manual: https://www.qemu.org/docs/master/system/target-arm.html https://www.qemu.org/docs/master/system/arm/virt.html This would avoid a lot of trial and error and unsupported combinations: lets test what is actually supported upstream and downstream. Thanks, C
-drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -vnc :93
Thanks! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c17 Thomas Zimmermann <tzimmermann@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(tzimmermann@suse. | |com) | --- Comment #17 from Thomas Zimmermann <tzimmermann@suse.com> --- Created attachment 874812 --> https://bugzilla.suse.com/attachment.cgi?id=874812&action=edit libvirt aarch64 XML config I use libvirt and the rsp desktop helpers for handling virtual machines. IDK how that translates to qemu calls, but I've attached the machine's XML configuration. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c18 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt@suse.com) | --- Comment #18 from Fabian Vogt <fvogt@suse.com> --- (In reply to Dario Faggioli from comment #8)
(In reply to Fabian Vogt from comment #0)
## Reproducible
Fails since (at least) Build [20231129](https://openqa.opensuse.org/tests/3771195)
## Expected result
Last good: [20231127](https://openqa.opensuse.org/tests/3763820) (or more recent)
So, I'm curious about this part. Does these "Fails since" and "Last good" mean that this was working at some point, and then it broke?
In this particular case not, the change that started the failure just exposed this issue. I don't actually remember what it was.
I'm asking because, AFAIK, graphical output until virtio-gpu.ko is loaded has always been the case (but I may be wrong, as I'm not much of an expert of ARM)...
I think so too.(In reply to Stefan Dirsch from comment #14)
For me it worked to use
qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ...
On my x86_64 hosts I just do qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c19 Joey Lee <jlee@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?, SHIP_STOPPER? --- Comment #19 from Joey Lee <jlee@suse.com> --- I am trying to install a aarch64 vm with qemu graphics window but it still failed. I can use the following command with root account to launch a openSUSE-MicroOS aarch64 installation process. The installation direct runs on serial console mode: qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -vnc :93 I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window. The qemu graphics window is created, but I only got a QEMU window with (qemu) promopt. My command is: qemu-system-aarch64 \ -m 4096 -cpu cortex-a57 -smp 4 -M virt \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 I used root account the run the above command. The installation process does NOT show on qemu graphics window. I also tried non-root account, but I always got "usr/libexec/qemu-bridge-helper: bridge helper failed" message. Looks that the net bridge needs root permission. Then I back to root account. Using qemu-kvm and "-cpu host" as the following command: qemu-kvm \ -m 4096 -cpu host -smp 4 \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -serial mon:stdio \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 The above command is failed. I got: qemu-kvm: combined size of system firmware exceeds 8388608 bytes Then I tried to use "-bios" parameter (please note that -bios parameter does NOT support secure boot). THe qemu-kvm command likes this: qemu-kvm \ -m 4096 -cpu host -smp 4 \ -bios /usr/share/qemu/aavmf-aarch64-code.bin \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 The above command is failed. I got: qemu-kvm: -device virtio-blk-device,drive=hd0: No 'virtio-bus' bus found for device 'virtio-blk-device' Simply said, I don't know how to install a aarch64 VM with a qemu graphics window. Because this issue is about graphics. I think that using serial console installation is NOT useful for creating a environment for debugging. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c20 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? | --- Comment #20 from Fabian Vogt <fvogt@suse.com> ---
I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window.
It will work if you do it like mentioned here: (In reply to Fabian Vogt from comment #18)
(In reply to Stefan Dirsch from comment #14)
For me it worked to use
qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ...
On my x86_64 hosts I just do
qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c21 --- Comment #21 from Claudio Fontana <claudio.fontana@suse.com> --- (In reply to Fabian Vogt from comment #20)
I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window.
It will work if you do it like mentioned here:
(In reply to Fabian Vogt from comment #18)
(In reply to Stefan Dirsch from comment #14)
For me it worked to use
qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ...
"qemu-kvm" as a way to launch qemu with the kvm accelerator is not needed and deprecated since a decade. I recommend to use qemu-system-aarch64 -accel kvm Do not spread the use of "qemu-kvm", which ends up in scripts, will break on other architectures, and may be removed in the future. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c22 Joey Lee <jlee@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #22 from Joey Lee <jlee@suse.com> --- Hi Fabian, (In reply to Fabian Vogt from comment #20)
I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window.
It will work if you do it like mentioned here:
(In reply to Fabian Vogt from comment #18)
(In reply to Stefan Dirsch from comment #14)
For me it worked to use
qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ...
On my x86_64 hosts I just do
qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices.
Thanks! Using -device virtio-gpu-pci -serial stdio works to me for launching installation process with qemu graphics window. The following command works on my side: qemu-system-aarch64 \ -m 4096 -cpu cortex-a72 -smp 4 -M virt \ -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars-store.bin \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso,id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c23 --- Comment #23 from Claudio Fontana <claudio.fontana@suse.com> --- (In reply to Joey Lee from comment #22)
Hi Fabian,
(In reply to Fabian Vogt from comment #20)
I have tried to remove "-vnc :93" and "-serial mon:stdio" qemu parameter and hope to launch the installation process in the qemu graphics window.
It will work if you do it like mentioned here:
(In reply to Fabian Vogt from comment #18)
(In reply to Stefan Dirsch from comment #14)
For me it worked to use
qemu-kvm -M virt -m 4096M -bios /usr/share/qemu/aavmf-aarch64-code.bin -cpu host -device virtio-gpu-pci ... -device qemu-xhci -device usb-kbd ...
On my x86_64 hosts I just do
qemu-system-aarch64 -M virt -cpu cortex-a72 -m 2048 -serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd -bios /usr/share/qemu/aavmf-aarch64-code.bin + whatever storage devices.
Thanks! Using -device virtio-gpu-pci -serial stdio works to me for launching installation process with qemu graphics window. The following command works on my side:
qemu-system-aarch64 \ -m 4096 -cpu cortex-a72 -smp 4 -M virt \
Hi Joey, happy it happens to work! Be careful that specifying an exact cpu as you are doing here -cpu cortex-a72 is going to be very dependent on the exact machine you are going to run on. The meaning of -cpu is different than on x86. Does -cpu host work too? Because if it doesn't that is something we really want to fix. Again, that is the supported and recommended option to use for ARM AArch64, I shared the relevant links above. Thanks, C
-serial stdio -device virtio-gpu-pci -device qemu-xhci -device usb-kbd \ -drive if=pflash,format=raw,readonly,file=/usr/share/qemu/aavmf-aarch64-code.bin \ -drive if=pflash,format=raw,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-vars- store.bin \ -net nic,model=virtio -net nic,model=virtio -net bridge,br=br0,helper=/usr/libexec/qemu-bridge-helper \ -drive if=none,file=/home/joeyli/iso/openSUSE-MicroOS-DVD-aarch64-Current.iso, id=hd0 -device virtio-blk-device,drive=hd0 \ -drive if=none,file=/home/joeyli/qemu-vm/openSUSE-MicroOS-aarch64-efi.qcow2,id=hd1 -device virtio-blk-device,drive=hd1 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c24 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo? | --- Comment #24 from Fabian Vogt <fvogt@suse.com> --- (In reply to Claudio Fontana from comment #23)
Be careful that specifying an exact cpu as you are doing here
-cpu cortex-a72
is going to be very dependent on the exact machine you are going to run on. The meaning of -cpu is different than on x86.
Not sure what you mean by that.
Does -cpu host work too? Because if it doesn't that is something we really want to fix.
Without KVM there's no -cpu host:
qemu-system-aarch64 -cpu host -M virt qemu-system-aarch64: unable to find CPU model 'host'
Again, that is the supported and recommended option to use for ARM AArch64, I shared the relevant links above. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c25 --- Comment #25 from Claudio Fontana <claudio.fontana@suse.com> --- (In reply to Fabian Vogt from comment #24)
(In reply to Claudio Fontana from comment #23)
Be careful that specifying an exact cpu as you are doing here
-cpu cortex-a72
is going to be very dependent on the exact machine you are going to run on. The meaning of -cpu is different than on x86.
Not sure what you mean by that.
I mean that when using KVM, named cpu models are not really working for ARM. See: https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html
Does -cpu host work too? Because if it doesn't that is something we really want to fix.
Without KVM there's no -cpu host:
Yes. What I am saying here is: * when using KVM, do not use qemu-kvm. The proper way to use it is qemu-system-aarch64 -accel kvm .
qemu-system-aarch64 -cpu host -M virt qemu-system-aarch64: unable to find CPU model 'host'
Again, that is the supported and recommended option to use for ARM AArch64, I shared the relevant links above.
On the original request, I don't see anything here to do. We know that virtio-gpu-pci works, and we see it working both with KVM and TCG. I continue to recommend to test on actual hardware with KVM, and not with TCG, because that is what is actually supported by us for customers running actual workloads. I do not see anything to do here, can we close? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c26 --- Comment #26 from Fabian Vogt <fvogt@suse.com> --- (In reply to Claudio Fontana from comment #25)
(In reply to Fabian Vogt from comment #24)
(In reply to Claudio Fontana from comment #23)
Be careful that specifying an exact cpu as you are doing here
-cpu cortex-a72
is going to be very dependent on the exact machine you are going to run on. The meaning of -cpu is different than on x86.
Not sure what you mean by that.
I mean that when using KVM, named cpu models are not really working for ARM.
See: https://qemu-project.gitlab.io/qemu/system/arm/cpu-features.html
Does -cpu host work too? Because if it doesn't that is something we really want to fix.
Without KVM there's no -cpu host:
Yes. What I am saying here is:
* when using KVM, do not use qemu-kvm. The proper way to use it is qemu-system-aarch64 -accel kvm .
Without kvm, you must specifiy some -cpu. The default cpu is cortex-a15 which does not have AArch64.
qemu-system-aarch64 -cpu host -M virt qemu-system-aarch64: unable to find CPU model 'host'
Again, that is the supported and recommended option to use for ARM AArch64, I shared the relevant links above.
On the original request, I don't see anything here to do.
We know that virtio-gpu-pci works, and we see it working both with KVM and TCG.
I continue to recommend to test on actual hardware with KVM, and not with TCG, because that is what is actually supported by us for customers running actual workloads.
I do not see anything to do here, can we close?
The bug report is about efifb not working with qemu-system-aarch64. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c27 Dario Faggioli <dfaggioli@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(fvogt@suse.com) --- Comment #27 from Dario Faggioli <dfaggioli@suse.com> --- (In reply to Fabian Vogt from comment #26)
(In reply to Claudio Fontana from comment #25)
I do not see anything to do here, can we close?
The bug report is about efifb not working with qemu-system-aarch64.
Right, so... (In reply to Fabian Vogt from comment #7)
So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice.
...I may still be missing something (not an ARM guy), but my impression is that it's either virtio-gpu-pci or nothing (and I'm talking about upstream). And I still don't think I understand what you meant with this: (In reply to Fabian Vogt from comment #7)
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/ 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. c#L1029). virtio-vga is not available in qemu-system-aarch64 though.
What is it that we're missing? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c28 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt@suse.com) | --- Comment #28 from Fabian Vogt <fvogt@suse.com> --- (In reply to Dario Faggioli from comment #27)
(In reply to Fabian Vogt from comment #26)
(In reply to Claudio Fontana from comment #25)
I do not see anything to do here, can we close?
The bug report is about efifb not working with qemu-system-aarch64.
Right, so...
(In reply to Fabian Vogt from comment #7)
So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice.
...I may still be missing something (not an ARM guy), but my impression is that it's either virtio-gpu-pci or nothing (and I'm talking about upstream).
There's also ramfb, but that's not really usable in practice.
And I still don't think I understand what you meant with this:
(In reply to Fabian Vogt from comment #7)
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/ 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. c#L1029). virtio-vga is not available in qemu-system-aarch64 though.
What is it that we're missing?
I guess either virtio-vga support for aarch64 or somehow support for a linear framebuffer with virtio-gpu-pci. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c29 Claudio Fontana <claudio.fontana@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FEATURE --- Comment #29 from Claudio Fontana <claudio.fontana@suse.com> --- (In reply to Fabian Vogt from comment #28)
(In reply to Dario Faggioli from comment #27)
(In reply to Fabian Vogt from comment #26)
(In reply to Claudio Fontana from comment #25)
I do not see anything to do here, can we close?
The bug report is about efifb not working with qemu-system-aarch64.
Right, so...
(In reply to Fabian Vogt from comment #7)
So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice.
...I may still be missing something (not an ARM guy), but my impression is that it's either virtio-gpu-pci or nothing (and I'm talking about upstream).
There's also ramfb, but that's not really usable in practice.
And I still don't think I understand what you meant with this:
(In reply to Fabian Vogt from comment #7)
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/ 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. c#L1029). virtio-vga is not available in qemu-system-aarch64 though.
What is it that we're missing?
I guess either virtio-vga support for aarch64 or somehow support for a linear framebuffer with virtio-gpu-pci.
unfortunately I think if ramfb is not enough, we do not have any other option available for AArch64 at the moment. Seems that this has been a missing feature on AArch64 for a while, see for example also this bug from 2019 that has a good description: https://bugzilla.redhat.com/show_bug.cgi?id=1679680 I would have to close this as FEATURE for now, since making progress on this would require implementing a new feature for ARM upstream. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c30 --- Comment #30 from Fabian Vogt <fvogt@suse.com> --- (In reply to Claudio Fontana from comment #29)
(In reply to Fabian Vogt from comment #28)
(In reply to Dario Faggioli from comment #27)
(In reply to Fabian Vogt from comment #26)
(In reply to Claudio Fontana from comment #25)
I do not see anything to do here, can we close?
The bug report is about efifb not working with qemu-system-aarch64.
Right, so...
(In reply to Fabian Vogt from comment #7)
So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice.
...I may still be missing something (not an ARM guy), but my impression is that it's either virtio-gpu-pci or nothing (and I'm talking about upstream).
There's also ramfb, but that's not really usable in practice.
And I still don't think I understand what you meant with this:
(In reply to Fabian Vogt from comment #7)
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/ 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. c#L1029). virtio-vga is not available in qemu-system-aarch64 though.
What is it that we're missing?
I guess either virtio-vga support for aarch64 or somehow support for a linear framebuffer with virtio-gpu-pci.
unfortunately I think if ramfb is not enough, we do not have any other option available for AArch64 at the moment.
Seems that this has been a missing feature on AArch64 for a while, see for example also this bug from 2019 that has a good description:
https://bugzilla.redhat.com/show_bug.cgi?id=1679680
I would have to close this as FEATURE for now, since making progress on this would require implementing a new feature for ARM upstream.
So where do we go from here? JIRA ticket? -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c31 Joey Lee <jlee@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?, | |needinfo?(tzimmermann@suse. | |com) Resolution|FEATURE |FIXED --- Comment #31 from Joey Lee <jlee@suse.com> --- Hi Thomas, I have installed a MicroOS guest success. But I got problem when debugging kernel. I have cross-compiler kernel with aarch64 on my build server, then I tried to run "make modules_install" in MicroOS guest but I got "Read-only file system" because root partition is read-only on MicroOS. Then I tried to use "transactional-update run make modules_install", but it shows "No rule to make target modules_install". Do you know how to install a kernel from a kernel source tree on MicroOS? Thanks a lot! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c32 --- Comment #32 from Claudio Fontana <claudio.fontana@suse.com> --- (In reply to Fabian Vogt from comment #30)
(In reply to Claudio Fontana from comment #29)
(In reply to Fabian Vogt from comment #28)
(In reply to Dario Faggioli from comment #27)
(In reply to Fabian Vogt from comment #26)
(In reply to Claudio Fontana from comment #25)
I do not see anything to do here, can we close?
The bug report is about efifb not working with qemu-system-aarch64.
Right, so...
(In reply to Fabian Vogt from comment #7)
So a question for the virtualization team (qemu + ovmf): What's the right controller to use to get this to work? I guess ramfb might work but it's too limited to be usable in practice.
...I may still be missing something (not an ARM guy), but my impression is that it's either virtio-gpu-pci or nothing (and I'm talking about upstream).
There's also ramfb, but that's not really usable in practice.
And I still don't think I understand what you meant with this:
(In reply to Fabian Vogt from comment #7)
That explains it. Looking at the EDK II source, the driver for virtio-gpu-pci does not expose a linear framebuffer, only virtio-vga does (https://github.com/tianocore/edk2/blob/ 952b5cf94c8727b65e04d3d507c0134743be2a66/OvmfPkg/Virtio10Dxe/Virtio10. c#L1029). virtio-vga is not available in qemu-system-aarch64 though.
What is it that we're missing?
I guess either virtio-vga support for aarch64 or somehow support for a linear framebuffer with virtio-gpu-pci.
unfortunately I think if ramfb is not enough, we do not have any other option available for AArch64 at the moment.
Seems that this has been a missing feature on AArch64 for a while, see for example also this bug from 2019 that has a good description:
https://bugzilla.redhat.com/show_bug.cgi?id=1679680
I would have to close this as FEATURE for now, since making progress on this would require implementing a new feature for ARM upstream.
So where do we go from here? JIRA ticket?
Tf this is something that we need to implement for the products, yes. Adding a few words about the more general context and the actual use case is likely to help. -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c33 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |FEATURE Flags|needinfo?, | |needinfo?(tzimmermann@suse. | |com) | --- Comment #33 from Fabian Vogt <fvogt@suse.com> --- I'll file a separate bug for the specific issue here, which is that drm support is missing in the initrd for encryption prompts. (It's not fixed, setting status to RESOLVED FEATURE again) (In reply to Joey Lee from comment #31)
Hi Thomas,
I have installed a MicroOS guest success. But I got problem when debugging kernel.
Any reason to use MicroOS specifically? Using TW should be fine here.
I have cross-compiler kernel with aarch64 on my build server, then I tried to run "make modules_install" in MicroOS guest but I got "Read-only file system" because root partition is read-only on MicroOS.
Then I tried to use "transactional-update run make modules_install", but it shows "No rule to make target modules_install".
Do you know how to install a kernel from a kernel source tree on MicroOS?
The easiest option is probably to install microos-devel-tools and use microos-rw to make the snapshot read-write temporarily.
Thanks a lot! -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |1224404 -- You are receiving this mail because: You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1219180 https://bugzilla.suse.com/show_bug.cgi?id=1219180#c34 Fabian Vogt <fvogt@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.suse.com/s | |how_bug.cgi?id=1224404 Blocks|1224404 | --- Comment #34 from Fabian Vogt <fvogt@suse.com> --- (In reply to Fabian Vogt from comment #33)
I'll file a separate bug for the specific issue here, which is that drm support is missing in the initrd for encryption prompts.
Done: bug 1224404 -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com