All Activity

25.2.3 build fine after upgrade though I had to hold rpi-eeprom, raspi-firmware and raspberrypi-sys-mods Also still getting the Method gave a blank filename apt error

This was my original approach. I don't have the knowledge/experience to parse a script like that and is the reason I was asking here.

Got it to mount the SD card.

Hello there, I have found another problem. My setup: Monitor Samsung syncmaster 2032mw Windoze 10 reports 1280x768 60Hz T95Z plus box cpu amlogic meson(s912)arm cortex-a53 mali t820 gpu dtb used: amlogic/meson-gxm-t95z-plus.dtb everything works including WIFI. But I have overscan in the terminal and in de Cinnamon desktop I am looking for info https://docs.armbian.com/User-Guide_Advanced-Configuration/ enable a custom screen resolution whitin x.org for a resolution when i open a terminal and run xrandr --listmonitors the result is: Monitors: 1 0: +HDMI 1920x1080/90+0+0 HDMI-1 then i type cvt 1628080 1768 but the next command allready result in bash:cvt: command not found Now i am stuck here any tips?

It gets problematic if it is only Windows that is available. In the past I advised people to download Knoppix and boot the PC with that so you have full control. But nowadays SecureBoot might already be a showstopper, unless you know how to deal with it. So your best Linux is probably the ROCK5 with Armbian Bookworm. You can use that to edit the Trixie SD-card. Or upgrade bookworm in-place to Trixie, I have done it more than 10 times in 2025H2, still 1 or 2 computers to go.

I don't know how to set loglevel to 7 in armbianEnv.txt 😕 On Windows after flashing the SD card, I don't have access to the files (ext4 partition probably). And on my Linux VM I'm not able to mount the SD card 😕

From the log I see: Model: Radxa ROCK 5B 272910 bytes read in 34 ms (7.7 MiB/s) I would expect Radxa ROCK 5B+ Or is it 1 DTB nowadays? The bytes read should represent the DTB file that is loaded, I use extlinux so can see what files are loaded, seems this 2025.10 build does not show this. Also be aware it first tries EFI booting, it fails as one can see, so no issue here, but I got confused on my ROCK5B (not the newer upgraded + board) because I had an NVME connectod with a working bootaa64.efi grub.cfg etc as well, so it booted something else than the image from SD-card. I was my own tuned rootfs, so was rather easy to see, but other occasion I did not notice and wasted a lot of time. For this case, what does the kernel spit out ? set loglevel to 7 in armbianEnv.txt

Try what? Do I need to guess what "the most current stable Armbian" is ? Best post an URL + sha256sum what you are doing/using. In theory, I could fairly easy merge it into booting in a KVM, it has then properly working (virtual) RTC from the host (ROCK5B or NanoPi-R6C or RPi4B), but likely needs generic Debian Trixie kernel+initrd/(DTB). That can hide potential errors with your hardware, like a dangling wire in your cable or RJ45 connector or duplicate DHCPserver in LAN or worse (criminals). Or you have ethernet time protocol working, various ethernet HW supports it, like on RPi. Or what do you use to manage your network? Recently netplan.io got pushed, that was a disaster for me, such that I banned Ubuntu now.

Thanks geoW, I look to be having some success with the 25.2.3 build I just have to see if it survives the ugrades

In general it can be done what you want. You just need to understand how Arm SBCs boot/work and Linux in general. Simply stated, it is: ROM -> bootloader -> kernel -> userspace ROM is very specific for the SoC of course, also bootloader is specific as well as the kernel. You can make a kernel that includes all various drivers and methods, like there is for x86 (works with Intel chips and AMD chips). userspace (rootfs) is normally generic, so if you take RPi bootloader+kernel and Libre userspace, it can work. I have done such things several times, but then the other way around: RPi userspace from my 5 years always in-place upgraded rootfs running on Rockchip RK3588 SBCs (Armbian bootloader and kernel). That way no lengthy and boring re-install of all sorts of debian packages and configs tuning etc. Even browser bookmarks are the same then. So very fast up and running with the new SBC. You need to know or start to study the differences in bootloader methods of course. In your case looking into the Libre script/tool would be a good start I think.

I confirm, here it is failing setting up openssh service, it starts rebooting after root autologin prompt, tested on rpi5.

As suggested by Werner, I have connected my computer to the board over UART. I have got this as output. Not sure if it helps.

