Install VirtualBox on Fedora 45 / 44 with Secure Boot

Oracle’s VirtualBox repository has no Fedora 45 tree, so the usual install VirtualBox on Fedora recipe stops at the first dnf install. Pinning the Fedora 44 tree does not rescue it either, because that build needs a library Fedora 45 no longer ships. RPM Fusion’s akmod build is the path that works on Fedora 45, Oracle’s repo still works on Fedora 44, and on both of them a machine with Secure Boot on refuses to load the kernel module until you sign it and enroll the key in MokManager.

Original content from computingforgeeks.com - post 17431

This guide covers the RPM Fusion install on Fedora 45, Oracle’s RPM on Fedora 44 and the Oracle .run installer for anyone who needs Oracle’s newest build on 45. It also walks through the module signing each path needs, the Extension Pack and a first VM created with VBoxManage. Every command below was run in October 2026 on Fedora 45 and Fedora 44 VMs with Secure Boot on, using VirtualBox 7.2.18 from RPM Fusion and 7.2.20 from Oracle.

Pick the install path for your release

Your choice of source decides two things you’ll live with afterwards: who rebuilds the kernel module when Fedora ships a new kernel, and which key signs it. RPM Fusion hands both jobs to akmods, which rebuilds automatically, while Oracle’s packages build with /sbin/vboxconfig and expect you to manage a signing key yourself. We ran all four combinations on lab VMs, and this is what each one did:

Release	Source	Version tested	Module build	Signing key
Fedora 45	RPM Fusion free	7.2.18	akmods, on install and on kernel updates	/etc/pki/akmods/certs/public_key.der
Fedora 45	Oracle .run installer	7.2.20	/sbin/vboxconfig	/var/lib/shim-signed/mok/MOK.der
Fedora 45	Oracle RPM repo	None: the 45 tree returns 404 and the 44 build needs libvpx.so.9	n/a	n/a
Fedora 44	Oracle RPM repo	7.2.20	/sbin/vboxconfig	/var/lib/shim-signed/mok/MOK.der

On Fedora 45, use RPM Fusion unless you need a fix that only exists in Oracle’s newest point release, because the .run installer sits outside dnf and you update it by hand. On Fedora 44 both sources work, and Oracle’s repo gets point releases a little sooner. Whichever you pick, don’t mix them: the RPM Fusion and Oracle packages install the same binaries and kernel modules.

Prerequisites

Most failures we hit were in the kernel module, so most of the list is about the kernel and the console you will need at the next boot:

• Fedora 45 or Fedora 44 on x86_64 with VT-x or AMD-V enabled in firmware
• A user with sudo rights
• A fully updated system, rebooted into the newest kernel (the post-install steps for Fedora 45 cover that and RPM Fusion)
• Keyboard and screen access at boot, because MokManager runs before Linux starts
• Free disk for VirtualBox, the compiler it pulls in and your guests under ~/VirtualBox VMs

Update and reboot before you install anything. The module is built against the running kernel, and kernel-devel-$(uname -r) only matches a package in the repo when you’re on the newest kernel. A box that installed a kernel update but never rebooted fails the build or the install. That mismatch is what sends people looking for a kernel-devel package that no longer exists in the repo:

sudo dnf -y upgrade --refresh
sudo systemctl reboot

After the reboot, check whether Secure Boot is on. If it reports enabled, the signing steps later in this guide are mandatory, not optional:

uname -r
mokutil --sb-state

Our Fedora 45 lab VM booted with Secure Boot on and the current kernel:

7.2.11-300.fc45.x86_64
SecureBoot enabled

With Secure Boot disabled in firmware, the module loads unsigned and you can skip the MOK steps, but you give up the protection Secure Boot gives the rest of the boot chain to save one reboot.

Why Oracle’s repo fails on Fedora 45

Oracle’s virtualbox.repo builds its URL from $releasever, and there is no fedora/45 directory on download.virtualbox.org. If you add the repo anyway, dnf retries the 404 four times, skips the repo and reports the package as not found. Nothing in that output says the tree is missing for your release, so it reads like a typo in the package name:

