I was trying to install Ubuntu on a Dell PowerEdge R610 and assumed iDRAC6 virtual media would be the easy path. Mount the ISO through the management interface, boot from the virtual CD-ROM, done. Instead I spent an entire afternoon discovering that iDRAC6 virtual media is fundamentally broken on every Mac made in the last seven years. This is the story of why, what I tried, and why PXE boot was the only thing that actually worked.
The R610 was released in 2009 and its iDRAC6 management controller was designed for Java 6. That detail matters more than you might think, because the virtual media feature depends on native compiled libraries that are permanently locked to that era's hardware and operating system assumptions. If you want the short version of this article: iDRAC6 virtual media cannot run on Apple Silicon, and it cannot run on Intel Macs running macOS Catalina or later. PXE boot is the answer. The rest of this article explains exactly why.
The Architecture Problem in One Paragraph
iDRAC6 virtual media works by sending a CD-ROM data stream from your computer to the iDRAC over the network. To do this, the Java applet (avctKVM.jar) loads native dynamic libraries from companion JAR files (avctKVMIOMac64.jar and avctVMMac64.jar). Inside those JARs are .dylib and .jnilib files compiled for a Mac that no longer exists: 32-bit Intel, running an OS that still loaded 32-bit code. Every modern Mac breaks one of those assumptions.
Why Apple Silicon Fails: ARM64 vs x86_64
On an Apple Silicon Mac (M1, M2, M3, M4), the Java runtime is ARM64. The native libraries inside the iDRAC6 JAR files are compiled for Intel x86_64. A Java Virtual Machine can only load native libraries compiled for its own CPU architecture; it cannot translate between architectures at the library-loading level.
Rosetta 2, Apple's translation layer, can run standalone Intel applications. But it cannot dynamically inject an Intel-compiled .dylib into an ARM64 Java process that is already running. When the KVM console launches and you click the Virtual Media button, Java tries to call System.loadLibrary, finds an x86_64 binary, and crashes with the error:
The Virtual Media native library cannot be loaded
The KVM video console works fine because it is pure Java. Virtual media does not because it depends on native code.
Why Intel Macs Fail: The 32-Bit Drop
Switching to an Intel Mac does not help, and this is the part that took me a while to figure out. The iDRAC6 firmware does not serve 64-bit x86_64 native libraries for the virtual media engine. It serves 32-bit i386 binaries, because that is what Mac OS X used when the R610 was designed.
macOS Catalina (10.15), released in October 2019, removed all support for 32-bit applications. Every macOS version since then, on every Intel Mac, refuses to load 32-bit code at the operating system level. So when Java on an Intel Mac tries to load the iDRAC6 virtual media library, macOS blocks it before the architecture question even comes up.
The result is identical to the Apple Silicon failure: the KVM video window opens and shows you the server's console, but clicking Virtual Media crashes with the same native library error. I confirmed this on an Intel MacBook Pro running a current macOS version with a matching Intel OpenJDK. The video feed was perfect. Virtual media was dead.
What I Tried (And Why None of It Worked)
Attempt 1: Download the missing JAR files manually
The first theory was that the default avctKVM.jar pull was missing its companion library JARs. I wrote a script to fetch avctKVMIOMac64.jar and avctVMMac64.jar directly from the iDRAC, unzip them, and pass -Djava.library.path=./idrac_libs to Java so it would find the extracted .dylib and .jnilib files.
This hit an immediate SSL problem. The iDRAC6 web server uses ancient Diffie-Hellman keys that modern Python and OpenSSL reject:
ssl.SSLError: [SSL: DH_KEY_TOO_SMALL] dh key too small
The fix was to lower the SSL security level in the download script:
ctx = ssl._create_unverified_context()
ctx.set_ciphers('DEFAULT@SECLEVEL=1')
That got the files downloaded and extracted. Java still could not load them, because the architecture mismatch was still there. On Apple Silicon the JVM is ARM64 and the libraries are x86_64. On Intel the libraries are 32-bit i386 and macOS Catalina+ blocks 32-bit code. Downloading the libraries correctly does not change what they are compiled for.
Attempt 2: Run an Intel Java via Rosetta 2
On the Apple Silicon Mac, I installed an x86_64 build of OpenJDK and ran the script with arch -x86_64 to force the Intel Java runtime:
arch -x86_64 /Library/Java/JavaVirtualMachines/temurin-11.jdk/Contents/Home/bin/java \
-Djava.library.path=./idrac_libs \
-cp avctKVM.jar com.avocent.idrac.kvm.Main ...
This got further. The JVM loaded, the KVM console connected, and the video window opened. But when I clicked Virtual Media, the same native library error appeared. The reason: the iDRAC6 firmware was serving 32-bit i386 libraries, not 64-bit x86_64 ones. Even an Intel JVM under Rosetta 2 cannot load 32-bit libraries on a version of macOS that has dropped 32-bit support entirely.
Attempt 3: An Intel Mac with Intel Java
I moved to an actual Intel MacBook Pro with a native Intel OpenJDK to eliminate Rosetta 2 from the equation. Same result. The KVM video console worked perfectly, but Virtual Media crashed with the identical native library error. The 32-bit i386 binaries were being blocked by the operating system (macOS Catalina+), not by the Java version or the CPU translation layer.
Attempt 4: racadm network mount
Since the Java path was dead, I tried mounting the ISO over the network through the iDRAC's command-line interface. The plan was to host the ISO on an SMB share from the MacBook and point the iDRAC at it via SSH:
/admin1-> racadm remoteimage -c -u shareuser -p sharepass -l //192.168.1.59/ISOs/ubuntu.iso
This returned a syntax error. Running racadm getconfig -g cfgRemoteHosts showed why: this particular iDRAC6 firmware version does not include the virtual media keys in its configuration database at all. The cfgRHostsVmImageURL and cfgRHostsVirtMediaEnable properties simply do not exist in this firmware's RACADM schema.
cfgRhostsSyslogEnable=1073845248
cfgRhostsSyslogServer1=
cfgRhostsSyslogServer2=
cfgRhostsSyslogServer3=
cfgRhostsSyslogPort=514
cfgRhostsFwUpdateTftpEnable=1
cfgRhostsFwUpdateIpAddr=0.0.0.0
cfgRhostsFwUpdatePath=
cfgRhostsSmtpServerIpAddr=0.0.0.0
No virtual media keys. Without them, there is no way to tell the iDRAC to fetch an ISO from a network share via RACADM. Some newer iDRAC6 firmware versions do include these keys, but flashing newer firmware onto an 11th-generation server is its own project, and the Java virtual media would still be broken for the actual mount operation.
Attempt 5: Community Java console tools
There are open-source projects like idrac6-kvm-console on GitHub that aim to replace Dell's broken native binaries with pure Java implementations. I downloaded one:
curl -L -o idrac6-kvm.jar https://github.com/.../idrac6-kvm-console.jar
java -jar idrac6-kvm.jar --hostname 192.168.1.220 --username root --password ***** \
--iso /Users/sean/Downloads/ubuntu.iso
This failed with Invalid or corrupt jarfile because the GitHub raw URL had served an HTML 404 page instead of the binary. Even when the download succeeds, these tools are unreliable in practice because they still depend on the iDRAC6 protocol and port layout, and the virtual media engine still needs architecture-matched native code that does not exist for modern macOS.
The Working Solution: PXE Boot
After every Java and RACADM workaround failed, I turned to PXE network boot and it worked on the first try. PXE does not touch iDRAC6 virtual media at all. The server boots from the network using its own PXE-capable NIC, and you serve the install files from another machine on your LAN.
The full PXE walkthrough is in a separate article: PXE Boot Ubuntu on a Dell R610 Using a MacBook as the TFTP/HTTP Server. The short version: your MacBook runs the built-in macOS TFTP server for the tiny boot files and Apache for the 2.7GB ISO, your router handles DHCP and points the server at the MacBook, and the R610 boots and installs Ubuntu over the network with no Java, no native libraries, and no physical media.
PXE works because it moves the entire problem outside the iDRAC6 stack. The server's network card does the boot, not the management controller. You never need to load a native library, never need to match a Java version, and never need to care whether your Mac is Apple Silicon or Intel.
The Working Part: The KVM Console
One thing worth noting: the iDRAC6 KVM video console does work on modern Macs, even Apple Silicon, with a custom launcher script. The video console is pure Java and does not load native libraries. You just need to work around the ancient TLS and download the JAR with a Python helper that lowers the SSL security level:
#!/bin/bash
TARGET_IP="192.168.1.220"
PASSWD="yourpassword"
python3 -c "
import urllib.request, ssl
ctx = ssl._create_unverified_context()
ctx.set_ciphers('DEFAULT@SECLEVEL=1')
opener = urllib.request.build_opener(urllib.request.HTTPSHandler(context=ctx))
urllib.request.install_opener(opener)
urllib.request.urlretrieve('https://$TARGET_IP/software/avctKVM.jar', 'avctKVM.jar')
"
xattr -d com.apple.quarantine avctKVM.jar 2>/dev/null
java \
-Djava.security.properties=<(echo "jdk.tls.disabledAlgorithms=None") \
-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 \
-cp avctKVM.jar com.avocent.idrac.kvm.Main \
ip=$TARGET_IP kmport=5900 vport=5900 user=root passwd=$PASSWD apcp=1 version=2
This gives you a live video feed of the server's console, which is useful for watching a PXE boot or interacting with the BIOS. You just cannot use it to mount ISOs. The KVM console is the part of iDRAC6 that aged well. Virtual media is the part that did not.
Why This Will Never Be Fixed
Dell is not going to issue a firmware update for an 11th-generation server released in 2009. The native libraries inside the virtual media JARs are compiled for a platform (32-bit Mac OS X) that Apple no longer supports at the operating system level. Even if Dell wanted to recompile them, the iDRAC6 firmware itself is locked to the hardware generation. There is no path forward for virtual media on this server through the Java applet.
The practical conclusion: stop trying to fix iDRAC6 virtual media on a modern Mac. You will spend hours downloading JARs, extracting libraries, switching Java versions, and bouncing between Intel and Apple Silicon Macs, only to hit the same wall every time. PXE boot solves the actual problem (getting an OS onto the server) in under an hour with services that are already built into macOS. Save the iDRAC6 KVM console for watching the boot, and use the network for the actual install.