eselarm
Members-
Posts
366 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
How you can help test upcoming Armbian 26.02 images?
eselarm replied to Igor's topic in Advanced users - Development
Armbian_26.2.1_Rock-3a_trixie_current_6.18.8_minimal.img.xz (ROCK3A) - system has NVME inserted and SATA M.2 E-key adaptor where HDD is connected to - SPI has Armbian legacy U-Boot, but that is skipped as SD-card with new image is inserted - further only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - NVME is available (but OS is running from SD-card for the test) - SATA is not available as not supported mainline based kernel (and needs adding overlay manually when vendor kernel) - reboot does not reboot (but 'echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger' works) - also poweroff is only shutdown, no powerdown (and HDD keeps also spinning) -
How you can help test upcoming Armbian 26.02 images?
eselarm replied to Igor's topic in Advanced users - Development
Armbian_26.2.1_Bananapi_trixie_current_6.12.68_minimal.img.xz (Bananapi M1) - only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - then connecting a SATA SSD ('hotplug'), pops up in dmesg, so recognized OK -
Rock 5b, 16Gb: after some runtime the network hangs
eselarm replied to rolsch's topic in Radxa Rock 5B
I would first check the link, what is on the other side, etc. Also do a flood ping with large enough packages. Or UDP flood, not sure how to do that. Iperf3 might be easier. I have no clue about Radxa OS, never really used it. Maybe also do test boot with mainline based kernel, 6.19 edge I think. And what U-Boot version is used. I use Tianocore EDK2 UEFI v1.1, that might also have effect. -
Rock 5b, 16Gb: after some runtime the network hangs
eselarm replied to rolsch's topic in Radxa Rock 5B
already in the first dmesg part I see: [54475.779558] r8169 0004:41:00.0 eth0: Link is Down [54479.115749] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [54479.115748] r8169 0004:41:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control off [55390.928391] br-ce724241dce3: port 1(veth1664549) entered disabled state [55390.928949] veth6932af4: renamed from eth0 [55391.020157] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.021811] device veth1664549 left promiscuous mode [55391.021831] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.493933] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.493954] br-ce724241dce3: port 1(veth1a65439) entered disabled state [55391.494085] device veth1a65439 entered promiscuous mode [55391.500502] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.500519] br-ce724241dce3: port 1(veth1a65439) entered forwarding state [55391.539757] eth0: renamed from vethb9b9ca0 [55391.561925] IPv6: ADDRCONF(NETDEV_CHANGE): veth1a65439: link becomes ready Which means to me that you use containers/docker or so and something on that networking level goes wrong. I think it had nothing specifically to do with Armbian nor ROCK5B. You should figure out what is running on your computer and what is done to networking in general. I do not use containers like seems to be done here, so cannot really help here. I have no clue about your networking setup and plans. I use various bridges and VLANs on my ROCK5B (Armbian Trixie), but all strict manually done by myself, only own files in /etc/NetworkManager/system-connections/ -
A month ago when doing test boots and power measurements, see I discovered that when using the RPL 27W 'Pi5' PSU, the NanoPi-R6C with the indicated bootloader(s) and kernel(s) sticks to 5V. But when using a 45W USB-C PD PSU from a HP laptop or 60W USB-C PD PSU white-label, switch is made I saw on a USB-C PD power measurement device that was also in the chain. More detailed USB-C PD protocol analysis seems to be needed in order to figure out what happens. One could guess 3A is requested at highest possible voltage as with the 45W PSU, I saw 15V. 9V or 12V would also be OK, but the PD handler cannot be 100% sure I think, depends also what is inserted in USB type-A ports on device etc.
-
That is the correct one. Then I do not know anymore why yours does not work with recent Armbian images/installation.
-
Which microUSB connector of the bananapi do you use for powering the bananapi itsef?
-
How do you power the bananapi m1? It has 2 microUSB connectors.
-
You can check the .DTB files on the bootfs (FAT32) 1st partition. AFAIK the Pi500 uses a D0 variant of the SoC and that needs a separate/dedicated .dts (when downstream kernel what Armbian also uses). When upstream kernel, make sure you have the very latest, as even in 6.18.0-rc? (or 6.19.0-rc? dont remember) I saw some fix w.r.t. naming w.r.t. that D0 variant. And also should pair with proper and/or new enough bootloader (the code in EEPROM). Still upstream kernel might lack a lot of functionality, but at least RP1 should work so RJ45 should work.
-
Mine is M1, no plus, so no WiFi. I used the following 2 years ago when I got the SBC: https://fi.mirror.armbian.de/oldarchive/bananapi/archive/Armbian_23.11.1_Bananapi_bookworm_current_6.1.63.img.txt
-
What is this topic about? M3 - it has Allwinner A83T and no SATA on the SoC but added via USB2 see https://banana-pi.org/en/banana-pi-sbcs/51.html M1(+) - it has Allwinner A20 and SATA on the SoC see https://banana-pi.org/en/banana-pi-sbcs/10.html Mine is the latter.
-
Just to note some more: I use none of those images, instead is it in-place upgraded Armbian, originally: root@banlipi:/tmp# grep VERSION /etc/armbian-image-release VERSION=23.11.1 Now Trixie: root@banlipi:/tmp# cat /etc/os-release PRETTY_NAME="Armbian 25.8.1 trixie" NAME="Debian GNU/Linux" VERSION_ID="13" VERSION="13 (trixie)" VERSION_CODENAME=trixie DEBIAN_VERSION_FULL=13.0 ID=debian HOME_URL="https://www.armbian.com/" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" ARMBIAN_PRETTY_NAME="Armbian 25.8.1 trixie" I log some stuff to terminal in my backup script; I see: U-Boot SPL 2024.01-armbian-2024.01-S866c-P7738-Hb9d3-Vf23c-Bb703-R448a (Jun 21 2025 - 02:53:13 +0000) Maybe also good to know, I use extlinux on real HW, grub on KVM root@banlipi:/boot/efi/extlinux# cat extlinux.conf menu title Select the kernel variant DEFAULT default TIMEOUT 80 LABEL default KERNEL zImage INITRD uInitrd FDT sun7i-a20-bananapi.dtb FDTOVERLAYS sun7i-a20-analog-codec.dtbo APPEND root=LABEL=armbianrfs rootwait rw earlyprintk console=ttyS0,115200 But I am not sure how valid the release info is, will need to look at lists files etc and also run update to it is latest Debian 13.3 I think. I just ran apt update && apt full-upgrade and now it is 'latest debian trixie' but I use apt pinning and I see it is too strict and also an error, so os-release not changed It is essentially Debian Trixie armhf up to date with manually written U-Boot and manually copied sunxi kernel.
-
I have this SBC and it is still nice one as it includes LiPo charging/operation and SATA. I changed Armbian OS drastically, such that the raw SD-card as blockdevice/image also runs as KVM on my ROCK3A or RPi4 for example as standard UEFI machine. I have not tested that yet, but done several similar for NanoPi-NEO and some RPi3. Last thing done was use kernel 6.18 as default. Had not tested/connected a SATA recently, so good time to do it now; It works, see below: root@banlipi:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 119.2G 0 disk ├─sda1 8:1 0 512M 0 part └─sda2 8:2 0 118.7G 0 part mmcblk0 179:0 0 59.6G 0 disk ├─mmcblk0p1 179:1 0 256M 0 part /boot/efi ├─mmcblk0p2 179:2 0 6G 0 part /.snapshots │ /local/fsroot │ / ├─mmcblk0p3 179:3 0 1G 0 part [SWAP] └─mmcblk0p4 179:4 0 52.4G 0 part /local/sdata root@banlipi:~# dmesg | grep ata [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [ 0.000000] Memory policy: Data cache writealloc [ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes [ 0.045731] Memory: 859656K/1015868K available (11264K kernel code, 1761K rwdata, 9604K rodata, 1024K init, 377K bss, 53644K reserved, 98304K cma-r eserved, 229436K highmem) [ 0.742930] libata version 3.00 loaded. [ 1.268996] ahci-sunxi 1c18000.sata: supply ahci not found, using dummy regulator [ 1.269351] ahci-sunxi 1c18000.sata: supply phy not found, using dummy regulator [ 1.269470] ahci-sunxi 1c18000.sata: supply target not found, using dummy regulator [ 1.311601] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP [ 1.311632] ahci-sunxi 1c18000.sata: forcing PORTS_IMPL to 0x1 [ 1.311727] ahci-sunxi 1c18000.sata: AHCI vers 0001.0100, 32 command slots, 3 Gbps, platform mode [ 1.311748] ahci-sunxi 1c18000.sata: 1/1 ports implemented (port mask 0x1) [ 1.311762] ahci-sunxi 1c18000.sata: flags: ncq sntf pm led clo only pio slum part ccc [ 1.316206] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 34 lpm-pol 0 [ 1.630949] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 1.632905] ata1.00: ATA-9: SanDisk SDSSDP128G, 1.0.0, max UDMA/133 [ 1.632934] ata1.00: 250069680 sectors, multi 1: LBA48 NCQ (depth 32) [ 1.633567] ata1.00: configured for UDMA/133 [ 11.515496] systemd[1]: Expecting device dev-disk-by\x2dlabel-sdata.device - /dev/disk/by-label/sdata... [ 22.764093] BTRFS: device label sdata devid 1 transid 36 /dev/mmcblk0p4 (179:4) scanned by mount (378) [ 23.002238] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck. root@banlipi:~# uname -a Linux banlipi 6.18.2-edge-sunxi #1 SMP Thu Dec 18 13:03:43 UTC 2025 armv7l GNU/Linux root@banlipi:~# cd /tmp root@banlipi:/tmp# mkdir 1 2 root@banlipi:/tmp# mount /dev/sda1 1 root@banlipi:/tmp# mount /dev/sda2 2 -osubvolid=0 root@banlipi:/tmp# ddrescue -f /dev/sda /dev/null GNU ddrescue 1.29 Press Ctrl-C to interrupt ipos: 1731 MB, non-trimmed: 0 B, current rate: 75366 kB/s opos: 1731 MB, non-scraped: 0 B, average rate: 133 MB/s non-tried: 126304 MB, bad-sector: 0 B, error rate: 0 B/s rescued: 1731 MB, bad areas: 0, run time: 12s pct rescued: 1.35%, read errors: 0, remaining time: 15m time since last successful read: n/a Copying non-tried blocks... Pass 1 (forwards)^C Interrupted by user So I can browse the filesystems on the SSD, seems I had used it for conversion of RPi Trixie Ext4 to Btrfs. Raw speed is fine I see. So I still can use it also with large 3.5inch HDDs, that is what I prepared the surrounding 12V powersupply for.
-
ssh missfire on bpi-m5 noble
eselarm replied to gene1934's topic in Software, Applications, Userspace
I stopped using netplan and its extra yaml layer on top of NetworkManager or systemd-networkd. I have a handful of VLANs (and several managed switches and cables in- and outside the house and also bridges 'on top' of those VLANs and USB/4G/WiFi as well. Several ISP's also use VLANs, so a must to have that working properly. It all works fine based on only NetworkManager essentially, but if needed I would do direct setup with ip tool. I have also Opensuse, that does not use netplan, but works simply by exchanging .nmconnection files with Debian. No new study or testing for days/weeks/months. Not Ubuntu because of that netplan and it generates .nmconnection files, so overwriting your own. The problem is, NetworkManager package in Ubuntu has a dependency on netplan.io package. So if you purge netplan.io , also NetworkManager is removed. This is not the case in Debian, hence Ubuntu again after 5 years when they also introduced could-init, turns out to be a PITA and simply waste of time for me. So for example for my ROCK3A (similar to your BPI-M5), I just threw away the Armbian Noble install and cloned Armbian Bookworm from NanoPi-R6C and later upgraded in-place to Trixie. Same networking, very little effort, almost unattended. As a sort of sick joke (for experienced home Linux users at least), also RPL put netplan and cloud-init as default in their images. There are several hacks/tweaks/workarounds on that forum. Even more because also many RPi users still use ifupdown and interfaces file (and dhcpcd based although not needed for static). Maybe have a look to see what could be best for you. I basically removed/blocked additional package sources lists, so I get the same on ARM as on x86-64. But note that that is for servers based, pure client computing should work out of the box if you have standard/average/common router, like ISP's 'give you'. If not, lot's own work to do as you see, but not Armbian specific, just home networking and router maintenance. So maybe think about hostnames and IP addressing in your home. I have own router (own software, Linux based) for more than 2 decades basically, so easy to keep a list of MACaddresses/computers, although I still have a simple spreadsheet as a sort of design philosophy/overview. You can reserve/fix MACaddress+IPaddress in dd-wrt, so then all client computer DHCP based tools should be no issues. Else you get a mess as you see. I have setup some dev/test environment based on a physical PCIe with RTL chipset ethernet port for systemd-networkd in combination with managed ethernet switches, but first trial locked up a certain VLAN (something in the switch I think). That was 3 monhts ago and not sure if I continue with it. It means more reading the long systemd-networkd docs, it seems not worth the effort when I compare with NM and its nmtui tool. You might also have silently installed a firewall package. firewalld defaults to public zone, that blocks incoming ssh. I experienced that some time ago on 1 computer with rolling release Linux distro, so that overwrites things every now and then when a fundamental upgrade of a certain part, but noted/warned in changelogs. -
ssh missfire on bpi-m5 noble
eselarm replied to gene1934's topic in Software, Applications, Userspace
Network is down: 2: end0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 All instances I could find. I think your own networking methods conflict with what is common nowadays and also might be reason ssh server is not even running or depending on a pseudo random situation. Same as for other topic where you could not reach armbian repo server.