>>> Status code: 404 for http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml (IP: 23.213.50.94) - http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml
>>> Status code: 404 for http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml (IP: 23.213.50.94) - http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml
>>> Status code: 404 for http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml (IP: 23.213.50.94) - http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml
>>> Status code: 404 for http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml (IP: 23.213.50.94) - http://download.virtualbox.org/virtualbox/rpm/fedora/45/x86_64/repodata/repomd.xml
>>> Usable URL not found
Repositories loaded.
Failed to resolve the transaction:
No match for argument: VirtualBox-7.2
You can try to add to command line:
  --skip-unavailable to skip unavailable packages

Pointing the repo at the fedora/44 tree gets further and then stops on a dependency, because every 7.2 build in that tree is the same fedora40 RPM linked against libvpx 1.15. Fedora 44 ships that library as libvpx.so.9, Fedora 45 moved to libvpx 1.17 with the libvpx.so.12 soname, and no Fedora 45 package provides the old one:

Problem: conflicting requests
  - nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.0_170228_fedora40-1.x86_64 from virtualbox
  - nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.10_174163_fedora40-1.x86_64 from virtualbox
  - nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.12_174389_fedora40-1.x86_64 from virtualbox
  - nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.14_174565_fedora40-1.x86_64 from virtualbox
  - nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.16_174877_fedora40-1.x86_64 from virtualbox
  - nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.18_175117_fedora40-1.x86_64 from virtualbox
  - nothing provides libvpx.so.9()(64bit) needed by VirtualBox-7.2-7.2.20_175154_fedora40-1.x86_64 from virtualbox

Forcing the install with --nodeps or a symlinked library is how you end up with a VirtualBox that breaks on the next dnf transaction. We checked every provider of libvpx.so* in the Fedora 45 repos and found only libvpx-1.17.0-1.fc45, so there is no compat package to install either. Remove the repo file if you added it, and take the RPM Fusion route below, or the .run installer if you need Oracle’s build:

sudo rm -f /etc/yum.repos.d/virtualbox.repo

If Oracle publishes a fedora/45 tree later, re-check with dnf install before you rely on it: the 43 and 44 trees both serve the same fedora40 build, and a 45 tree with that build would still want libvpx.so.9.

Install VirtualBox from RPM Fusion on Fedora 45

VirtualBox lives in RPM Fusion’s free repository as an akmod, a source package that akmods compiles into a kernel module on your machine. Because the module is built on your machine, it is always built for the exact kernel you run, which is what lets RPM Fusion support a new Fedora release without waiting for anyone upstream. Enable RPM Fusion free with its release package:

sudo dnf -y install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

Check which build the repo offers before you commit to it. RPM Fusion usually trails Oracle by a point release or two, so this is where you find out whether the fix you are after has landed yet. If it has not, the .run section below is the way around it:

dnf repoquery --info VirtualBox akmod-VirtualBox | grep -E "^(Name|Version|Release|Repository)"

Both packages came from rpmfusion-free at the same version:

Name           : VirtualBox
Version        : 7.2.18
Release        : 1.fc45
Repository     : rpmfusion-free
Name           : akmod-VirtualBox
Version        : 7.2.18
Release        : 1.fc45
Repository     : rpmfusion-free

Install VirtualBox together with the headers for the running kernel. The VirtualBox package pulls in akmod-VirtualBox, akmods and the compiler, and the build runs as part of the transaction, which took just under two minutes on a 4 vCPU VM:

sudo dnf -y install VirtualBox kernel-devel-$(uname -r)

List what landed. The kmod-VirtualBox package carries the kernel version in its name, which is akmods telling you which kernel this build is for. That naming matters later: after a kernel update you should see a second kmod-VirtualBox package for the new kernel, and if you don’t, the rebuild never ran and the module will be missing at the next boot:

