Booting a 2006 live DVD on 2026 hardware

Four things stop a twenty-year-old live image from starting on a machine bought this decade: firmware that no longer speaks BIOS, a kernel that cannot see the disk, a kernel that cannot see the keyboard, and an X server that has never heard of the graphics card. All four have a documented way around them, and the route below is one download and one command rather than a project — though nothing on this page was timed, because nothing on this page was booted. The thing you probably want back — the compositing desktop, the wobbly windows, the cube on the desktop switcher — is the one part that does not come back, and it is worth knowing that before you start rather than after.

Start with the disappointment: the cube is the part that does not survive

The reason anyone wants a 2006 Linux desktop back is not KDE 3.5 and not OpenOffice 2.0.2. It is the compositing demo. Xgl, David Reveman's OpenGL-backed X server, was first released on 2 January 2006, and for about eighteen months afterwards a rotating desktop cube and windows that wobbled when you dragged them were the most effective advertising free software had. The project that shipped from this domain went to some trouble over it: the manifest for the 3.0 RC1 miniEdition lists x11-base/xgl-0.0.1_p20060524 and x11-wm/compiz-0.0.7_p20060404 on a disc that also had to fit on a CD, and the site published a video of the desktop alongside the torrent.

That effect needed a real GPU with a real accelerated driver, and it is the one thing an emulator will not hand back to you. The reason is architectural rather than a missing flag. Everything else here is recoverable: go in expecting a strange and entirely coherent 2006 desktop drawn in software, and the rest of this page is about getting to it.

First, an image — and the RR4 discs are not among the survivors

Nothing from the RR4 or RR64 era appears to be mirrored anywhere, which the release-history piece documents in detail: the checksums survive, the files do not. So the practical starting points are these two, and they are twenty years apart in what they demonstrate.

That is a genuine 2006 Gentoo live CD, from the same tree and the same months as the DVD this address shipped, and it is small enough for every technique below. Its checksums are worth being exact about, because the distinction they draw is the whole subject of the appendix. The Internet Archive computes an MD5 and a SHA-1 for every file it stores and publishes both in the item's own manifest, so you can prove that what you downloaded is what was uploaded in 2018. Nothing in the item ties what was uploaded in 2018 to what Gentoo released in 2006: there is no DIGESTS file, and distfiles.gentoo.org/releases/x86/2006.0/ now returns 404, so the publisher's own checksums are off the mirrors. An integrity check is not a provenance check, and only the second one is missing here — but the second one is the one that matters.

The other survivor is the end of the same line — Sabayon Sabayon Linux · Ended 19.03, from March 2019, still on ibiblio and on the University of Maryland mirror with MD5 files that agree across both hosts. It will not show you a 2006 desktop, but it is verifiable and 64-bit, and every step here works on it with qemu-system-x86_64 substituted. Check what you downloaded before you spend an evening debugging a boot failure that is really a truncated file.

The four blockers, and what each one actually does to you

One: the firmware no longer speaks BIOS. A 2006 ISO boots through El Torito, a BIOS mechanism. There is no EFI System Partition on the image and no bootx64.efi for firmware to find, so a UEFI-only machine does not fail to boot the disc — it declines to list it at all. Intel signalled this in 2017, when Brian Richardson's Last Mile Barriers to Removing Legacy BIOS put a date on shipping UEFI Class 3 systems, meaning no CSM. Secure Boot is a second and separate lock: nothing pressed in 2006 is signed, and there is no shim to enrol.

Two: the image is 32-bit and the world assumes 64. The mildest of the four. Your CPU still runs 32-bit protected-mode code perfectly well, and the RR4 3.0 RC1 build even moved its CHOST from i386 to i586, so the binaries want a Pentium and nothing more exotic. What breaks is tooling defaults: the emulator binary you reach for, the hypervisor's assumption of an x86-64 guest, any firmware path that is 64-bit only.

