I noticed that Dnfdragora needs a lot of time to prepare for updates.
Just to show the available updates it takes in my opinion to long. I use F33 with libvirt as guest.
My host OS is Fedora32 Gnome with installed mate desktop.
When i do dnf update in terminal it not takes so long.
What is the best way to debug it?
DNF i allready optimized a bit.
QEMU: Checking for hardware virtualization : PASS
QEMU: Checking if device /dev/kvm exists : PASS
QEMU: Checking if device /dev/kvm is accessible : PASS
QEMU: Checking if device /dev/vhost-net exists : PASS
QEMU: Checking if device /dev/net/tun exists : PASS
QEMU: Checking for cgroup 'cpu' controller support : WARN (Enable 'cpu' in kernelKconfig file or mount/enable cgroup controller in your system)
QEMU: Checking for cgroup 'cpuacct' controller support : PASS
QEMU: Checking for cgroup 'cpuset' controller support : WARN (Enable 'cpuset' in kernel Kconfig file or mount/enable cgroup controller in your system)
QEMU: Checking for cgroup 'memory' controller support : PASS
QEMU: Checking for cgroup 'devices' controller support : PASS
QEMU: Checking for cgroup 'blkio' controller support : WARN (Enable 'blkio' in kernel Kconfig file or mount/enable cgroup controller in your system)
QEMU: Checking for device assignment IOMMU support : PASS
QEMU: Checking if IOMMU is enabled by kernel : WARN (IOMMU appears to be disabled in kernel. Add intel_iommu=on to kernel cmdline arguments)
LXC: Checking for Linux >= 2.6.26 : PASS
LXC: Checking for namespace ipc : PASS
LXC: Checking for namespace mnt : PASS
LXC: Checking for namespace pid : PASS
LXC: Checking for namespace uts : PASS
LXC: Checking for namespace net : PASS
LXC: Checking for namespace user : PASS
LXC: Checking for cgroup 'cpu' controller support : FAIL (Enable 'cpu' in kernel Kconfig file or mount/enable cgroup controller in your system)
LXC: Checking for cgroup 'cpuacct' controller support : PASS
LXC: Checking for cgroup 'cpuset' controller support : FAIL (Enable 'cpuset' in kernel Kconfig file or mount/enable cgroup controller in your system)
LXC: Checking for cgroup 'memory' controller support : PASS
LXC: Checking for cgroup 'devices' controller support : PASS
LXC: Checking for cgroup 'freezer' controller support : FAIL (Enable 'freezer' in kernel Kconfig file or mount/enable cgroup controller in your system)
LXC: Checking for cgroup 'blkio' controller support : FAIL (Enable 'blkio' in kernel Kconfig file or mount/enable cgroup controller in your system)
LXC: Checking if device /sys/fs/fuse/connections exists : PASS
This depends on whether it’s refreshing the cache when it does this. If it is, a slow repo can cause delays, for example, or connection issues.
Does DNFDragora share the DNF cache? DNF runs a timer now that updates the cache periodically so that when you run a command, the cache is likely to be up to date already.
DNF appears to have per user cache, so it also depends on whether DNF runs with sudo or not.
This should require the VM to be online to work properly.
Actually I’ve recently encountered similar issues while updating the modular repo metadata.
It might be a transient problem with the mirroring service.
This could be indeed an issue. When i start dnf i do it with sudo. When i open DNFDragora it just ask me for the Sudo password when i apply the changes. I open dnf dragora dialogue with the icon in the status bar.
I tried to start dnfdragora-updater in terminal. As my user it works. as sudo i get errors.
Is there a group wher i can join that DNFDragora is not asking me the Sudo PW to add updates?
I do believe that popularity of Fedora causes also a bit traffic jams . And living in Brasil also not helps to have high speed internet.
If there is a way to share the dnf cache with DNFDragora i will do it.
That’s why I used dnf when i got the popup Notification, to save a bit time. No problem for me to work in terminal.
Just thinking that new user feel uncomfortable to do so (using the terminal).
And remember, when your cache is being built, Fedora downloads about 50 Megabytes+ of repo metadata. If you are on a slow (mobile) connection or connecting to a slow mirror, this may take a while.
I shouldn’t. There is 171 mirrors worldwide, so the load should be spread across many servers. However, Brasil seems to be underrepresented. There is a single mirror, by UFPR, for the entire country. (I am not counting Globo as mirror if their bandwidth is indeed 10 Mbit)
what you could do is comparing the actual download speed in both machines (baremetal and libvirt guest).
run sudo dnf clean all, then sudo dnf update and see how long it takes to refresh all repos.
(given the repos are the same, otherwise, temporarily disable some to match the repolist on both machines).