From the serial_log.txt I can conclude that your SPI-flash must be empty, as it uses the u-boot version that is on the SD-card. So if you also don't have an eMMC attatched, that is now more simple. It is that older legacy based U-Boot, so should work with kernel 6.1.x. But kernellogging level is default set to 1, so I cannot see from the txt file what kernel it is, it might be older 6.1.x, I had lots of trouble with those. At least the 6.1.115 runs very solid on my ROCK3A now; it does all I/O I want: SPI, NVME, SATA (and SD-card as well but slot normally empty). This U-Boot: root@rock3a:~# strings /dev/mtdblock0 | grep "U-Boot SPL 20" U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51) You can set loglevel to 7 in armbianEnv.txt (or directly on kernel commandline is more generic), then you see much more what is going on, it even might spit out info about crashing itself. A key thing for ROCK3A is to have proper PSU: Mine is never stable with whatever 5V only PSU, so also not the RPI5 PSU for example. Various U-Boot versions don't support USB-C PD, so I just soldered my own USB-C cable/connector that I connect to a 12V old car battery or some random 12V PSU that can do 2A or so. Then the onboard DC-DC converter is used to create a stable 5V etc. I don't remember how the ROCK3C should be powered, also not sure if it has own DC-DC converter onboard, so in that case it is just 5V and you are quite dependent on the quality of your PSU. If only an SD-card, it should be fine, but when PCIe is used fort NVME, I think expect freezes. Also think what you want with the ROCK3C; If you want a generic Arm64 Linux computer, you might be better off with 'edge' (both u-boot and kernel). You can't use quite some specific RK35xx features, but should be stable and easier to maintain. You can always compile/build an image yourself.

I'm having trouble with the raspberry omv builds. The latest build I can get working is 24.11.1 which doesn't survive an upgrades (I've tried holding the various packages that seem to cause issues which used to work but doesn't work anymore. The suggested trouble shooting on the download page doesn't work either. Currently the 25.11.1 build is stuck in a bootloop, the only irregularity I can identify is failure to load console-setup.service message. I had a working system that lost my soundcard/DAC-hat after trying to address update error messages which's what started this whole refresh process

I believe renegade uses a diff bootloader but seems logical that firmwares would be different given different hardware The Libre tool is designed to inject Renegade firmware to make a Debian system swappable between Rpis and Renegade boards. What I was ultimately hoping to do though is use Rpi builds for other distros like Alpine and inject Renegade/Firefly firmware to make those pi builds usable on a Renegade board

@Nick A do you know how to remove key ring error? [🐳|🌱] git: Fetch from remote completed, rev-parsing... [ 'debootstrap-debian-devel' 'master' 'FETCH_HEAD' ] [🐳|🌱] Debootstrap version [ '1.0.142' for /armbian/cache/sources/debootstrap-debian-devel/debootstrap ] [🐳|🌱] Installing base system with 5 packages [ Stage 1/2 ] [🐳|🔨] I: Retrieving InRelease [🐳|🔨] I: Checking Release signature [🐳|🔨] E: Release signed by unknown key (key id F8D2585B8783D481) [🐳|🔨] The specified keyring /usr/share/keyrings/debian-archive-keyring.gpg may be incorrect or out of date. [🐳|🔨] You can find the latest Debian release key at https://ftp-master.debian.org/keys.html [🐳|💥] error! [ Debootstrap first stage failed /armbian/cache/sources/debootstrap-debian-devel/debootstrap bookworm yes ]

Thanks a lot @Nick A I will give a try now. I see few more device support added on your fork https://github.com/NickAlilovic/build Can I get the change log only for IK316/H616 with LPDDR2 RAM support? I would like to sync those changes with the most recent upstream source code.

This is confusing for me. What are you actually trying to achieve? What is on Renegade that is not on Rpi?

Even just someone kicking in with yes I think it's possible but not sure how or whatever I'd been thinking to ad the armbian repo hosting firmware files but I doubt it's so simple in practice

@Jeeva Kandasamy I noticed the same problem with my older builds. Should be fixed now. You'll need to install Docker. Also, if you see the build-root errors. Run the same compile options again and it continue where you left off.

These are forums for Armbian Linux, not Android.

I'm looking for an Android 10 image but I haven't been able to find one, but I still need to do the cut to know.

What image are you trying to load?

Thanks for replying, I hadn't noticed the android thing, I have two sd cards one with the radxa android 14 and the other with the debian bullseye from radxa. I didn't mess with the SPI flash because both work correctly, does android flash the spi when booting, I don't understand how it works with the default debian but not here? I will try to maskrom mode and update. Btw here is the whole boot sequence in case it helps (I tried an older armbian build here but still the same). serial_log.txt

Did someone managed to make it work on this model below? I tried creating the image with different allwinner chips but its not booting when I burn the sd and insert on the device. The tv box is a Mortal T1 Android 13 2gb ram and 16gb rom