Three: the kernel cannot see modern storage, and possibly not your keyboard. NVMe has no driver in mainline Linux until 3.3, in 2012, so an NVMe SSD is not a slow disk to a 2006 kernel, it is no disk. USB 3.0 is worse in a way people do not anticipate: the xHCI driver arrived in 2.6.31, September 2009, so on a machine whose only USB controllers are xHCI, the keyboard works under the firmware's legacy emulation and dies at the exact moment the kernel takes over. A SATA controller presented in AHCI mode is the one storage path with a real chance, and for the discs this domain shipped it is not a guess: every kernel configuration the project published has CONFIG_SCSI_SATA_AHCI=y, built in rather than modular. That settles these images and no others; a different 2006 disc is a different build.

Four: X has never heard of your graphics card. The RC1 manifest carries x11-base/xorg-server-1.0.2-r4 and 72 packages under x11-drivers, none of which knows a GPU designed after 2007. You land on the vesa driver, which needs VESA BIOS Extensions a machine booted in native UEFI mode may not provide. Kernel mode setting did not exist yet either, so the nomodeset advice that solves this class of problem on later systems is meaningless here: there is no mode setting to turn off.

The project published its own kernel configs, and all five still fetch

Most of what follows would be inference if this project had not done something almost nobody bothered with in 2006: it published the kernel configuration for each build next to the image, under /gentoo/kconfigs/. Five of those paths are in the Internet Archive's index of this domain, and unlike the lost images they are not filename-only entries — every one of them returns the file. Reading them converts four judgement calls on this page into answers.

The timestamps inside the files date them better than the captures do. The November 2005 config is the 2.6.14-reiser4 kernel the download page listed for RR64 3.0b0; the January one is the 2.6.15 kernel of the 32-bit 3.0b0 series; the two dated 28 May 2006, ninety seconds apart, are the non-SMP and SMP halves of the 2.6.16 Reiser4 kernel that the release report of 18 June announced for 3.0 RC1. Four things follow, and each of them is a flag decision further down this page.

AHCI is compiled in, not modular. That is the single most useful fact in the set, because it is the difference between a disc that can see a real SATA disk on a machine set to AHCI mode and one that cannot see any disk at all. It holds across both architectures and three kernel versions, which suggests a deliberate policy rather than an accident of one build.

The kernel's CPU floor is lower than the userland's, and it moved when the userland did. CONFIG_M486 in January, CONFIG_M586 in May, three weeks before the RC1 report opened by announcing the i386-to-i586 CHOST migration. They are separate settings — one is what the kernel is compiled for, the other what everything else is — so this is a build moving in step with itself rather than one causing the other. Either way an emulated CPU from a Pentium upwards clears both floors, which is why the conservative -cpu choice below costs nothing.

The memory ceiling is four gigabytes and it is a build-time decision. CONFIG_HIGHMEM4G with HIGHMEM64G unset means these kernels were built without PAE: no amount of RAM handed to the guest gets used above the 4 GB line, and the usable figure is lower still because the PCI hole sits underneath it. Sizing a guest at 8 GB does nothing but reserve host memory.

The live-media path is the ordinary Gentoo one. ISO9660 with transparent compression and SquashFS are both built in, which is the arrangement cdroot exists to drive — Gentoo documents that option as one that "attempts to load livecd.squashfs" — so the genkernel vocabulary in the failure table below is these discs' own vocabulary and not a guess imported from a later era. The VESA framebuffer is built in too, which is the console half of the display story that the X half ends badly.

One caveat on all of this. The five files are the configurations the project published, not proof of what was compiled onto any particular ISO, and nobody can close that gap without the images themselves. They are strong evidence and they are not the artefact.

Do it in an emulator, because the emulator is period hardware

Putting a 2006 image on 2026 metal is a firmware fight with no prize at the end of it. An emulator inverts every blocker above at once, and not by working around them — by presenting the machine the disc was written for. QEMU's default x86 machine type, pc, is documented as an i440FX host PCI bridge and PIIX3 PCI to ISA bridge with 2 PCI IDE interfaces with hard disk and CD-ROM support, and its firmware is the PC BIOS from the Seabios project. That is a 1996 chipset behind a legacy BIOS: blockers one, three and four evaporate, and blocker two is a choice of binary. The current release is QEMU 11.0.3, dated 24 July 2026; older ones are fine, since the flags below have been stable for years with the one audio exception noted underneath.

