# Actions-FriendlyWrt turns a GitHub Actions runner into an OpenWrt build farm > Actions-FriendlyWrt is a set of GitHub Actions workflows and scripts that compile FriendlyWrt firmware images for a long list of FriendlyELEC boards and publish them as GitHub releases. It is a shell-driven fork of the P3TERX Actions-OpenWrt approach, and the repository ships the workflow definitions rather than the images themselves. **friendlyarm/Actions-FriendlyWrt** — Build FriendlyWrt using GitHub Actions - Repository: https://github.com/friendlyarm/Actions-FriendlyWrt - Stars: 547 · Forks: 283 - Language: Shell - License: not declared - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/friendlyarm-actions-friendlywrt ## What the repository actually contains The project description is Build FriendlyWrt using GitHub Actions, and the primary language is Shell. The top-level layout is small: a .github directory, .gitignore, README.md, README_en.md and a scripts directory. There is no application code here, because the product is the workflow. The compilation runs on GitHub's runners, and the output is published as releases, with the firmware download address given as the repository's releases page on GitHub. The default branch is master, the last push was on 2026-10-14, and the release list shows dated tags such as FriendlyWrt-2026-10-13, FriendlyWrt-2026-08-07 and FriendlyWrt-2026-07-21, so a new build appears roughly monthly. The acknowledgements credit luci-app-diskman, luci-theme-argon, P3TERX's Actions-OpenWrt, NanoPi-R1S-Build-By-Actions and QiuSimons' YAOF, which is the clearest statement of lineage in the repository: this is a fork of a well-known community build pipeline, with board support and package tweaks layered on top. ## Two firmware artefacts, and the eMMC flashing rules The README distinguishes two files in each release, and confusing them is the most common way to brick a board. XYZ.img.gz is the firmware image, writable to an SD card or to eMMC for boot. images-XYZ.tgz is an upgrade package that is only for the eMMC flashing assistant and cannot be written to an SD card to boot. The flashing procedure depends on which case you are in. For a first install you write XYZ.img.gz to an SD card, boot the system, enter the FriendlyWrt backend, go to System and then the eMMC flashing assistant, and upload the firmware directly without extracting it; once that finishes you remove the SD card and the device reboots from eMMC. For a minor version upgrade, such as moving from 25.12.2 to 25.12.3, you flash an images-XXYYZZ.tgz through the same assistant and can choose to keep data, though the README notes compatibility is your own call to assess. For a major version upgrade, such as 24.10 to 25.12, the recommendation is to back up the configuration first and then use the full XYZ.img.gz image, to avoid compatibility problems. Default credentials are listed as root and password, with the backend reachable at 192.168.2.1. ## Which boards are covered Board support is added over time and the update log is the only place it is recorded. Reading it backwards from the most recent entries, the set includes the NanoPi-R28S, NanoPi-M6V2, NanoPi-M6, NanoPi-M5, NanoPi-M4v2, NanoPi-NEO3-Plus, NanoPi-R76S, NanoPi-R3S, NanoPi-R3S-LTS, NanoPi-Zero2, NanoPi-R5C including a 2GB variant, NanoPi-R6C and NanoPi-R6S, along with the NanoPC-T4 and NanoPC-T6. Newest first: the 2026/10/13 build fixes the network LED status display on the NanoPi-R28S, the 2026/08/07 build adds NanoPi-R28S support and fixes an RTL8125 issue tracked as issue 130, and the 2026/06/09 build adds NanoPi-M6V2 support. That listing is the practical inventory for anyone deciding whether their board is covered, and it also shows the pace of the work, with board support appearing a few times a year rather than all at once. WiFi support has been added along the way too, including on-board WiFi for the NanoPC-T4 and NanoPi-M4v2 in the 2026/06/25 build and support for RTL8851BU wireless cards in the 2025/06/06 build. ## Kernel versions, drivers and the OpenWrt base The builds track upstream OpenWrt releases closely. The update log shows moves to openwrt-25.12.5 on 2026/07/08, 25.12.4 on 2026/06/05, 25.12.2 on 2026/04/29, 24.10.4 on 2025/12/31, 24.10.2 on 2025/06/30, 24.10.0 on 2025/02/28, then 23.05.5, 23.05.4, 23.05.3, 23.05.2 and 23.05.0, with 22.03.5, 22.03.4 and 22.03.3 and 21.02.7 and 21.02.6 for older branches. Kernels are maintained per SoC family, and the log is explicit about it: RK33xx moved to kernel 6.6.134 in the 2026/06/09 build, RK35xx to 6.1.141 on 2025/12/31, and the rk3568 and rk3588 targets to 5.10.160 on 2023/07/04. Driver work appears throughout, including an RTL8125 update on 2026/07/22 aimed at improving 2.5G network card performance and reducing standby power consumption, ntfs3 support added to the rk3568 and rk3588 5.10 kernels, and pwm-fan driver module work in 2025/07/09 to fix PWM fan control. Kernel 6.1.57 was an RK35xx update in June 2024. The build also enables the built-in fq_codel queue scheduler in the kernel to improve network latency, and fixes an issue where USB devices occasionally failed to work after a reboot. ## Storage, partition layout and the disk manager plugin Several changes over the years concern storage rather than networking, and they are the ones most likely to matter if you run containers on these boards. In the 2025/02/28 build the partition layout was adjusted so the root partition size is fixed, an independent partition was added to improve Docker storage performance, and the data in that partition is preserved even after a factory reset. The opt partition had an inode count that was too small, and that was fixed in the 2025/03/24 build. A change in 2023/03/01 added ntfs3 drivers for rk3568 and rk3588 on the 5.10 kernel along with kernel minor version updates and network driver updates, and a March 2023 entry updated initramfs and pointed at guidance on disabling OverlayFS or creating an extra partition. The eMMC flashing assistant itself has been improved several times, including a change on 2026/04/29 that strengthened it and added support for more formats, a fix on 2023/12/22 for compatibility with large capacity eMMC, a stability improvement in December 2022, and a change in November 2022 making it usable when booting from eMMC. In March 2025 the assistant was re-enabled for devices with more than 1G of memory when booting from eMMC. The luci-app-diskman plugin, which the acknowledgements credit, had a display problem fixed in December 2024. ## Where this is the wrong route There is a licence and support question to settle first. The licence is recorded as unknown, so there is no stated grant in the repository metadata, and the images are produced by an unaffiliated community workflow rather than by FriendlyELEC, which means a device that misbehaves after flashing has no vendor behind it. The second limitation is that the README documents the build output but not the build process in this repository. The .github and scripts directories hold the workflow, but the README does not explain how to run the compilation yourself, how long it takes, or what the required runner configuration is, so if you want your own fork with your own packages you are reading the scripts rather than following a guide. The third is the update cadence. Dated monthly-ish releases mean you choose between a fresh build with recent kernel and driver fixes and a known image, and the update log shows the base OpenWrt version moving several times a year, so a stale image is months behind on security patches. The fourth is the flash format trap, which the README goes out of its way to explain: an images tgz package written to an SD card simply will not boot, and a major version upgrade through the upgrade package is exactly the case where the README tells you to back up and use a full image instead. ## How this differs from building OpenWrt yourself The alternative to this repository is the official OpenWrt build system, which every OpenWrt vendor uses, and the difference is entirely about who runs it. Compiling OpenWrt yourself means provisioning a machine with the cross-compilation toolchain, resolving package feeds for your target, and spending hours of CPU on a single image, and for a FriendlyELEC board you would also need the vendor's device tree and configuration. Actions-FriendlyWrt moves all of that onto GitHub's runners and hands you a finished artefact. The other alternative is P3TERX's Actions-OpenWrt, which this project credits directly and whose general-purpose approach supports many more targets and configurations than a single vendor's board list. The trade is scope. A vendor-specific workflow like this one ships exactly the boards, packages and defaults that FriendlyELEC users expect, including the eMMC assistant and the disk manager integration, at the cost of the flexibility a general workflow offers. For a user who just wants a current image for one supported board, that is the right trade. For a user who wants custom packages, a different kernel or an unsupported target, the general workflow is the better starting point. ## Conclusion Adopt Actions-FriendlyWrt if you want dated FriendlyWrt builds for a FriendlyELEC board without maintaining a build machine of your own. Skip it if you need a supported vendor image rather than a community build, since these artifacts are produced by an unaffiliated workflow. Before you flash anything, read the eMMC instructions in full, because the img.gz and tgz packages are not interchangeable and the README warns that major version upgrades should use a full image rather than an upgrade package. ## FAQ ### What is Actions-FriendlyWrt? It is a set of GitHub Actions workflows and shell scripts that compile FriendlyWrt firmware images for FriendlyELEC boards and publish them as GitHub releases. The repository holds the .github directory and a scripts directory rather than an application, and the build lineage credits P3TERX's Actions-OpenWrt. ### What is the difference between XYZ.img.gz and images-XYZ.tgz? XYZ.img.gz is the firmware image, which can be written to an SD card or to eMMC for boot. The images-XYZ.tgz file is an upgrade package for the eMMC flashing assistant only and cannot be written to an SD card to boot. ### How do I flash FriendlyWrt to eMMC? Write XYZ.img.gz to an SD card, boot into FriendlyWrt, go to System and then the eMMC flashing assistant, and upload the firmware without extracting it. Remove the SD card afterwards and the device reboots from eMMC. ### What is the default login for FriendlyWrt builds from this repository? The README lists the username as root, the password as password, and the backend IP address as 192.168.2.1. ## Sources - [friendlyarm/Actions-FriendlyWrt on GitHub](https://github.com/friendlyarm/Actions-FriendlyWrt) - [Issues](https://github.com/friendlyarm/Actions-FriendlyWrt/issues) - [README](https://github.com/friendlyarm/Actions-FriendlyWrt/blob/master/README.md) - [Releases](https://github.com/friendlyarm/Actions-FriendlyWrt/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/friendlyarm-actions-friendlywrt