rpm -qa | grep -iE "virtualbox|akmod" | sort

Six packages, with the module built for 7.2.11-300.fc45:

akmods-0.6.2-14.fc45.noarch
akmod-VirtualBox-7.2.18-1.fc45.x86_64
kmod-VirtualBox-7.2.11-300.fc45.x86_64-7.2.18-1.fc45.x86_64
VirtualBox-7.2.18-1.fc45.x86_64
VirtualBox-kmodsrc-7.2.18-1.fc45.noarch
VirtualBox-server-7.2.18-1.fc45.x86_64

The install builds the module but doesn’t load it, because vboxdrv.service is a one-shot unit that runs at boot. On a machine with Secure Boot off, run sudo systemctl start vboxdrv (or reboot) and we’re done with the module. With Secure Boot on, the module is on disk but the kernel will not load it yet, so the next section is not optional.

Sign the akmods module for Secure Boot

On the Fedora 45 VM the first build shipped unsigned. /etc/pki/akmods/certs was empty after the install and the [email protected] unit that would have created a key was disabled, so akmods had nothing to sign with. akmods’ own README says the key is created on the first akmods.service run, but that path goes through this disabled unit. Loading the module then fails with the error most people search for:

modprobe: ERROR: could not insert 'vboxdrv': Key was rejected by service

Generate the akmods key pair, then rebuild so the module gets signed with it. kmodgenca -a is the tool RPM Fusion’s own Secure Boot instructions use. --force --rebuild replaces the unsigned build instead of skipping a kernel that already has one. Run them in this order, because a rebuild before the key exists produces another unsigned module and the import step then fails on a missing public_key.der, which is what happened on the first attempt in the lab:

sudo kmodgenca -a
sudo akmods --force --rebuild
modinfo vboxdrv | grep -E "^(signer|sig_key|sig_hashalgo)"

These are the key steps from our lab VM, from the rejected load to a module whose signer field names the new key. The key is named after the hostname plus a timestamp, so yours will differ:

Signed is not the same as trusted. The kernel still rejects the module until the public key is in the MOK list, and only MokManager can add it there, at the next boot. Queue the request and set a one-time password that you will type in MokManager:

sudo mokutil --import /etc/pki/akmods/certs/public_key.der
sudo mokutil --list-new | grep -E "Subject:|SHA1 Fingerprint"

Note the SHA1 fingerprint. MokManager shows the same bytes at boot, and comparing them is the only check you get that the key you are about to trust is the one you generated, not something another process queued:

SHA1 Fingerprint: 46:ec:00:8c:33:a9:eb:59:33:0c:0c:61:ba:c9:30:98:4a:ee:a3:e4
        Subject: O=f45-vbox, OU=f45-vbox/emailAddress=akmods@f45-vbox, L=None, ST=None, C=US, CN=f45-vbox_1792495343_f4f8f176

Reboot and stay at the keyboard. MokManager shows a blue “Press any key to perform MOK management” screen for about 10 seconds, and if nobody presses a key it boots on and the pending request is lost, which means another mokutil --import and another reboot. The enrollment itself takes five moves:

1. Press any key, then pick Enroll MOK.
2. Pick View key 0 and compare the fingerprint with the one mokutil printed, then press a key to go back.
3. Pick Continue, then Yes at “Enroll the key(s)?”.
4. Type the password you set with mokutil. Nothing echoes on screen, and the keyboard layout is US QWERTY whatever your OS uses.
5. Pick Reboot.

Step 2 on our lab VM looked like this. The fingerprint block matches the mokutil --list-new output above byte for byte:

Back in Fedora, confirm the key is enrolled and that the service loaded all three modules on its own:

sudo mokutil --test-key /etc/pki/akmods/certs/public_key.der
systemctl is-active vboxdrv
lsmod | grep -E "^vbox" | awk '{print $1}'
VBoxManage --version

All three modules loaded on their own, and the version string carries RPM Fusion’s suffix:

/etc/pki/akmods/certs/public_key.der is already enrolled
active
vboxnetadp
vboxnetflt
vboxdrv
7.2.18_RPMFUSIONr175117

You enroll this key once per machine. Every later akmods build, including the ones after kernel updates, is signed with the same key pair, so the MokManager visit doesn’t repeat. The same mechanism signs any other akmod you install, such as the NVIDIA driver, and the Secure Boot and MOK guide for Fedora covers listing, testing and deleting enrolled keys in more depth.

Install Oracle’s VirtualBox on Fedora 44

Oracle’s repo still serves Fedora 44, and the 44 tree is the same fedora40 build that Fedora 44’s libvpx satisfies. Add the repo file and install the 7.2 package with the matching headers. The package name carries the series (VirtualBox-7.2) so that a future series lands as a separate package you opt into, rather than as a surprise during a routine upgrade:

sudo curl -fsSL https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo -o /etc/yum.repos.d/virtualbox.repo
sudo dnf -y install VirtualBox-7.2 kernel-devel-$(uname -r)

With -y, dnf imports Oracle’s signing key without asking. When it finishes, check the package name, because it shows which build you actually got and explains the libvpx problem on Fedora 45:

rpm -q VirtualBox-7.2

Oracle labels it for Fedora 40. The repo serves one build per series across several Fedora releases, so it links against the libraries Fedora 40 shipped, which works only while the release you run still carries the same sonames:

VirtualBox-7.2-7.2.20_175154_fedora40-1.x86_64

With Secure Boot on, the install completes with no module loaded at all, and dnf prints nothing that says so. Run the setup script by hand, because it is the only place that reports why:

sudo /sbin/vboxconfig

Compiling works, then the signing step fails because Fedora has no tool that creates the key Oracle’s script looks for:

vboxdrv.sh: Building VirtualBox kernel modules.
vboxdrv.sh: Signing VirtualBox kernel modules.
vboxdrv.sh: failed:

System is running in Secure Boot mode, however your distribution
does not provide tools for automatic generation of keys needed for
modules signing. Please consider to generate and enroll them manually:

    sudo mkdir -m 0700 -p /var/lib/shim-signed/mok
    sudo openssl req -nodes -new -x509 -newkey rsa:2048 -outform DER -addext "extendedKeyUsage=codeSigning" -keyout /var/lib/shim-signed/mok/MOK.priv -out /var/lib/shim-signed/mok/MOK.der
    sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
    sudo reboot

Follow Oracle’s recipe, with two additions to the openssl line. Without -subj it stops to ask for every certificate field, and without -days the certificate is only valid for 30 days, which gives the key a name you’ll recognize in MokManager and a lifetime that outlasts the release:

sudo mkdir -m 0700 -p /var/lib/shim-signed/mok
sudo openssl req -nodes -new -x509 -newkey rsa:2048 -outform DER -addext "extendedKeyUsage=codeSigning" -subj "/CN=$(hostname) VirtualBox module signing/" -days 3650 -keyout /var/lib/shim-signed/mok/MOK.priv -out /var/lib/shim-signed/mok/MOK.der
sudo mokutil --import /var/lib/shim-signed/mok/MOK.der
sudo mokutil --list-new | grep -E "Subject:|SHA1 Fingerprint"

The pending key carries the name you gave it, and the fingerprint is what MokManager will show you at boot:

SHA1 Fingerprint: 24:ff:69:31:17:7d:84:8b:51:5b:b0:38:35:c7:56:03:be:41:f0:7f
        Subject: CN=f44-01 VirtualBox module signing

Reboot to reach MokManager:

sudo systemctl reboot

We walked through MokManager exactly as in the RPM Fusion section, then reran the setup script. It finds the key in /var/lib/shim-signed/mok on its own:

sudo /sbin/vboxconfig
modinfo -F signer vboxdrv
VBoxManage --version

This time the signing step succeeds and the signer is the certificate you just enrolled:

vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
vboxdrv.sh: Signing VirtualBox kernel modules.
f44-01 VirtualBox module signing
7.2.20r175154