The invocation, flag by flag

This is a documented invocation assembled from QEMU's own option reference, not a transcript of a session. I have not booted these images; every flag below is justified from the documentation cited at the foot of the page, and where a choice is a judgement call rather than a documented requirement I say so.

qemu-system-i386 \
  -machine pc,accel=kvm \
  -cpu core2duo \
  -m 1536 \
  -cdrom Gentoo_Linux_2006.0_x86_Live_CD.iso \
  -boot order=d \
  -vga std \
  -usb -device usb-tablet \
  -audiodev pipewire,id=snd0 -device AC97,audiodev=snd0 \
  -nic none \
  -display gtk \
  -k en-us

• qemu-system-i386 — the 32-bit binary. qemu-system-x86_64 runs a 32-bit guest too, but the i386 binary keeps the CPU model list period-appropriate, which matters two lines down.
• -machine pc — the i440FX machine described above. The alternative, q35, gives you PCIe and an AHCI controller instead of PIIX3 IDE, which is precisely the modern hardware you are trying to escape. QEMU has removed all versioned machine types at 5.1.0 and older, so pinning to an ancient pc-i440fx-2.x is not an option, and is not needed.
• accel=kvm — hardware acceleration on a Linux host; accel=hvf on macOS. With no accelerator at all, accel=tcg emulates and is perfectly usable here, which is a pleasant consequence of how little work a 2006 desktop is by current standards.
• -cpu core2duo — a judgement call, and the one flag most worth changing if the boot dies early. -cpu host hands a twenty-year-old kernel two decades of feature bits it has never seen; a period model avoids the question. -cpu pentium3 is the conservative choice and clears both floors the recovered configs establish: CONFIG_M586 for the RC1-era kernel, i586 for the userland built against it.
• -m 1536 — QEMU defaults to 128 MiB, which is not enough for a live image that decompresses parts of itself into RAM. There is no point going far above this, and the reason is in the build rather than in folklore: CONFIG_HIGHMEM4G with no PAE puts a 4 GB ceiling on the guest kernel, with the PCI hole taking a further slice below it. One case does want more — the handbook's docache, which caches the disc into RAM, "requires that there is at least twice as much available RAM as the size of the CD". For the 730 MB image above that is about 1.5 GB for the cache alone, so -m 2048 or more if you intend to use it.
• -cdrom — documented as attaching the image "on the default bus of the emulated machine (which is IDE1 master on x86)". IDE is the entire point: a virtio-blk or virtio-scsi device is invisible to this guest, because virtio's guest drivers post-date these images by about two years. -boot order=d then boots it; d is documented as "first CD-ROM" on the x86 PC.
• -vga std — "Standard VGA card with Bochs VBE extensions", which is what both halves of the display path here want: the kernel's own vesafb, built in as CONFIG_FB_VESA, for the console, and the 2006 X vesa driver on top. If X refuses to start, switch to -vga cirrus, the "Cirrus Logic GD5446" card, for which that X tree has a native driver. One of the two will come up.
• -usb -device usb-tablet — an absolute-coordinate pointer, so the mouse tracks without QEMU grabbing it. On the pc machine -usb gives you a UHCI controller, and the configs show why that is the safe choice: USB_UHCI_HCD is there as a module and the HID layer above it, CONFIG_USB_HID, is built in. The one place where adding USB helps rather than hurts.
• Audio — -soundhw was removed in QEMU 7.1, so the modern spelling is an -audiodev backend plus a -device; substitute pa or alsa for pipewire as your host requires. AC97 is the right card because ALSA of that era knows it well.
• -nic none — deliberate, and the subject of its own section. -display gtk selects the display backend, and -k sets a keyboard layout for when the guest's own keymap selection will not cooperate.

