Thanks for providing info, but I have one question to you: Why do you install SSH server with tasksel? It’s built into the Armbian image, so I think no need to do that. The second thing about removing jessie scripts: I need to find out (maybe with you) which packages are needed and not needed. Maybe there’s in the future a new really clean image with an updated kernel.
I have only bananapi-R1 … no other HW from this AllWiner family… then I am able to test only R1.
I want to be sure the openssh server is installed with all dependencies. Debian is little bit new for me, I used Debian before 10+ years It is possible this step is useless, but for sure
If you want to move next : apt install armbian-firmware linux-dtb-current-sunxi linux-headers-current-sunxi linux-image-current-sunxi
Without uboot created to current is still old “next” kernel used. And there is a armbian problem, linux-u-boot-current-bananapi_19.11.3_armhf.deb has a bad singature/size as is reported in repo. You need it download it manually with wget, or curl :
apt install /pathtopackage/linux-u-boot-current-bananapi_19.11.3_armhf.deb
Then u-boot for NEXT kernel is removed…
After reboot you are able to remove : apt --purge remove linux-dtb-next-sunxi linux-headers-next-sunxi linux-image-next-sunxi
Please install hostapd-realtek instead of hostapd
Last note … your image missing configuration for ondemand cpu governor. Please add nano /etc/default/cpufrequtils
clean Debian kernel is few years behind Armbian. Not using Armbian kernel is shooting into the foot. If there would be fixes it would be implemented into the Armbian kernel years ago.
if you would read what people before you discovered you would not waste time with irrelevant things in user space. Change Armbian for Debian or Ubuntu or OpenWRT or Arch or whatever will lead into the same problem which is somewhere in the area where kernel talks with hardware. In most cases this is the one and only implementation of those two critical components:
Both are at most cheap and are not well supported in Linux kernel. Armbian only apply fixes to that implementation, but if the core is totally fucked up, its hard to fix or represent serious investment which is out of the question to cover.
Since I don’t pay attention anymore, things could be better, but certainly not in kernel 4.19.y or around. And certainly not in a kernel that comes with a generic distribution such as Debian. Stop wasting time and start reading where people left and understand the reason why Armbian community (!!!) which is nothing else but Debian for ARM, same folks, just dealing with ARM boards and contribute to the same code … does not waste time for this hardware anymore
… if you want to do some progress. Sorry for being harsh.
I think you’re right. I will stop imaging. I hope we have some better Linux images in the future… It’s a shame. It’s difficult to program because of the ethernet switch. It’s not physicially seperated, that’s a huge problem. The swconfig disappeared in new distributions, that’s a problem too. Maybe I can find another way and image that. Thank you for your command!
this was first what I read Your document and armbian forum about R1 was a first place what I studied for a long time before I started try to use debian like OS on my BPI-R1. This documents, kernel documentation for dsa switch with this chipset and networking/dsa/dsa.txt from kernel, etc …
Igor is right with this HW, by his unpolite way But my expectation about OS installed on R1 seems to be different as for others. I don’t want to use wifi/AP, or switch extended function. I wan’t to keep switch as a ‘non managed in one vlan’ with port8/eth0 enabled. What I want is stable kernel running on HDD with some IOT and ansible scripts with a lot of logs
Then there can be way to use old kernel with disabled features. Or not. This and short support cycle of Fedora are a main reasons why I am trying to use Debina/Armbian.