Search the Community

Hello, I am still facing the E: The repository 'http://apt.armbian.com bionic Release, is no longer signed. error message when attempting a apt update So far, I have tried: 1. Waiting 2. Re-adding the repository key as suggested by user "favorit800" in this thread. 3. Setting the repository as "trusted" as suggested by "Jerry Jyrer" in this thread. None of the above have worked, I am running: ~$ cat /etc/armbian-release # PLEASE DO NOT EDIT THIS FILE BOARD=rock64 BOARD_NAME="Rock 64" BOARDFAMILY=rockchip64 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=baaefaf69-dirty DISTRIBUTION_CODENAME=bionic DISTRIBUTION_STATUS=csc VERSION=21.05.4 LINUXFAMILY=rockchip64 ARCH=arm64 IMAGE_TYPE=user-built BOARD_TYPE=csc INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image BRANCH=current ~$ uname -a Linux rock64 5.10.43-rockchip64 #21.05.4 SMP PREEMPT Wed Jun 16 08:02:12 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux Any ETA regarding the repository signing ? Regards!

Hey everyone...I've tried searching the problem I'm having and have tried different things...all so far to no avail. I'm relatively new to learning about pihole and decided to go out and buy the kit from ameriDroid (maybe should have built my own but decided to go this route to try and save myself some time). I received the kit today and started following the install instructions (I am attempting to install via SSH thru Putty). Once I reached the install command, I get an error stating: "Error: Unable to update package cache. Please try "apt-get update". I've tried the apt update/upgrade and I'm still getting the same error. The output from the apt-get update command is the following: root@rock64:/home/pihole# sudo apt update Hit:2 http://ports.ubuntu.com focal InRelease Hit:3 http://ports.ubuntu.com focal-security InRelease Ign:1 https://armbian.tnahosting.net/apt focal InRelease Hit:4 http://ports.ubuntu.com focal-updates InRelease Hit:6 http://ports.ubuntu.com focal-backports InRelease Err:5 https://armbian.tnahosting.net/apt focal Release Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 130.185.239.75 443] Reading package lists... Done W: http://apt.armbian.com/dists/focal/InRelease: No system certificates available. Try installing ca-certificates. W: http://apt.armbian.com/dists/focal/Release: No system certificates available. Try installing ca-certificates. E: The repository 'http://apt.armbian.com focal Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. I've tried running sudo apt-get install ca-certificates but they already appear to be installed. Any help will be greatly appreciated.