One flag people reach for that no longer exists: -no-acpi, removed in QEMU 9.0 and now the machine property acpi=off. In practice you want ACPI disabled on the guest kernel command line instead, which is the next section.

When it fails, it fails in one of five places

Every boot option in the table below is documented by Gentoo, which is the correct reference for any live medium built from Gentoo's release tooling — which is what these discs were. Two documents, not one: the handbook's boot-options block covers the hardware flags, and the genkernel page covers the initramfs flags the handbook does not list, including cdroot, "used for loading live media". The exception is doslowusb, which is this project's own spelling from its own release report; current Gentoo documents the equivalent as slowusb, "extra pauses into the boot process for slow USB CDROMs". If one spelling is ignored, try the other. Type them at the boot: prompt after the label the splash screen offers.

What you will and will not see, stated plainly

What survives is the desktop itself: the panel, the menus, the theme, the applications, the fonts, the icon set, the boot splash. On a current host with KVM the 2006 software is running on a CPU it was never designed against — the release these discs shipped targets a 586 and assumes a single core, and CONFIG_HIGHMEM4G says the memory budget it was tuned for topped out at 4 GB. That is a reasoned expectation of a comfortable session rather than a benchmark; nothing on this page was measured, and a reader who finds otherwise should tell us.

You will not get compositing. Xgl was a full X server that rendered through OpenGL, so it needed accelerated GLX underneath it, and QEMU's std and cirrus adapters offer a 2006 X server no DRI at all — which leaves GLX doing indirect software rendering, enough to draw glxgears and not enough to run a compositing window manager as your desktop.

The obvious escape does not work either. QEMU's 3D-accelerated display device passes OpenGL through to the host, but the guest half of that arrangement is a virtio-gpu DRM driver that entered the Linux kernel in 4.2, in 2015, paired with a Mesa Gallium driver from the same year. A 2.6.15 kernel has no mechanism to talk to it and no way to acquire one; there is no flag that closes a nine-year gap in guest driver support.

So the one thing that sold this distribution is the one thing the safe route cannot reproduce: the artefact survives, the demo does not, and the demo was the product. If the cube is genuinely what you are after, the only route is real hardware with a GPU of the period.

The bare-metal route, and why a 2012 ThinkPad beats a 2026 desktop

Four requirements, and machines from roughly 2008 to 2015 satisfy all four while nothing current satisfies any: a legacy BIOS or a working CSM, a GPU with a driver in the 2006 X tree, USB controllers that are not exclusively xHCI, and either an optical drive or firmware willing to boot from a USB one. A business laptop of that vintage — Intel integrated graphics, a real BIOS setup menu, a physical wireless switch — is a better time machine than any current desktop. In its firmware setup: CSM or Legacy boot on, Secure Boot off, SATA set to AHCI or, if the menu still offers it, IDE or Compatibility mode, USB legacy support on.

Then the media, which is where most attempts actually die: these ISOs are not hybrid images. ISOLINUX gained hybrid mode in version 3.72, and it requires the image to be post-processed with the isohybrid tool before it can be written raw to a USB stick — a technique that did not exist when these discs were built and was never retroactively applied to them. Writing a 2006 ISO to a stick with dd produces a stick the BIOS will not boot, which accounts for a great many "it just does nothing" reports.

Two ways around it. Burn a real disc, which is why a USB optical drive is the most useful object in this whole exercise; the disc's own doslowusb flag exists precisely because people were already booting that way in 2006. Or use Ventoy, currently 1.1.17, released 24 July 2026, which keeps ISOs as files on a normal partition and chainloads them. For images this old its normal mode may not cope, and memdisk mode is the fallback: it "will load the whole ISO/IMG file into memory and boot it", with "higher success rate to boot", reached with Ctrl+d in the boot menu — it was F1 before Ventoy 1.0.83, which is what most older instructions still tell you.

