When a VirtualBox Lab Hangs at Boot — Rocky 10.2 and PXE Setup Notes

AI_Manager

There were issues that needed to be resolved before installing NetBox, Zabbix, and AWX. New VMs got stuck during kernel boot, UEFI network boot paths failed to open, and PXE installation images failed to fit into memory. This article outlines issues encountered specifically in a VirtualBox lab environment, rather than errors within the services themselves.

The environment consists of Windows 11 Pro, an Intel Core Ultra 9 185H, approximately 31.4 GiB of available memory, VirtualBox 7.2.18, and Rocky Linux 10.2. The resolution conditions below are based on observations from this specific PC and should not be generalized to all VirtualBox and UEFI environments.

1. Kernel boot hangs on multiple vCPUs

Symptoms and Observations

Some VMs stopped making progress during boot after increasing the number of CPUs. The serial console left an EVM extended attributes initialization message on the final screen. However, the presence of EVM in the last output does not automatically mean that EVM or SELinux was the root cause.

We compared variations by changing the paravirtualization provider and virtual CPU conditions. With the Intel Core i7-6700K CPU profile, booting and rebooting were verified with 2 vCPUs on gateway and 4 vCPUs on ops01. On the other hand, the new BIOS PXE target stalled on the 2 vCPU installation kernel even with the same profile, requiring a reduction to 1 vCPU to proceed.

Applied Measures

# Apply only after the VM has shut down cleanly.
$VBox = 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe'
& $VBox modifyvm fml-ops-01 --cpu-profile 'Intel Core i7-6700K' --cpus 4
& $VBox modifyvm fml-dev-app-01 --cpus 1

This profile represents a compatibility condition for virtual CPUs; it does not change the actual host CPU to an i7-6700K. Because guest asset collection results display the virtual CPU model, this was kept distinct from the portfolio’s physical PC specifications.

Hyper-V, VBS, and Windows Memory Integrity were not disabled. Rather than concluding that turning off these features is a universal fix, we recorded the specific conditions that worked for each VM. The final vCPU count took into account not only successful booting, but also the resources required for service operations.

2. UEFI firmware exceptions and network boot paths

Symptoms and Observations

CpuDxe exceptions occurred with certain graphics and firmware combinations on new EFI VMs. While the EFI64, VMSVGA, and 16 MiB VRAM combination avoided those exceptions, the expected native PXE boot menu did not appear.

Additionally, the existing Extension Pack was version 7.1.10 while the main VirtualBox software was 7.2.18, confirming a version mismatch error (VERR_VERSION_MISMATCH). No actions were taken to install Extension Packs or agree to licenses.

Official iPXE EFI and legacy EFI boot paths were also tested, but on this PC they did not progress from initialization to installation. We did not extrapolate this to conclude that ‘UEFI PXE simply does not work.’

Path used for actual installation

With BIOS + official ipxe-legacy.iso, the process progressed from DHCP to internal HTTP kernel/initrd and through to Rocky Kickstart installation. The target used only a single internal network NIC, and OS packages were fetched from the provision server.

& $VBox modifyvm fml-prod-app-01 --firmware bios --cpus 1 --memory 4096
& $VBox modifyvm fml-prod-app-01 --boot1 disk --boot2 dvd --boot3 net --boot4 none

The evidence of PXE installation in this lab is limited to this BIOS path. This does not mean that UEFI, Secure Boot, NIC Option ROM, and RAID configurations on physical servers were validated. When applying to physical equipment, the supported paths for that specific hardware must be tested separately.

3. Installation image download failure on 2GiB memory

Symptoms and Causes

After receiving the PXE kernel/initrd, No space left on device occurred during the step to download the roughly 750 MiB install.img. This was not a shortage of space on the virtual disk targeted for installation, but rather an insufficient tmpfs space issue in the initial installation environment.

Actions and Verification

The installation target RAM was increased from 2 GiB to 4 GiB. The installation image and 309 RPMs were successfully downloaded from the same internal storage, completing the Rocky installation. After installation, we verified SSH connectivity, the operating system version, the management IP, SELinux Enforcing status, and the installation complete flag, performed a clean shutdown, and then reduced the RAM back to 1 GiB.

& $VBox showvminfo fml-prod-app-01 --machinereadable
# After shutting down the guest cleanly
& $VBox modifyvm fml-prod-app-01 --memory 1024
& $VBox startvm fml-prod-app-01 --type headless

The memory required during installation differs from the memory required to run services post-installation. Simultaneously allocating 4 GiB for installation across multiple targets reduces the headroom available to Windows and central services, so target installations were executed sequentially.

4. Installation screen appears to hang for a long time

In 1 vCPU labs, configuring kernel-core, generating initramfs, and applying SELinux policies took a significant amount of time. The VM power was not immediately turned off just because the final screen stopped changing. Active installations and halted boots were distinguished by checking progress timestamps in serial logs, installation process states, and disk activity.

Power was forcefully cut only when re-testing conditions where a new blank disk target had stalled during kernel boot prior to the start of installation. VMs undergoing package installation or filesystem updates were never interrupted in this manner.

5. Values to check immediately after VM cloning

The serial console left behind the public SSH host key and fingerprint generated during installation. Management automation checks this value to register it in known_hosts, and did not turn off StrictHostKeyChecking to resolve authentication failures.

6. Why this record was separated from the service deployment post

Virtual CPUs, firmware, and installation RAM are issues of the VM-based environment. On the other hand, NetBox health checks, Redis connection timeouts, AWX permission propagation, and API token/repository paths are issues of service deployment and operations. Separating these two categories allows you to quickly determine in the next practice whether you should ‘fix the VM first’ or ‘check the service configuration’.

For official boot files and operating methods, refer to iPXE download, iPXE boot files, and iPXE chainloading. The success and failure conditions in this text are actual practice records from this PC.

Further Reading and Configuration Materials

Original Portfolio · Online/Offline Network Deployment Guide · Failure Scenarios and Verification Records · VirtualBox Configuration Troubleshooting Records

Practice Setup and Automation Source ZIP · ZIP SHA-256

The public ZIP contains configuration templates and automation sources. It does not include the OS, RPMs, container images, or credentials. Configure with your own address, public CA, authorized SSH keys, and secret storage before applying.