Installation
Rufus is the only supported software for flashing dArkOSen.
Rufus is the only supported software for flashing dArkOSen.
And one last time,
Rufus is the only supported software for flashing dArkOSen.
This is not a recommendation. It is a support requirement.
If you flash dArkOSen with another application and the resulting installation behaves incorrectly, the first troubleshooting step is to reflash the image using Rufus before reporting or troubleshooting any other problem.
This is especially important because many failures caused by an incorrectly written or subsequently modified image do not produce an obvious filesystem error. The console may boot normally while individual files, filesystem structures, permissions, configuration data, or other parts of the installation are incorrect.
The resulting symptoms can therefore appear completely unrelated to the flashing process.
DOWNLOAD RUFUS HERE:
The dArkOSen .img file is a complete disk image, not an archive of files intended to be extracted onto a formatted SD card.
For example, the dArkOSen_R36_07312026b.img image contains:
MBR partition table
│
├── Partition 1
│ ├── Start: sector 32768
│ ├── Size: 100 MiB
│ └── Type: FAT32 (LBA)
│
├── Partition 2
│ ├── Start: sector 237568
│ ├── Size: 6.7 GiB
│ └── Type: Linux
│
└── Partition 3
├── Start: sector 14368768
├── Size: 100 MiB
└── Type: 0x07
The image uses an MBR partition table and contains three partitions at specific sector offsets.
The image is approximately 6.95 GiB and contains 14,573,568 sectors of 512 bytes each.
These structures are part of the installation.
The flashing process therefore needs to reproduce the image as a disk image on the SD card. It is not equivalent to:
- formatting an SD card,
- creating partitions manually,
- extracting the contents of the image,
- copying the files onto those partitions.
The partition table, partition offsets, boot sectors, filesystem structures, and data contained within the image all form part of the installation.
A raw disk image is written to the SD card starting at the beginning of the target block device.
Conceptually:
IMAGE FILE SD CARD
sector 0 ────────────────> sector 0
sector 1 ────────────────> sector 1
sector 2 ────────────────> sector 2
... ...
partition data ────────────────> corresponding sectors
The MBR at the beginning of the image defines where the partitions begin.
The filesystem data then exists at those exact locations.
A raw image writer does not need to understand the files contained in the filesystems. It can simply copy the image's blocks to the target device.
This is fundamentally different from extracting an archive or copying files to an already-formatted partition.
There is an important distinction between what should work in theory and what is supported by this project.
Rufus, balenaEtcher, Win32 Disk Imager, and other applications can perform raw image writes. There is no general technical rule that makes Rufus inherently capable of writing a raw .img correctly while every other raw-image writer is incapable of doing so.
dArkOSen does not claim that.
The reason Rufus is required is empirical.
During development and distribution of dArkOSen, numerous users have reported installations produced with other flashing software exhibiting unexplained and inconsistent problems. Reported failures have included:
- Missing files
- Missing themes
- Applications or emulators that normally work failing to launch
- Buttons not functioning correctly
- Hotkeys performing unexpected functions
- Inconsistent system behaviour
- Lockups
- Other unpredictable behaviour that cannot be reproduced on correctly flashed installations
The important characteristic of these reports is that the failures are often not consistent with a single identifiable software bug.
The same dArkOSen release can behave normally on one SD card and exhibit apparently unrelated problems after being flashed using another application.
When the affected card is subsequently reflashed using Rufus, these problems have repeatedly disappeared.
This is based on project testing and user reports. It is therefore an empirical support policy, not a claim that the underlying cause of every failure has been conclusively identified.
A raw image contains filesystem structures as well as the files themselves.
Writing the image successfully does not necessarily mean that the resulting installation will remain byte-for-byte identical to the original image.
Operating systems can automatically inspect, mount, and modify filesystems on removable media.
For example, Windows automatically mounts filesystems it recognizes on removable drives. Rufus documents that Windows can modify mounted filesystems by creating files and changing filesystem metadata, including timestamps. This can occur after the image has been written and is not necessarily caused by the image-writing application itself.
This matters because a raw image can contain Linux filesystems that Windows cannot fully interpret while also containing filesystems that Windows does recognize.
The result is that the contents of the SD card after flashing are not necessarily guaranteed to remain identical to the source image simply because the raw write completed successfully.
This is one reason that filesystem handling and the behaviour of the operating system performing the flash can matter.
It is not, however, sufficient evidence to conclude that this is the specific cause of every dArkOSen flashing failure.
Other applications can legitimately write raw disk images.
For example, balenaEtcher explicitly supports flashing OS images to SD cards and verifies the completed flash.
That does not make it a supported dArkOSen flashing method.
dArkOSen is not a generic disk image, and the project does not have sufficient testing across every combination of:
- Flashing application
- Application version
- Operating system
- SD card
- SD card reader
- USB adapter
- Host hardware
- Filesystem handling
- Post-flash operating-system behaviour
to guarantee that an installation produced by another application is equivalent to one produced by the supported procedure.
Rufus provides a known and repeatable installation procedure for the project.
That is the standard we support.
Extract the downloaded archive until you have the .img file.
Do not attempt to extract the contents of the .img file onto an existing SD card filesystem.
Open Rufus and select the SD card.
Select the dArkOSen .img file as the boot selection/image.
Make absolutely certain that the selected target is the SD card.
Everything on the selected target will be overwritten.
Write the image to the card.
After the image has been written, open the card's boot partition and run:
SELECT MODEL.bat
Select the exact genuine R36 model being used.
Safely eject the SD card from the computer and insert it into the console.
Power on the console.
The first boot is not a normal boot.
dArkOSen will expand the system partitions and reboot during the process.
The console is expected to reboot twice before reaching the normal dArkOSen installation.
Do not interrupt the process simply because the console reboots.
After the expansion process completes, dArkOSen will boot normally.
Rufus is a Windows application.
For users who cannot run Rufus, balenaEtcher is the only alternative currently known to have produced a reasonable success rate on macOS.
It is still not a supported flashing method.
If a macOS installation produces unexplained behaviour, the supported troubleshooting procedure is to flash the image using Rufus on a Windows system and retest the card before investigating the console itself.
If your genuine device is not listed in the model selector, do not randomly select another model.
First make backups of the original device-tree files from your existing installation.
Rename the required files as:
rg351mp-uboot.dtb
rk3326-r36s-linux.dtb
and place them on the boot partition as appropriate for the installation.
Using an unmodified device tree means that some dArkOSen-specific hardware configuration and overclocking functionality may not be available.
Do not assume that a DTB from a visually similar clone is appropriate for a genuine device.
If the installation exhibits unexpected behaviour such as:
- Random button failures
- Incorrect hotkeys
- Missing files
- Missing themes
- Emulators failing unexpectedly
- Lockups
- Configuration behaving differently from a known-good installation
- Other unexplained or inconsistent behaviour
Do not begin by modifying the system.
First verify the installation method.
If the image was not flashed with Rufus:
- Reflash the SD card using Rufus.
- Run
SELECT MODEL.batagain. - Boot the console.
- Allow the automatic partition expansion and reboots to complete.
- Test the installation again.
If the problem disappears after a Rufus flash, the previous installation should be considered invalid for troubleshooting purposes.
Do not use a non-Rufus installation as evidence that a dArkOSen feature, emulator, DTB, or configuration is defective.
Rufus is the only supported flashing software for dArkOSen.
This requirement exists because it gives the project one known, repeatable flashing procedure and because extensive user reports have demonstrated a substantially higher rate of unexplained failures with other flashing methods.
The project does not claim that other raw-image writers are technically incapable of producing a correct card.
It does claim that dArkOSen installations created with them are unsupported.
If you want a supported installation, use Rufus.
dArkOSen is a passion project born out of love for the R36S. If you appreciate what I do and want to support the project you can show that support by buying me a coffee. Proceeds help fund the cost of SD cards and other expenses involved with development.