Memdisk mode carries a documented limit that decides the question: "the ISO file can't be too big, normally less than 1GB". The Gentoo 2006.0 CD, at 730 MB, is inside it; a 4 GB live DVD is not, and no configuration changes that. If the artefact you want is specifically a DVD-sized 2006 image, it is an optical drive and a blank DVD, or it is the emulator.

Getting files in and out of a machine with no network

The modern conveniences are all unavailable: virtio-9p shared folders, virtio-serial, guest agents, clipboard sharing — every one needs a guest driver written years after this kernel. What works is what worked then, removable media, emulated.

# in: build a second CD and attach it alongside the live image
xorriso -as mkisofs -r -J -V PAYLOAD -o payload.iso payload/
qemu-system-i386 ... -drive if=ide,media=cdrom,file=payload.iso

# out: a small raw disk the guest can format, and the host can loop-mount
qemu-img create -f raw scratch.img 512M
qemu-system-i386 ... -drive if=ide,format=raw,file=scratch.img

Partition and mkfs.vfat the scratch disk once inside the guest, and every subsequent session has a two-way channel. FAT rather than ext2 for the reason it was chosen in 2006: both ends read it without argument. On the host afterwards, losetup -P gives you the partitions and an ordinary mount gives you the files.

Never put it on a network

Keep -nic none on the QEMU line. On real hardware, unplug the cable and leave the wireless switch off.

This is not a hedge or a policy position. A 2.6.15 kernel carries every locally and remotely exploitable bug found in that branch since February 2006, none of them fixed; the browser is of the same vintage, and the one manifest that survives from this domain pins it exactly, at mozilla-firefox-bin-1.5.0.3; the TLS stack cannot negotiate anything a current server will accept even if you wanted it to. Bridging that guest to your LAN puts an unpatchable machine inside your perimeter in exchange for nothing, because there is nothing left to fetch: the Portage snapshot is a fossil, and the Entropy servers a Sabayon-era install reaches for stopped answering years ago. The full risk assessment for an unsupported system is a separate piece; for a live image booted out of curiosity, the air-gapped case is the only one worth arguing about, and -nic none gives you it for free.

Appendix: archiving an old ISO so it survives the next twenty years

Every problem on this page is downstream of somebody, twenty years ago, not doing the following. It costs ten minutes.

Read physical discs with a tool that expects failure. ddrescue -d -r3 /dev/sr0 disc.iso disc.log reads the raw device with direct access and retries, and its log lets you resume against a second copy of the same disc to fill in what the first could not read. Copying files off a mounted disc instead loses the boot catalog, and an ISO without its boot catalog is a data archive, not a bootable image.

Publish a checksum next to the file, not in a forum post. sha256sum disc.iso > disc.iso.sha256. If the project published its own checksums, keep those too, verbatim, in a separate file — they are the only thing that can ever tie your copy to what shipped. That is exactly where the archive item quoted above falls down: the host will tell you what it received in 2018, and nobody can tell you whether what it received in 2018 was a faithful copy or a re-master.

Keep the torrent file if one exists. A .torrent carries a SHA-1 for every piece of the exact bytes it was made from, which makes it an independent verification of an image whose checksum file has been lost — a property worth far more now than the swarm it was written for. This is not a hypothetical here. Two of this domain's torrent filenames are in the archive's index; one of them still returns a torrent rather than a page captured years later, and it is for a release whose .md5 file did not survive:

Read what that recovers. Six of this domain's MD5 files survive and this release is not among them — but the torrent gives the exact byte length of the ISO, a hash of every 512 KiB of it, and an info hash that identifies the release unambiguously. If a copy of that image ever surfaces on somebody's shelf, it can be checked to a finer resolution than the project's own MD5 would have allowed, twenty years after the tracker went quiet. Metadata outlived the files, which is the argument for keeping metadata.

Write a README, and be specific about what you did not verify. Where the bytes came from, the URL, the date, the checksum you computed, the checksum the project published if you found one, and a plain sentence about what remains unproven. Then put a copy somewhere that is not your house.