Keep MOK.priv where it is. Oracle’s script signs every rebuild with it, and if you delete it the next kernel update brings back the Secure Boot failure along with a fresh MokManager visit for a new key. Plan the move before you upgrade Fedora 44 to 45, too: the repo file switches to the 45 tree that returns 404, and the installed build still wants libvpx.so.9, so remove Oracle’s package and repo first and install from RPM Fusion once the upgrade is done. Treat the key like any other private key: anyone who can read it can sign a kernel module your firmware will accept, so leave the directory at mode 0700 owned by root, as the mkdir above created it.

Run Oracle’s latest build on Fedora 45

The generic Linux .run installer does not depend on Fedora’s libvpx, so it installs Oracle’s current release on Fedora 45 where the RPM can’t. Read the current version from Oracle’s LATEST-STABLE.TXT, download the installer and check it against Oracle’s published SHA256 list:

VER=$(curl -fsSL https://download.virtualbox.org/virtualbox/LATEST-STABLE.TXT)
RUN=$(curl -fsSL https://download.virtualbox.org/virtualbox/${VER}/SHA256SUMS | awk '/Linux_amd64.run/{print $2}' | tr -d '*')
curl -fsSLO https://download.virtualbox.org/virtualbox/${VER}/${RUN}
curl -fsSL https://download.virtualbox.org/virtualbox/${VER}/SHA256SUMS | grep "${RUN}"
sha256sum "${RUN}"

The two hashes must be identical before you run anything as root. The installer is a self-extracting shell script that writes to /opt and loads kernel modules, so a corrupted or tampered download is not something to find out about afterwards:

14676e58ae57c543b9f3883fed8d266d9ec595083202c2a3acfc3cf350a21086 *VirtualBox-7.2.20-175154-Linux_amd64.run
14676e58ae57c543b9f3883fed8d266d9ec595083202c2a3acfc3cf350a21086  VirtualBox-7.2.20-175154-Linux_amd64.run

Install the build tools the installer needs for the modules, then run it. Unlike the RPMs, the .run file does not pull in a compiler or headers on its own, so skipping the first line leaves you with the userland tools and no module:

sudo dnf -y install kernel-devel-$(uname -r) gcc make perl bzip2
sudo sh "${RUN}"

It unpacks to /opt/VirtualBox in about 40 seconds and prints the same Secure Boot message that /sbin/vboxconfig printed on Fedora 44, followed by “VirtualBox has been installed successfully.”, so don’t take that last line as a working module. It clears the same way: create the key in /var/lib/shim-signed/mok with the openssl command from the previous section, import it, enroll it in MokManager and run sudo /sbin/vboxconfig again. On the Fedora 45 VM that produced a signed, loaded module and 7.2.20r175154, and a headless Alpine guest started normally. We only tested this install headless: on that server VM, ldd reported unresolved libraries for the GUI components, so on a desktop check VirtualBox starts before you rely on the Manager.

What you trade for the newer build is maintenance. dnf does not know this install exists, so dnf upgrade never updates it. Moving to a new release means downloading the next .run and running it over the old one. Pick this only if you need something Oracle has released that RPM Fusion hasn’t packaged yet.

Add your user to vboxusers

Every install path creates a vboxusers group, and only its members can pass USB devices through to guests. Add yourself:

sudo usermod -aG vboxusers $USER

Group membership is read at login, so id -nG in the same terminal still won’t list it. Log out and back in, or reboot, then check:

id -nG

In a fresh session the group is at the end of the list:

josphat adm wheel systemd-journal vboxusers

Install the Extension Pack

The Extension Pack must match the installed VirtualBox version exactly, and RPM Fusion’s version string carries a suffix, so strip it before building the download URL. RPM Fusion’s 7.2.18_RPMFUSIONr175117 is not a directory on Oracle’s download server, so the two cut calls reduce it to the plain 7.2.18, and on Oracle’s own builds they turn 7.2.20r175154 into 7.2.20. Oracle’s SHA256SUMS file covers the pack as well:

VER=$(VBoxManage --version | cut -d_ -f1 | cut -dr -f1)
curl -fsSLO https://download.virtualbox.org/virtualbox/${VER}/Oracle_VirtualBox_Extension_Pack-${VER}.vbox-extpack
curl -fsSL https://download.virtualbox.org/virtualbox/${VER}/SHA256SUMS | grep "Extension_Pack-${VER}.vbox-extpack"
sha256sum Oracle_VirtualBox_Extension_Pack-${VER}.vbox-extpack

Oracle licenses the pack under its PUEL rather than the GPL, which covers personal and educational use, so read the license before you put it on a work machine. Install it as root and answer y at the license prompt:

sudo VBoxManage extpack install --replace Oracle_VirtualBox_Extension_Pack-${VER}.vbox-extpack

After you accept, VBoxManage prints a license hash for unattended installs. It was the same for 7.2.18 and 7.2.20, and it changes whenever Oracle changes the license text:

License accepted. For batch installation add
--accept-license=eb31505e56e9b4d0fbca139104da41ac6f6b98f8e78968bdf01b1f3da3c4f9ae
to the VBoxManage command line.
Successfully installed "Oracle VirtualBox Extension Pack".

List the pack to confirm it’s usable, and read what it says it contains:

VBoxManage list extpacks

Both the 7.2.18 pack on Fedora 45 and the 7.2.20 pack on Fedora 44 described themselves the same way:

Extension Packs: 1
Pack no. 0:   Oracle VirtualBox Extension Pack
Version:        7.2.18
Revision:       175117
Edition:
Description:    Oracle Cloud Infrastructure integration, PXE ROM.
VRDE Module:
Crypto Module:
Usable:         true
Why unusable:   

That description is much shorter than the feature list older guides repeat. USB 2.0 and 3.0 controllers moved into the open-source base package in VirtualBox 7.0, so a plain install already gives guests xHCI, and on these builds the pack reported no VRDE or crypto module. If all you wanted was USB 3 in a guest, you can skip the pack and its license entirely.

Create a VM from the command line

A VM built with VBoxManage is the quickest proof that the modules, the group and hardware virtualization all work. It is also what you’d script on a host without a desktop. This one boots the 66 MB Alpine virt ISO from a SATA optical drive with an 8 GB disk next to it, and the ISO_NAME and curl lines fetch whichever virt ISO is current on Alpine’s mirror. The VMSVGA graphics controller is VirtualBox’s own default for Linux guests, and the IntelAhci SATA controller is the one every Linux installer recognizes without extra drivers, so the same commands work for a Fedora or Ubuntu ISO with only the memory and disk size changed:

VM=alpine01
ISO_NAME=$(curl -fsSL https://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86_64/latest-releases.yaml | awk '/file: alpine-virt-.*x86_64.iso/{print $2}')
curl -fsSL -o "$HOME/$ISO_NAME" https://dl-cdn.alpinelinux.org/alpine/latest-stable/releases/x86_64/$ISO_NAME
ISO=$HOME/$ISO_NAME
VBoxManage createvm --name "$VM" --ostype Linux_64 --register
VBoxManage modifyvm "$VM" --memory 1024 --cpus 1 --nic1 nat --graphicscontroller vmsvga
VBoxManage createmedium disk --filename "$HOME/VirtualBox VMs/$VM/$VM.vdi" --size 8192
VBoxManage storagectl "$VM" --name SATA --add sata --controller IntelAhci
VBoxManage storageattach "$VM" --storagectl SATA --port 0 --device 0 --type hdd --medium "$HOME/VirtualBox VMs/$VM/$VM.vdi"
VBoxManage storageattach "$VM" --storagectl SATA --port 1 --device 0 --type dvddrive --medium "$ISO"
VBoxManage startvm "$VM" --type headless

Check the state from the host, and grab the guest’s screen without opening a window. On a headless host that screenshot is often the fastest way to see whether a guest hung in its bootloader or reached a login prompt:

VBoxManage showvminfo alpine01 --machinereadable | grep -E "^(VMState|memory|cpus|nic1|ostype)="
VBoxManage controlvm alpine01 screenshotpng /tmp/alpine01.png

The VM reports running with the resources you gave it:

ostype="Other Linux (64-bit)"
memory=1024
cpus=1
VMState="running"
nic1="nat"

A second screenshot a little later caught the guest at its login prompt, inside a Fedora 45 VM that was itself running on Proxmox with nested virtualization:

If startvm fails with a VT-x or AMD-V error instead, hardware virtualization is off in firmware, or another hypervisor holds it. The KVM guide for Fedora covers checking the CPU flags.

Open the VirtualBox Manager

On a desktop, start VirtualBox from the application grid or run VirtualBox in a terminal. VMs you created with VBoxManage show up straight away because both tools read the same registry in ~/.config/VirtualBox. The details pane is also a quick way to check that the guest got hardware acceleration, which this one did (Nested Paging and KVM paravirtualization):

The Fedora CoreOS on VirtualBox guide uses this same install to boot an Ignition-provisioned VM if you want a second guest to try.

Keep the module working after kernel updates

Fedora ships kernel updates throughout a release’s life, and each new kernel needs its own build of the module. RPM Fusion handles that through akmods, which hooks into kernel installation and also runs at boot:

systemctl is-enabled akmods.service
ls /usr/lib/kernel/install.d/ | grep -i akmod

Both pieces were in place on the lab VM. When dnf upgrade installs a kernel, the hook queues an akmods build for it in the background, and a boot into a kernel that still has no module gets a build from akmods.service before vboxdrv.service runs:

enabled
95-akmodsposttrans.install

Each build needs headers for the new kernel, so keep kernel-devel installed and let dnf upgrade update it alongside the kernel. If systemctl status vboxdrv shows inactive after a kernel update, the build did not run. Run sudo akmods --force followed by sudo systemctl restart vboxdrv on the RPM Fusion install or sudo /sbin/vboxconfig on Oracle’s, and if a new kernel will not boot at all, boot the previous kernel and rebuild from there. Fedora keeps three kernels installed by default, so there is always an older one with a working module to fall back on while you sort out the new one.

Uninstall VirtualBox and clean up the key

Power off and delete your VMs first if you don’t want them, because removing the packages leaves ~/VirtualBox VMs and the disks in it untouched. Then remove the Extension Pack and the packages for your install path:

VBoxManage controlvm alpine01 poweroff
VBoxManage unregistervm alpine01 --delete
sudo VBoxManage extpack uninstall "Oracle VirtualBox Extension Pack"

For the RPM Fusion install, remove the akmod and every kmod built from it along with VirtualBox, because each kernel you ran got its own kmod-VirtualBox package and a plain dnf remove VirtualBox leaves them behind. On the lab VM this took the whole stack with it, 215 packages including akmods and the Qt and X11 libraries the install had pulled in:

sudo dnf -y remove VirtualBox akmod-VirtualBox "kmod-VirtualBox*"

Oracle’s RPM goes with dnf, but the repo file stays in /etc/yum.repos.d until you delete it:

sudo dnf -y remove VirtualBox-7.2
sudo rm -f /etc/yum.repos.d/virtualbox.repo

The .run install isn’t known to dnf, so it removes itself with the script it put in /opt/VirtualBox:

sudo /opt/VirtualBox/uninstall.sh

None of the three removes the signing key from firmware. Leaving it enrolled is harmless on a machine you control, since only modules signed with your private key pass it. To remove it, run sudo mokutil --delete on the same .der file, reboot and confirm in MokManager, then delete /var/lib/shim-signed/mok or /etc/pki/akmods so no private key is left on disk. Do that for the akmods key only if no other akmod is installed: the NVIDIA driver and every other akmod are signed with the same key, and under Secure Boot they stop loading the moment it’s gone.