Super dumb question, how do I check the current clock speed of the memory? dmesg, /sys, etc? I have a few rock64 (v2) boards. One running Armbian fine, the other and old Ayufan OMV (need to move that to Armbian). I had a board sometimes go unstable (when accessing NTFS filesystem, more details https://forum.pine64.org/showthread.php?tid=13393) so I swapped it out with another board but I keep thinking I could use the board for something and wondering if it was memory clock related. I'd like to check what I have in both systems before trying to change it (and to help keep track later once its changed!) Thanks!

This is when trying to play a Sony demo video that plays OK under Kodi on my Rock 64. Without sudo gives me a green screen, no video whilst using sudo gives me a few green lines then a black screen with no video. dan@rock64:~$ mpv --gpu-context=drm Sony\ Aquarium\ 4K\ Demo.mp4 LIBGL: Initialising gl4es LIBGL: v1.1.5 built on Dec 22 2020 23:27:36 LIBGL: Using GLES 2.0 backend LIBGL: loaded: libGLESv2.so LIBGL: loaded: libEGL.so LIBGL: loaded: libgbm.so LIBGL: loaded: libdrm.so.2 LIBGL: Using GLES 2.0 backend LIBGL: Error while gathering supported extension (eglInitialize: EGL_BAD_ALLOC), default to none LIBGL: Targeting OpenGL 2.1 LIBGL: WARNING, No Limited or Full NPOT support in hardware, Forcing NPOT have no effect! LIBGL: Not trying to batch small subsequent glDrawXXXX LIBGL: try to use VBO LIBGL: Force texture for Attachment color0 on FBO LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done LIBGL: glX Will try to recycle EGL Surface LIBGL: Current folder is:/home/dan (+) Video --vid=1 (*) (hevc 3840x2160 59.940fps) (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz) [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu/opengl] Failed to initialize EGL. [vo/gpu] Failed to setup EGL. Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory [vo/vdpau] Error when calling vdp_device_create_x11: 1 [vo/xv] No Xvideo support found. [vaapi] Failed to initialize VAAPI: unknown libva error [vo/x11] Warning: this legacy VO has bad performance. Consider fixing your graphics drivers, or not forcing the x11 VO. mpi: mpp version: 11d98147 author: JMCC Import changes from fork Kwiboo/mpp, branch libreelec-hdr, and version bump mpp_device: mpp_device_init failed to open device /dev/rkvdec, errno 13, error msg: Permission denied mpp_rt: NOT found ion allocator mpp_rt: found drm allocator mpp: deprecated block control, use timeout control instead mpp: deprecated block control, use timeout control instead H265D_PARSER: No start code is found. H265D_PARSER: mpp_hevc_decode_nal_sei error ret = -1006 mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor Using hardware decoding (rkmpp). [autoconvert] HW-downloading from drm_prime mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor AO: [pulse] 48000Hz stereo 2ch float mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor mpp_device: mpp_device_send_reg ioctl VPU_IOC_SET_REG failed ret -1 errno 9 Bad file descriptor H265HAL: RK_HEVC_DEC: ERROR: mpp_device_send_reg Failed!!! mpp_device: mpp_device_wait_reg ioctl VPU_IOC_GET_REG failed ret -1 errno 9 Bad file descriptor [ao/pulse] pa_stream_cork() failed: Connection terminated [ao/pulse] pa_stream_flush() failed: Connection terminated VO: [x11] 3840x2160 nv12 mpp_device: mpp_device_deinit invalid negtive file handle, Exiting... (Quit) LIBGL: Shuting down dan@rock64:~$ sudo mpv --gpu-context=drm Sony\ Aquarium\ 4K\ Demo.mp4 [sudo] password for dan: LIBGL: Initialising gl4es LIBGL: v1.1.5 built on Dec 22 2020 23:27:36 LIBGL: Using GLES 2.0 backend LIBGL: loaded: libGLESv2.so LIBGL: loaded: libEGL.so LIBGL: loaded: libgbm.so LIBGL: loaded: libdrm.so.2 LIBGL: Using GLES 2.0 backend LIBGL: GBM Surfaces supported LIBGL: Hardware Full NPOT detected and used LIBGL: Extension GL_EXT_blend_minmax detected and used LIBGL: FBO are in core, and so used LIBGL: PointSprite are in core, and so used LIBGL: CubeMap are in core, and so used LIBGL: BlendColor is in core, and so used LIBGL: Blend Substract is in core, and so used LIBGL: Blend Function and Equation Separation is in core, and so used LIBGL: Texture Mirrored Repeat is in core, and so used LIBGL: Extension GL_OES_mapbuffer detected LIBGL: Extension GL_OES_packed_depth_stencil detected and used LIBGL: Extension GL_OES_depth24 detected and used LIBGL: Extension GL_OES_rgb8_rgba8 detected and used LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used LIBGL: Extension GL_OES_depth_texture detected and used LIBGL: Extension GL_EXT_shader_texture_lod detected and used LIBGL: Max vertex attrib: 16 LIBGL: Extension GL_OES_standard_derivatives detected and used LIBGL: Max texture size: 4096 LIBGL: Max Varying Vector: 12 LIBGL: Texture Units: 8/8 (hardware: 8), Max lights: 8, Max planes: 6 LIBGL: Max Color Attachments: 1 / Draw buffers: 1 LIBGL: Hardware vendor is ARM LIBGL: EGLImage from Pixmap supported LIBGL: EGLImage to Texture2D supported LIBGL: EGLImage to RenderBuffer supported LIBGL: Targeting OpenGL 2.1 LIBGL: NPOT texture handled in hardware LIBGL: Not trying to batch small subsequent glDrawXXXX LIBGL: try to use VBO LIBGL: glXMakeCurrent FBO workaround enabled LIBGL: FBO workaround for using binded texture enabled LIBGL: Force texture for Attachment color0 on FBO LIBGL: Hack to trigger a SwapBuffers when a Full Framebuffer Blit on default FBO is done LIBGL: glX Will try to recycle EGL Surface LIBGL: Current folder is:/home/dan (+) Video --vid=1 (*) (hevc 3840x2160 59.940fps) (+) Audio --aid=1 --alang=eng (*) (aac 2ch 48000Hz) [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu/opengl] Could not choose EGLConfig for GLES 3.x! mpi: mpp version: 11d98147 author: JMCC Import changes from fork Kwiboo/mpp, branch libreelec-hdr, and version bump mpp_rt: NOT found ion allocator mpp_rt: found drm allocator mpp: deprecated block control, use timeout control instead mpp: deprecated block control, use timeout control instead H265D_PARSER: No start code is found. H265D_PARSER: mpp_hevc_decode_nal_sei error ret = -1006 Using hardware decoding (rkmpp). AO: [pulse] 48000Hz stereo 2ch float VO: [gpu] 3840x2160 drm_prime[nv12] [vo/gpu] Using HW-overlay mode. No GL filtering is performed on the video! [ao/pulse] pa_stream_cork() failed: Connection terminated [ao/pulse] pa_stream_flush() failed: Connection terminated Exiting... (Quit) LIBGL: Shuting down

Has anyone successfully played a 4K video on a RK3328 (eg a Rock64) using mpv and rkmpp? I've been trying this build of mpv on my 4 GB Rock64 running buster legacy try to get it to play a 4K h264 but I've not had one play properly yet. What is the full mpv command to get fullscreen, 4K h264 playback to work with rkmpp, if possible? I've seen commands such as this suggested but it doesn't work for me: mpv --vo=gpu --gpu-api=opengl --gpu-context=drm --gpu-hwdec-interop=drmprime-drm --hwdec=rkmpp video.mkv I've tried various combos of those options. With all the videos I've tried, I either see the first frame of the video then nothing else (I just have to quit mpv), I just get a black screen or it crashes.

Moved out to a separate topic. Rock64 is unsupported, if you do a little search you will know why. In short, because of problems like yours. Do some search in the forums, please.

Running Armbian on a Rock64 (RK3328) board and in turn running pihole for DNS. I cannot seem to be able to get rid of the secondary IP address that is pulling from DHCP. the main static address I set duing pihole setup is 10.4.5.2. Any way to remove the 10.4.5.98? ifconfig from terminal only shows the .98 address.

Was anybody successfull installing Armbian to Rockbox (Rock64 chipset)?

I've been dealing with this problem for a while now, and after seeing this thread, I decided to dive in a little deeper. With LZ4-compressed lists, running an apt search on my Rock64 currently takes at least 20 minutes. As other users have reported, it appears to be bottlenecked by CPU, and is not saturating the storage I/O. Needless to say, this is not a usable speed. Based on what I've found, I believe with substantial confidence that there is no performance problem with LZ4. This should not be too much of a surprise, because speed, especially decompression speed, is LZ4's primary objective; it is in fact considerably faster than LZO in that regard, which means that it's dramatically faster than DEFLATE (gzip). I cannot imagine any conceivable case where switching from LZ4 to DEFLATE would result in decompression performance improvements, and indeed it does not seem to do so here. In any case, you can trivially see this for yourself by using the command-line lz4 utility to decompress one of the compressed list files in /var/lib/apt/lists. On my Rock64, decompressing the largest of these (/var/lib/apt/lists/apt.armbian.com_dists_buster_main_binary-arm64_Packages.lz4, which weighs about 1.8 MB) takes around a tenth of a second. For some perspective, my test run of an apt search took just over 2700 seconds, so if it did spend all or most of this time doing LZ4 decompression, then it could easly have decompressed every list in the directory over a thousand times each. I am not an expert on the intricacies of file compressors, but I find it to be highly unlikely that LZ4 is responsible for the slowness we're seeing here. I had a look at the strace output for the search operation. I'm new to reading straces, but I think I can confirm what a previous poster said, which is that it's accessing the same files over and over again with small reads, often many times in the same place. It is unclear to me what function this serves, but this appears to be what takes up the majority of the runtime. If you would like to see for yourself, I've made the full strace output available at https://fluora.net/strace_apt-search_armbian.7z. Be warned that it's around 260 megabytes when uncompressed, but since it's extremely repetitive, it compresses efficiently, and the 7z archive is only about 96 kB. In addition, you may compare this to the strace of a sane apt-search operation that I took on an x86 laptop running Debian Bullseye with gzip-compressed package lists, available at https://fluora.net/strace_apt-search_debian86.txt (116 kB, not compressed). This isn't much more than a guess, but I wonder if apt is decompressing the entire list with each one of these repeated read operations - this would explain not only the slowness, but also why switching to uncompressed lists seems to help (since it allows the storage cache to render the repeated accesses cheap). From what I've found here, I strongly suspect that something is wrong with the version of apt distributed by Armbian. I don't know enough about the code to know where to start looking, but this is the point where I would hope that someone familiar with Armbian's modifications to apt could help out.

Indeed. For example, my Rock64 and my Neo3 are stable at 1.3 GHz with -25mV and -50mV respectively vs. default OPP values. Silicon lottery. It's still strange that H6 DTS lacks a proper OPP. Maybe with Unstable kernel, based upon 5.11 mainline? Some patches for H6 were included in 5.11 and accompaining DTS.

I'm trying to create a microSD card to boot Armbian, but first would be inserted into a Windows laptop to edit some configuration. To make the microSD show up in Windows, the first partition must be a FAT partition, and so Linux would be ext4 partion 2. I suspect I'll need to put the /boot partition on the FAT volume, with directions to load from mmcblk1p2. In case it matters, this is a Rock64 without emmc. I've just started this research, but I'd be grateful for any u-boot-savvy person's help here. Thanks.

Maybe my problem is a bit different then. My Rock64 (with both Armbian Stable and Unstable) does not reboot after "sudo poweroff": it performs the shutdown sequence, but does not really "power off". It is halted, does not respond to login or ping, but the peripherals are still powered and the board still draws the typical idle current (about 220 mA); the heatsink stays warm too.

My Rock64 using Armbian_21.02.3_Rock64_buster_current_5.10.21.img.xz works fine. It didn't used to. I had the same shutdown, autorestart problem. Last year, my problem first occurred with the Armbian_20.08.1_Rock64_buster_current_5.8.6.img.xz version when I upgraded to the 5.9.14 kernel. I used the armbian-config program to back out the kernel to the 5.9.11 version and the poweroff then worked. One thing that I noticed when I restored the kernel is that my hardware ethernet address xx:xx:xx:xx:xx:xx changed. I had OMV5 installed and had to run omv-firstaid to fix the ethernet definition. My Rock64 with Armbian has worked ever since. I don't know why the address changed or why it is now working. So, I now decided to install the current Armbian_21.02.3_Rock64_buster_current_5.10.21.img.xz on a new SD card. Everything works just fine. Using 'sudo poweroff', it shuts down immediately without restarting. I also installed OMV5 and the shutdown from OMV works also. Could that restoring of the kernel and some process changing the hardware ethernet address have fixed it ?

@firewire10000 Hi, I can confirm this behaviour, both with the Stable image (kernel 5.10.21) and with the latest Unstable from yesterday (kernel 5.11.15). Unfortunately I don't know how to fix it. I tried rebuliding the kernel from the latest "Edge", with CPU Power Management enabled, but nothing changed. The Rock64 is not supported by Armbian, so if powerdown is important to you, I would advice sticking with Ayufan images.

Hi all, I'd love to run my sas2008 card on armbian. Im currentky testing the ayufan 0.10.12 build and it is working with my sas cards flawlessly even with sas expanders and 16x hdd attached. https://github.com/ayufan-rock64/linux-build/releases On armbian or any other release for that matter there is insufficient boot wait time for to card, i believe these cards take around 400ms to boot with bios rom deleted. The patch provides 1 second wait time. Working kernel patch is here thats been pulled into the above release https://github.com/nuumio/rp64-linux-mainline-kernel/releases any chance of having this incorporated? My skillset with kernel/image building is very short in supply so im not sure how much i can do but point me in the right direction and ill try, it appears this is a very usefull feature for those with lsi sas cards for bigger nas boxes. Krita

@Henry Delphing I'm trying to set up an "OrangePi kernel building" environment on one of my SBCs, a Rock64 2GB running Armbian stable. It's a difficult task, because documentation is often obsolete, sparse and conflicting; plus, every pre-cooked build environment is quite rigid about what to build and from which source. Anyway, my goal is to replicate Hexdump's kernel: clone jernej's sources, apply hexdump's patches, load hexdump's kernel config and build. Then sort out which of the various DTSs actually enables USB on the PiZero2. If and when I'll reach my goal, I'll post a link to the working kernel here, I promise.

Hi, in my case the test is on a Rock64 (4GB, v2 edition) using latest current Buster or Focal. The problem is in the first init configuration assistant. When selecting the "User language based on your location", after selecting es_AR.UTF-8 (I am from Argentina) it "auto-detects" my keyboard layout as AR which belongs to Arabic iirc (which is wrong). After this of course I can't type anything right on terminal. I had to fix it over ssh by issuing the command: sudo dpkg-reconfigure keyboard-configuration.

Search the forums. Don't expect official documents: as we have stated several times, Rock64 is not supported by Armbian, and therefore we won't put resources into it. If you, or any other community member, wants to work on documenting the problems or fixing them, feel free to do it. I don't even own the board. And please start a different thread on the "Peer-to-Peer Support" subforum. Any further post about the Rock64 problems will be deleted from this thread.

I have the same problem with my Rock64. I couldn't get it to boot. Are there docs about the problems, anywhere?

Wow rollin the dice. Im optimistic on their behalf and won't make any passive comments about the Rock64

Ok, I missed that one. Anyways, installing Buster of Focal with legacy Kernel makes my Rock64 (4GB) to kernel fault randomly and crash, even at start: )

