Warning : Failed to set up UEFI / The Libvirt version does not support UEFI / Install options are limited...
Mario Marietto
marietto2008 at gmail.com
Tue Aug 22 19:44:00 UTC 2023
Hello,
Pavel,are you there ? Please help me to give it the last push. I've fixed
the last error like so :
root at devuan:~/Desktop/libvirt/build# update-alternatives --set iptables
/usr/sbin/iptables-legacy
update-alternatives: using /usr/sbin/iptables-legacy to provide
/usr/sbin/iptables (iptables) in manual mode
but now I have got another error. Anyway,I feel to be close :
root at devuan:~/Desktop/libvirt/build# sudo ./run src/virtlockd & sudo ./run
src/virtlogd & sudo ./run src/libvirtd
2023-08-22 19:38:49.036+0000: 15002: info : libvirt version: 9.7.0
hostname: devuan
error : virPidFileAcquirePathFull:409 : Failed to acquire pid file
'/root/libvirt_build/var/run/virtlockd.pid': Resource temporarily
unavailable
On Tue, Aug 22, 2023 at 7:01 PM Mario Marietto <marietto2008 at gmail.com>
wrote:
> Et voila'. I've recompiled libvirt in this way :
>
> git clone https://github.com/libvirt/libvirt.git
> mkdir -p libvirt_build
> cd libvirt
> apt install meson xsltproc libgnutls28-dev libxml2-dev rst2pdf
> meson build --prefix=$HOME/libvirt_build
> ninja -C build
> sudo ninja -C build install
> cd build
> nano vai.sh :
>
> sudo ./run src/virtlockd & sudo ./run src/virtlogd & sudo ./run
> src/libvirtd
>
> chmod +x vai.sh
>
> this is the error I get :
>
> root at devuan:~/Desktop/libvirt/build# ./vai.sh
>
> 2023-08-22 16:52:34.416+0000: 14725: info : libvirt version: 9.7.0
> 2023-08-22 16:52:34.416+0000: 14725: info : hostname: devuan
> 2023-08-22 16:52:34.416+0000: 14725: error :
> virFirewallApplyRuleDirect:518 : internal error: Failed to apply
> firewall rules /usr/sbin/iptables -w --table filter --list-rules:
> iptables: Failed to initialize nft: Protocol not supported
>
> 2023-08-22 16:52:34.428+0000: 14725: error :
> virFirewallApplyRuleDirect:518 : internal error: Failed to apply firewall
> rules /usr/sbin/ip6tables -w --table filter --list-rules: ip6tables: Failed
> to initialize nft: Protocol not supported
>
> On Tue, Aug 22, 2023 at 6:49 PM Pavel Hrdina <phrdina at redhat.com> wrote:
>
>> On Tue, Aug 22, 2023 at 06:22:25PM +0200, Mario Marietto wrote:
>> > In your opinion should I remove virt-manager and all its dependencies
>> > before launching the recompilation ?
>>
>> I would say there is no need to do that if you install libvirt to
>> /usr/local as it should be separated from the libvirt installed by
>> package manager.
>>
>> Pavel
>>
>> >
>> > On Tue, Aug 22, 2023 at 6:05 PM Pavel Hrdina <phrdina at redhat.com>
>> wrote:
>> >
>> > > On Tue, Aug 22, 2023 at 05:55:30PM +0200, Mario Marietto wrote:
>> > > > I have installed virt-manager and all its dependencies grabbing the
>> files
>> > > > from the devuan 5 repository.
>> > > > To recompile libvirt I need to acquire some basic information. Which
>> > > > version should I compile ? Where is the source code located ? Do
>> you have
>> > > > some tutorial that explains the necessary steps to do it ? thanks.
>> > >
>> > > Everything can be found at https://libvirt.org/ not sure which
>> version
>> > > to pick, you can try latest upstream version but there might be some
>> > > dependencies missing in Devuan, if that happens you can fallback to
>> > > version that is provided by Devuan.
>> > >
>> > > For example this link has basic info on how to compile libvirt
>> > > https://libvirt.org/compiling.html and here you can find sources
>> > > to libvirt https://libvirt.org/downloads.html .
>> > >
>> > > Pavel
>> > >
>> > > > On Tue, Aug 22, 2023 at 5:50 PM Pavel Hrdina <phrdina at redhat.com>
>> wrote:
>> > > >
>> > > > > On Tue, Aug 22, 2023 at 05:28:50PM +0200, Mario Marietto wrote:
>> > > > > > root at devuan:~# virsh domcapabilities --machine virt
>> --emulatorbin
>> > > > > > /usr/bin/qemu-system-arm
>> > > > > >
>> > > > > > error: failed to get emulator capabilities
>> > > > > > error: KVM is not supported on this platform: Function not
>> > > implemented
>> > > > > >
>> > > > > > BUT it's not true :
>> > > > > >
>> > > > > > root at devuan:~# kvm-ok
>> > > > > >
>> > > > > > INFO: /dev/kvm exists
>> > > > > > KVM acceleration can be used
>> > > > >
>> > > > > Are you using libvirt installed using package manager or some
>> libvirt
>> > > > > that you compiled yorself? Checking libvirt code this error only
>> > > happens
>> > > > > if libvirt was compiled without KVM, more specifically if header
>> > > > > `/usr/include/linux/kvm.h` doesn't exists.
>> > > > >
>> > > > > I was not able to find any details on Devuan distro so not sure
>> how
>> > > > > the libvirt package is compiled. You might need to try compiling
>> > > libvirt
>> > > > > yourself.
>> > > > >
>> > > > > Pavel
>> > > > >
>> > > > > >
>> > > > > > On Tue, Aug 22, 2023 at 5:27 PM Mario Marietto <
>> > > marietto2008 at gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Oh sorry....
>> > > > > > >
>> > > > > > > On Tue, Aug 22, 2023 at 5:26 PM Mario Marietto <
>> > > marietto2008 at gmail.com
>> > > > > >
>> > > > > > > wrote:
>> > > > > > >
>> > > > > > >> virsh domcapabilities --machine virt --emulatorbin
>> > > > > > >> /path/to/qemu-system-arm
>> > > > > > >>
>> > > > > > >> error: failed to get emulator capabilities
>> > > > > > >> error: Cannot check QEMU binary /path/to/qemu-system-arm: No
>> such
>> > > > > file or
>> > > > > > >> directory
>> > > > > > >>
>> > > > > > >> On Tue, Aug 22, 2023 at 4:49 PM Pavel Hrdina <
>> phrdina at redhat.com>
>> > > > > wrote:
>> > > > > > >>
>> > > > > > >>> On Tue, Aug 22, 2023 at 04:05:09PM +0200, Mario Marietto
>> wrote:
>> > > > > > >>> > Where does libvirt want to find those files ? since the
>> qemu
>> > > 5.1
>> > > > > > >>> > installation files have been placed under /usr/local
>> during the
>> > > > > command
>> > > > > > >>> > make install,I have also copied the firmware files in :
>> > > > > > >>> >
>> > > > > > >>> > ls /usr/local/share/AAVMF
>> > > > > > >>> >
>> > > > > > >>> > AAVMF32_CODE.fd AAVMF_CODE.fd AAVMF_CODE.snakeoil.fd
>> > > > > > >>> AAVMF_VARS.ms.fd
>> > > > > > >>> > AAVMF32_VARS.fd AAVMF_CODE.ms.fd AAVMF_VARS.fd
>> > > > > > >>> > AAVMF_VARS.snakeoil.fd
>> > > > > > >>> >
>> > > > > > >>> > but they aren't still recognized.
>> > > > > > >>>
>> > > > > > >>> Downgrading libvirt would not help in this specific case.
>> Since
>> > > > > version
>> > > > > > >>> 5.2.0 libvirt uses firmware auto-selection. Libvirt is
>> looking
>> > > for
>> > > > > json
>> > > > > > >>> files describing available firmwares. It is documented in
>> QEMU
>> > > > > project
>> > > > > > >>> git repository in `docs/interop/firmware.json`, this
>> specific
>> > > section
>> > > > > > >>> describes where the json files should be placed:
>> > > > > > >>>
>> > > > > > >>> # It is recommended to create firmware JSON files (each
>> > > containing a
>> > > > > > >>> # single @Firmware root element) with a double-digit
>> prefix, for
>> > > > > example
>> > > > > > >>> # "50-ovmf.json", "50-seabios-256k.json", etc, so they can
>> be
>> > > sorted
>> > > > > in
>> > > > > > >>> # predictable order. The firmware JSON files should be
>> searched
>> > > for
>> > > > > in
>> > > > > > >>> # three directories:
>> > > > > > >>> #
>> > > > > > >>> # - /usr/share/qemu/firmware -- populated by
>> distro-provided
>> > > > > firmware
>> > > > > > >>> # packages (XDG_DATA_DIRS
>> covers
>> > > > > > >>> # /usr/share by default),
>> > > > > > >>> #
>> > > > > > >>> # - /etc/qemu/firmware -- exclusively for sysadmins' local
>> > > > > additions,
>> > > > > > >>> #
>> > > > > > >>> # - $XDG_CONFIG_HOME/qemu/firmware -- exclusively for
>> per-user
>> > > > > local
>> > > > > > >>> # additions
>> > > (XDG_CONFIG_HOME
>> > > > > > >>> # defaults to
>> > > $HOME/.config).
>> > > > > > >>>
>> > > > > > >>> It doesn't matter where the *CODE* and *VARS* firmware
>> files are
>> > > > > placed
>> > > > > > >>> if the path to these files is correct in the json files in
>> one
>> > > of the
>> > > > > > >>> three directories.
>> > > > > > >>>
>> > > > > > >>> Looking at the qemu-efi-arm package it should install
>> > > > > > >>>
>> > > > > > >>> /usr/share/AAVMF/AAVMF32_CODE.fd
>> > > > > > >>> /usr/share/AAVMF/AAVMF32_VARS.fd
>> > > > > > >>> /usr/share/qemu/firmware/60-edk2-arm.json
>> > > > > > >>>
>> > > > > > >>> and that should be picked up correctly by libvirt.
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> I don't know what machine types are available for 32bit
>> ARM, but
>> > > you
>> > > > > > >>> should be able to figure that out by running:
>> > > > > > >>>
>> > > > > > >>> virsh capabilities | grep canonical
>> > > > > > >>>
>> > > > > > >>> it will show only lines with machine types, but my guess is
>> on
>> > > arm
>> > > > > there
>> > > > > > >>> should be 'virt' machine type so running
>> > > > > > >>>
>> > > > > > >>> virsh domcapabilities --machine virt --emulatorbin
>> > > > > > >>> /path/to/qemu-system-arm
>> > > > > > >>>
>> > > > > > >>> where you should be able to see the firmware paths if they
>> are
>> > > > > correctly
>> > > > > > >>> detected by libvirt.
>> > > > > > >>>
>> > > > > > >>> Pavel
>> > > > > > >>>
>> > > > > > >>>
>> > > > > > >>> > On Tue, Aug 22, 2023 at 3:55 PM Mario Marietto <
>> > > > > marietto2008 at gmail.com
>> > > > > > >>> >
>> > > > > > >>> > wrote:
>> > > > > > >>> >
>> > > > > > >>> > > I've already did that :
>> > > > > > >>> > >
>> > > > > > >>> > > # apt install qemu-efi-arm
>> > > > > > >>> > >
>> > > > > > >>> > > Reading package lists... Done
>> > > > > > >>> > > Building dependency tree... Done
>> > > > > > >>> > > Reading state information... Done
>> > > > > > >>> > > qemu-efi-arm is already the newest version (2022.11-6).
>> > > > > > >>> > > qemu-efi-arm set to manually installed.
>> > > > > > >>> > >
>> > > > > > >>> > > if I don't get wrong,that package do the installation
>> of the
>> > > > > > >>> following
>> > > > > > >>> > > files :
>> > > > > > >>> > >
>> > > > > > >>> > > root at devuan:/usr/share/AAVMF# ls
>> > > > > > >>> > >
>> > > > > > >>> > > AAVMF32_CODE.fd AAVMF_CODE.fd
>> AAVMF_CODE.snakeoil.fd
>> > > > > > >>> > > AAVMF_VARS.ms.fd
>> > > > > > >>> > > AAVMF32_VARS.fd AAVMF_CODE.ms.fd AAVMF_VARS.fd
>> > > > > > >>> > > AAVMF_VARS.snakeoil.fd
>> > > > > > >>> > >
>> > > > > > >>> > > in my case they have been correctly placed under
>> > > /usr/share/AAVMF
>> > > > > > >>> > >
>> > > > > > >>> > > I'm not sure that the problem is there. The error
>> message
>> > > talks
>> > > > > > >>> about the
>> > > > > > >>> > > libvirt version that could be wrong. What about if I
>> > > retrocede
>> > > > > > >>> libirt 7.0
>> > > > > > >>> > > to 6.9 for example. Why 6.9 ?
>> > > > > > >>> > >
>> > > > > > >>> > >
>> > > > > > >>> > > As you can read below,it supports qemu 5.0 and newer...
>> > > > > > >>> > >
>> > > > > > >>> > > v6.9.0 (2020-11-02)
>> > > > > > >>> > >
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > *New features*
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > nodedev: Add support for channel subsystem (CSS)
>> > > devices on
>> > > > > > >>> S390
>> > > > > > >>> > >
>> > > > > > >>> > > A CSS device is represented as a parent device of
>> a CCW
>> > > > > device.
>> > > > > > >>> > > This support allows to create vfio-ccw mediated
>> devices
>> > > > > with
>> > > > > > >>> > > virNodeDeviceCreateXML().
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > qemu: Implement memory failure event
>> > > > > > >>> > >
>> > > > > > >>> > > New event is implemented that is emitted whenever
>> a
>> > > guest
>> > > > > > >>> > > encounters a memory failure.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > qemu: Implement support for <transient/> disks
>> > > > > > >>> > >
>> > > > > > >>> > > VMs based on the QEMU hypervisor now can use
>> > > <transient/>
>> > > > > > >>> option
>> > > > > > >>> > > for local file-backed disks to configure a disk
>> which
>> > > > > discards
>> > > > > > >>> changes made
>> > > > > > >>> > > to it while the VM was active.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > hyperv: implement new APIs
>> > > > > > >>> > >
>> > > > > > >>> > > The virConnectGetCapabilities(),
>> > > virConnectGetMaxVcpus(),
>> > > > > > >>> > > virConnectGetVersion(), virDomainGetAutostart(),
>> > > > > > >>> > > virDomainSetAutostart(), virNodeGetFreeMemory(),
>> > > > > > >>> virDomainReboot(),
>> > > > > > >>> > > virDomainReset(), virDomainShutdown(), and
>> > > > > > >>> virDomainShutdownFlags()
>> > > > > > >>> > > APIs have been implemented in the Hyper-V driver.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > bhyve: implement virtio-9p filesystem support
>> > > > > > >>> > >
>> > > > > > >>> > > Implement virito-9p shared filesystem using the
>> > > > > <filesystem/>
>> > > > > > >>> > > element.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > qemu: Add support for vDPA network devices.
>> > > > > > >>> > >
>> > > > > > >>> > > VMs using the QEMU hypervisor can now specify vDPA
>> > > network
>> > > > > > >>> devices
>> > > > > > >>> > > using <interface type='vdpa'>. The node device
>> APIs
>> > > also
>> > > > > now
>> > > > > > >>> list
>> > > > > > >>> > > and provide XML descriptions for vDPA devices.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > cpu_map: Add EPYC-Rome CPU model
>> > > > > > >>> > >
>> > > > > > >>> > > *It's supported in QEMU 5.0.0 and newer.*
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > cpu: Add a flag for XML validation in CPU
>> comparison
>> > > > > > >>> > >
>> > > > > > >>> > > The virConnectCompareCPU and
>> > > virConnectCompareHypervisorCPU
>> > > > > > >>> API now
>> > > > > > >>> > > support the VIR_CONNECT_COMPARE_CPU_VALIDATE_XML
>> flag,
>> > > > > which
>> > > > > > >>> > > enables XML validation. For virsh, this feature is
>> > > enabled
>> > > > > by
>> > > > > > >>> passing the
>> > > > > > >>> > > --validate option to the cpu-compare and
>> > > > > hypervisor-cpu-compare
>> > > > > > >>> > > subcommands.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > qemu: Introduce virtio-balloon free page reporting
>> > > feature
>> > > > > > >>> > >
>> > > > > > >>> > > Introduce the optional attribute
>> free-page-reporting
>> > > for
>> > > > > virtio
>> > > > > > >>> > > memballoon device. It enables/disables the
>> ability of
>> > > the
>> > > > > QEMU
>> > > > > > >>> virtio
>> > > > > > >>> > > memory balloon to return unused pages back to the
>> > > > > hypervisor.
>> > > > > > >>> QEMU 5.1 and
>> > > > > > >>> > > newer support this feature.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > *Improvements*
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > qemu: Make 'cbitpos' & 'reducedPhysBits' attrs
>> optional
>> > > > > > >>> > >
>> > > > > > >>> > > Libvirt probes the underlying platform in order to
>> > > fill in
>> > > > > > >>> these
>> > > > > > >>> > > SEV attributes automatically before launching a
>> guest.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > util: support device stats collection for SR-IOV
>> VF
>> > > hostdev
>> > > > > > >>> > >
>> > > > > > >>> > > For SR-IOV VF hostdevs, libvirt now supports
>> retrieving
>> > > > > device
>> > > > > > >>> > > traffic stats via the virDomainInterfaceStats API
>> and
>> > > virsh
>> > > > > > >>> > > domifstat.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > logging: Allow disabling log rollover
>> > > > > > >>> > >
>> > > > > > >>> > > Set max_len=0 in virtlogd.conf to disable log
>> rollover.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > qemu: Set noqueue qdisc for TAP devices
>> > > > > > >>> > >
>> > > > > > >>> > > Set noqueue instead of the former pfifo_fast queue
>> > > > > discipline
>> > > > > > >>> for
>> > > > > > >>> > > TAP devices. It will avoid needless cost of host
>> CPU
>> > > cycles
>> > > > > > >>> and thus
>> > > > > > >>> > > improve performance.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > qemu: virtiofs can be used without NUMA nodes
>> > > > > > >>> > >
>> > > > > > >>> > > Virtiofs is supported for the VM without NUMA
>> nodes but
>> > > > > > >>> configured
>> > > > > > >>> > > with shared memory.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > *Bug fixes*
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > hyperv: ensure WQL queries work in all locales
>> > > > > > >>> > >
>> > > > > > >>> > > Relying on the "Description" field caused queries
>> to
>> > > fail
>> > > > > on
>> > > > > > >>> > > non-"en-US" systems. The queries have been
>> updated to
>> > > avoid
>> > > > > > >>> using localized
>> > > > > > >>> > > strings.
>> > > > > > >>> > > -
>> > > > > > >>> > >
>> > > > > > >>> > > rpc: Fix virt-ssh-helper detection
>> > > > > > >>> > >
>> > > > > > >>> > > libvirt 6.8.0 failed to correctly detect the
>> > > availability
>> > > > > of
>> > > > > > >>> the
>> > > > > > >>> > > new virt-ssh-helper command on the remote host,
>> and
>> > > thus
>> > > > > always
>> > > > > > >>> > > used the fallback instead; this has now been
>> fixed.
>> > > > > > >>> > >
>> > > > > > >>> > >
>> > > > > > >>> > > What do you think ? Can you share some documentation
>> about
>> > > how to
>> > > > > > >>> > > recompile an older version of libvirt from source code ?
>> > > thanks.
>> > > > > > >>> > >
>> > > > > > >>> > > On Tue, Aug 22, 2023 at 3:35 PM Pavel Hrdina <
>> > > phrdina at redhat.com
>> > > > > >
>> > > > > > >>> wrote:
>> > > > > > >>> > >
>> > > > > > >>> > >> On Tue, Aug 22, 2023 at 02:49:05PM +0200, Mario
>> Marietto
>> > > wrote:
>> > > > > > >>> > >> > Hello to everyone.
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > I'm trying to use qemu 5.1 with virt-manager and
>> libvirt
>> > > on
>> > > > > my ARM
>> > > > > > >>> > >> > chromebook (armhf 32 bit cpu) running with Devuan 4
>> as
>> > > host
>> > > > > o.s.
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > By default it uses qemu and its dependencies,version
>> 5.2.
>> > > I
>> > > > > > >>> remember
>> > > > > > >>> > >> that I
>> > > > > > >>> > >> > can't use qemu 5.2,because it doesn't have any
>> support for
>> > > > > KVM as
>> > > > > > >>> you
>> > > > > > >>> > >> can
>> > > > > > >>> > >> > read here :
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>>
>> > > https://lists.gnu.org/archive/html/qemu-devel/2020-09/msg02074.html
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > For this reason,I've compiled qemu 5.1 from source.
>> Below
>> > > I
>> > > > > shown
>> > > > > > >>> how I
>> > > > > > >>> > >> > have configured everything such as a little piece of
>> > > > > compilation
>> > > > > > >>> > >> messages :
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > # apt install libgtk-3-dev libpulse-dev libgbm-dev
>> > > > > > >>> libspice-protocol-dev
>> > > > > > >>> > >> > libspice-server-dev libusb-1.0-0-dev libepoxy-dev
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > # cp
>> /root/Desktop/qemu-v5.1.0/arm-softmmu/qemu-system-arm
>> > > > > > >>> /usr/bin
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > # CFLAGS=-Wno-error ./configure
>> > > --target-list=x86_64-softmmu
>> > > > > > >>> > >> --enable-opengl
>> > > > > > >>> > >> > --enable-gtk --enable-kvm --enable-guest-agent
>> > > --enable-spice
>> > > > > > >>> > >> --audio-drv-
>> > > > > > >>> > >> > list="oss pa" --enable-libusb
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > A little piece of the log messages that I've got
>> from the
>> > > > > > >>> compilation of
>> > > > > > >>> > >> > qemu 5.1 :
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > https://pastebin.ubuntu.com/p/8DYfgPvhXy/
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > These are the resulting versions of my frankenstein
>> > > operation
>> > > > > :
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > # virsh version
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > Compiled against library: libvirt 7.0.0
>> > > > > > >>> > >> > Using library: libvirt 7.0.0
>> > > > > > >>> > >> > Using API: QEMU 7.0.0
>> > > > > > >>> > >> > Running hypervisor: QEMU 5.1.0
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > At this point I ran virt-manager. It has been able to
>> > > detect
>> > > > > > >>> qemu,but I
>> > > > > > >>> > >> get
>> > > > > > >>> > >> > the following error :
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > Warning : Failed to set up UEFI.
>> > > > > > >>> > >> > The Libvirt version does not support UEFI.
>> > > > > > >>> > >> > Install options are limited.
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > (I have also tried upgrading devuan 4 with devuan 5
>> and
>> > > I've
>> > > > > got
>> > > > > > >>> the
>> > > > > > >>> > >> same
>> > > > > > >>> > >> > error :
>> > > > > > >>> > >>
>> > > > > > >>> > >> You most likely need to install qemu-efi-arm package
>> which
>> > > > > should
>> > > > > > >>> > >> provide 32bit arm firmware files. The package name is
>> a bit
>> > > > > > >>> confusing
>> > > > > > >>> > >> as it doesn't originate from qemu project, it is from
>> edk2
>> > > > > project.
>> > > > > > >>> > >>
>> > > > > > >>> > >> Without this package libvirt most likely doesn't
>> report any
>> > > efi
>> > > > > > >>> files
>> > > > > > >>> > >> and that's what causes the error you are hitting.
>> > > > > > >>> > >>
>> > > > > > >>> > >> Pavel
>> > > > > > >>> > >>
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > root at devuan:/usr/bin# virsh version
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > Compiled against library: libvirt 9.0.0
>> > > > > > >>> > >> > Using library: libvirt 9.0.0
>> > > > > > >>> > >> > Using API: QEMU 9.0.0
>> > > > > > >>> > >> > Running hypervisor: QEMU 5.1.0
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > If I change qemu-system-arm vers. 5.1 with
>> qemu-system-arm
>> > > > > > >>> 5.2,the error
>> > > > > > >>> > >> > disappears. So,it seems that libvirt does not accept
>> > > > > > >>> qemu-system-arm
>> > > > > > >>> > >> vers.
>> > > > > > >>> > >> > 5.1 or maybe any version lower than 5.2,I don't
>> know. But
>> > > as
>> > > > > I've
>> > > > > > >>> said,I
>> > > > > > >>> > >> > can't use any version of qemu greater or equal to
>> 5.2 on
>> > > my
>> > > > > > >>> setup. And I
>> > > > > > >>> > >> > want to use virt-manager and libvirt because I find
>> these
>> > > > > tools
>> > > > > > >>> very
>> > > > > > >>> > >> > comfortable instead of using the "raw" qemu
>> parameters. Is
>> > > > > there a
>> > > > > > >>> > >> > workaround ? Maybe I can recompile virt-manager and
>> / or
>> > > > > libvirt
>> > > > > > >>> from
>> > > > > > >>> > >> the
>> > > > > > >>> > >> > source code ? but how ? Do you think that it could
>> work
>> > > if I
>> > > > > use
>> > > > > > >>> > >> something
>> > > > > > >>> > >> > like this (if it exists and if it can be reached in
>> some
>> > > way)
>> > > > > :
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > Compiled against library: libvirt 5.0.0
>> > > > > > >>> > >> > Using library: libvirt 5.0.0
>> > > > > > >>> > >> > Using API: QEMU 5.0.0
>> > > > > > >>> > >> > Running hypervisor: QEMU 5.1.0
>> > > > > > >>> > >> >
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > thanks.
>> > > > > > >>> > >> >
>> > > > > > >>> > >> > --
>> > > > > > >>> > >> > Mario.
>> > > > > > >>> > >>
>> > > > > > >>> > >
>> > > > > > >>> > >
>> > > > > > >>> > > --
>> > > > > > >>> > > Mario.
>> > > > > > >>> > >
>> > > > > > >>> >
>> > > > > > >>> >
>> > > > > > >>> > --
>> > > > > > >>> > Mario.
>> > > > > > >>>
>> > > > > > >>
>> > > > > > >>
>> > > > > > >> --
>> > > > > > >> Mario.
>> > > > > > >>
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Mario.
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Mario.
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Mario.
>> > >
>> >
>> >
>> > --
>> > Mario.
>>
>
>
> --
> Mario.
>
--
Mario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20230822/8cdc271d/attachment-0001.htm>
More information about the virt-tools-list
mailing list