RROrg/rr: a preinstallation and recovery environment for Synology DSM on x86 hardware

What RR actually solves for Xpenology builders

Installing Synology DSM on non-Synology hardware has never been a single download. The boot medium has to present the right model identity, load the correct kernel modules for the machine's NIC and storage controller, and point at a matching DSM PAT file. RR, short for redpill's preinstallation and recovery environment, packages that chain into one build process. The README describes it as "a single flash of bootload pre-installation process in addition within recovery environment", which is the honest summary: it is both the installer and the console you return to when the installed system stops booting.

The audience is narrow and technical. You need an x86/x64 machine, some willingness to read a build log, and a spare disk. The README's disclaimer sets the tone before any instructions: it states that any user-specific custom modification of the prebuilt bootloader images could cause irreversible data destruction, and that the project is released for educational purposes with commercial application strictly prohibited. That is not boilerplate. A bootloader that misidentifies a disk layout can write over the wrong volume.

It is also not a general purpose NAS distribution. RR exists to reproduce the Synology DSM experience on hardware Synology did not sell you. If you want a NAS OS that is designed for arbitrary hardware, this is the wrong starting point.

How the build process gets model, PAT and driver information

The mechanism visible in the README is a compile step that reaches out to the network. During the compilation process, the project states, you need an Internet connection to obtain model and version information and to download the corresponding ROM. The data behind that step is published as spreadsheets in the repository: models.xlsx, pats.xlsx, addons.xlsx and modules.xlsx, all under docs/. There is also a driver lookup page at rrorg.github.io/rr/modules.html for checking whether a given piece of hardware has a module behind it.

That design has a direct consequence. If the machine doing the build has no route to the Internet, the README tells you to build a pre-compiled bootloader through RR-CUSTOM at rrorg.github.io/rr instead. So the offline path exists, but it is a separate service, not a flag on the local build.

The repository layout backs this up. There is a files/ tree, which the contributing guide shows contains the initrd payload under files/initrd/opt/rr, plus scripts/ for host-side helpers, update-check.sh and update-list.yml for version tracking, and a VERSION file. The localisation workflow in the README confirms the architecture: strings are extracted with xgettext from the Shell sources in files/initrd/opt/rr, which means the recovery environment itself is a set of Shell scripts running inside an initrd, not a compiled daemon.

Installing RR on Proxmox VE with the one-click script

The fastest documented path is the Proxmox VE script. It is piped straight into bash, so read it before you run it. The README gives this invocation with a bootloader disk type of usb:

curl -fsSL https://github.com/RROrg/rr/raw/refs/heads/main/scripts/pve.sh | bash -s -- --bltype usb

The script accepts optional parameters, all listed in the README. The ones you are most likely to touch are --onboot with 0 or 1 (default 1), --efi with 0 or 1 (default 1), --bltype taking sata, usb or nvme (default sata), --storage for the image storage name such as local-lvm, and --tag to pin a specific image tag instead of downloading the latest release. There is also --img to use a local image file, and --v9ppath and --vfsdirid for virtio 9p and virtio fs shares. After the VM is created, you open its console and work through the RR menu to pick a model and DSM version, then let it download the PAT and build the loader. The README does not document a rollback procedure for a failed build.

A second documented path runs the whole thing in Docker. The README's Compose file expects you to download rr.img from the latest release and replace the placeholder path:

services:
  rr:
    image: qemux/qemu:latest
    container_name: rr
    environment:
      RAM_SIZE: "4G"
      CPU_CORES: "2"
      DISK_FMT: "qcow2"
      DISK_TYPE: "sata"
      DISK_SIZE: "32G"
    devices:
      - /dev/kvm
      - /dev/net/tun
    ports:
      - 7681:7681
      - 5000:5000

The README marks 4G of RAM as the recommended minimum for DSM and notes the ports: 5000 and 5001 for DSM management, 7681, 7304 and 7080 for RR management, and 8006 for QEMU management. The container needs /dev/kvm and /dev/net/tun, NET_ADMIN capability, and a stop_grace_period of 2m so DSM shuts down cleanly.