And shit I still have problems, so I'm looking for the right .dtb for my mx10 for this buster image of the station M1, I'm a bit lost to tell the truth, but I found an old post If anyone still has .dtb files for the mx10 I'm very interested ... Otherwise I tested several dtb with different results Boot OK but no eth with rk3328-roc-pc.dtb and rk3328-rock64.dtb (I noticed that rk3328-rock6.dtb is the only version that uses the led of my box in the correct blue way in operation and red in standby) Boot OK and eth OK but problems with the usb using the 3 versions rk3328-evb.dtb No boot with rk3328-box-liantong.dtb, nor with the dtb taken in the latest version of libreelec (rk3328-box.dtb) What a misery to find this damn .dtb ... Thank again..

It seems to be system-specific. Pine H64 B + Hirsute: doesn't build. Pine H64 B + Bullseye: doesn't build. Pine H64 B + Focal: builds, doesn't install OPiPC + Hirsute: builds. OPiPC+ + Bullseye: builds. (All sunxi-dev) EDIT: Rock64 + Bullseye: doesn't build. (dev as well)

Hi, New here and new to Linux / Terminal so please be gentle. I've installed Armbian (Armbian_20.11.6_Rockpro64_focal_current_5.9.14_desktop.img) on my RockPro64... liking it so far. Issue I have is I cannot eject media from the File Manager GUI. This applies to USB thumb drives and also CDR/DVD drive. Error message reads as follows: Failed to eject “15 GB Volume”. Error ejecting /dev/sda: Error spawning command-line ‘eject’/dev/sda”: Failed to execute child process “eject” (No such file or directory) (g-exec-error-quark, 8). Incidently I have a vague memory of this being an issue when I tested Armbian on a Rock64 board at some point in the past. Any help greatfully received. Thanks

Hi, I’m running Armbian 20.11 on a RockPro64. I have a Dell DW316 CD/DVD drive and would like to use it to burn data CDs, however so far I have not been able to get it to work. I have tried to burn using Brasero, KD3 and others but no luck. The Brasero log mentioned something about ‘adapter’ error but have tried a different USB cable. I was having an issue with ejecting media in the GUI with Armbian but managed to fix that but makes no difference for this (https://forum.armbian.com/topic/16863-failed-to-eject-media-warning/?tab=comments#comment-117961). The Drive makes a whirling noise for a few seconds then stops and does that repeatedly until disconnected. Sometimes it will recognise CDs eventually and sometimes not. I note that the USB3.0 sockets on the Rock64 and RockPro64 have never worked with Armbian… could it be a power issue? The drive works with Brasero on a RaspberryPi2b running Ubuntu Mate so don’t think it is a hardware issue. Thanks