Where RR stops being the right tool

The failure modes are mostly about hardware and version coverage. The model, PAT, addon and module lists are finite spreadsheets. If your NIC or HBA is not represented in modules.xlsx or the driver lookup page, the built loader will boot and then fail to find the network or the disks, which looks like a broken install rather than a missing driver. Checking the lookup page before building is cheaper than debugging it afterwards.

DSM version coverage is the second constraint. The PAT list is what the builder can download. A DSM release that is not in that list cannot be targeted, regardless of what the menu offers.

The third is the recovery environment itself. RR is the tool you use when DSM will not boot, so it sits on the same boot medium. If that medium fails, or if a firmware update changes the boot order, you have lost the console as well as the installed system. The README's own disclaimer is blunt about the stakes: any custom modification of the prebuilt images can cause irreversible data destruction. Keep the data on separate disks from the loader, and do not treat the loader disk as a backup target.

Finally, the licence and the disclaimer disagree with commercial use. The README states that commercial application of the software is strictly prohibited, while the repository is GPL-3.0. If you are deploying this inside a business, that sentence is the one to read carefully.

RR against Arc Loader and the older ARPL lineage

The obvious comparison is Arc Loader, which is what people search for alongside RR. Both are Redpill-derived bootloaders for running DSM on non-Synology x86 hardware, and both present a menu-driven build step. The difference is in packaging and in the surrounding tooling. RR publishes its model, PAT, addon and module data as spreadsheets in the repository and offers a driver lookup page, which makes the coverage question answerable before you build. It also ships a Proxmox VE one-click script and a Docker Compose path, so the loader can be built inside a VM or container rather than on bare metal. Arc Loader's documentation is a separate project and the README here does not describe its internals, so a feature-by-feature comparison is not something this material supports.

The other reference point is ARPL, credited in the acknowledgements alongside RedPill-TTG, redpill-lkm5 and linux_dsm_epyc7002. RR is a continuation of that lineage rather than a fresh design. If you already know ARPL's menu flow, RR will feel familiar. If you have never built a Redpill loader, the learning curve is the same one, and the disclaimer applies equally.

Maintenance, releases and what the licence means in practice

RR is not archived, and the last push to main was on 2026-09-18, three days before this writing. Releases are frequent: 26.9.0 on 2026-09-04, 26.8.2 on 2026-08-30, and 26.8.1 on 2026-08-13. The repository carries update-check.sh and update-list.yml at the top level, which is consistent with a project that expects loaders to be rebuilt as new DSM versions appear.

That cadence is the upgrade cost. A bootloader is tied to a DSM version and to a hardware configuration, so a DSM update can require a rebuild, and a rebuild means going back into the recovery environment. Budget for that rather than treating the install as one-and-done. The project's own version tracking files exist precisely because the upstream data changes.

The licence is GPL-3.0, and the README adds a restriction of its own: the software is released for educational and learning purpose only, with commercial application strictly prohibited. GPL-3.0 and a no-commercial-use clause are not obviously compatible, and the README does not reconcile them. Whether that clause is enforceable, or how it interacts with GPL-3.0's permissions, is a question for a lawyer, not for this article. What is clear is the project's stated intent, and anyone planning a commercial deployment should weigh that stated intent before adopting it.

Editorial conclusion

RR suits engineers who already understand the Redpill boot chain and want a maintained build environment for DSM on their own x86 hardware, plus a recovery console when an update goes wrong. It is the wrong choice for anyone treating it as a supported Synology product, for commercial deployment, or for hardware the model and PAT lists do not cover. Before flashing, verify that your NIC and storage controller appear in the modules list and that a matching PAT exists for the DSM version you intend to run; the README's own warning is that customised bootloader images can cause irreversible data destruction.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. RROrg/rr on GitHub