jofland

http://tron.dyn.cc/sun7i-bananpro-ahci.dts
download my test user overlay, copy it to your system and activate it (as root) with:
armbian-add-overlay sun7i-bananpro-ahci.dts this should work on any kernel below 5.17
after release of 22.05 you need to remove it from /boot/overlay-user/
 

Hello everyone!
 
I would like to express my deepest gratitude to Dieter for the great work he has done to find out the cause of the problem.
I had a similar problem. And I confirm that in the above way you can revive the work of BananaPi Pro
 
So:
1) you need to remove the MicroSD and in any Linux system (for example, by booting from Ubuntu-LifeCD or other), edit the file /boot/armbianEnv.txt, specifying the correct UUID of our MicroSD to the rootdev parameter. It is better not to remove the value for loading from HDD/SDD, but to comment it out
For example:
##/mmcblk0/mmcblk0p1 #rootdev=UUID=2027b0d6-b106-4f62-b4ea-6280cdcf0a23 ##/dev/sda1 rootdev=UUID=8204db71-090a-44b5-84cb-dd55d9110fed 2) insert MicroSD back and start. We enter the system and launch the command "armbian-config", select "Systems" -> "DTC" from the menu.
2a) DO NOT REPEAT. First I tried in the "ahci-5v" section to change the ""status =" disabled "" parameter to ""status ="enabled "". Rebooted but it didn't help. Returned the parameter back.
2b) look for the "sata@1c18000" section and delete the line "target-supply = <0x24>;" in it. To the request to save the answers "Y", to the request to overwrite the file - we also confirm "Y" and reboot.
3) After rebooting, the "lsblk" command will already show our HDD/SSD available.
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT sda           8:0    0  55,9G  0 disk └─sda1        8:1    0  55,9G  0 part / mmcblk0     179:0    0   7,5G  0 disk └─mmcblk0p1 179:1    0   7,4G  0 part /media/mmcboot zram0       254:0    0 483,7M  0 disk [SWAP] 4) Again edit the file /boot/armbianEnv.txt, uncommenting the "rootdev" parameter for the UUID of our HDD/SDD and commenting it out for MicroSD.
5) Reboot and enjoy again the work of our BananaPi Pro. When updating the kernel, you will have to repeat everything again. Maybe if, after the update, you immediately edit the dtc and then reboot, then the problem will not be reproduced.
 
I express my gratitude to everyone who unsubscribed in this thread - thanks to you, I was able not to freak out and delete all my data, but to restore the performance of my system. I think it would be a good idea to solidify this topic so that other colleagues can quickly find it and restore their devices to work. But I would like the developers to fix this. Thank you for a good product, albeit with problems.
 
Good luck to all!

I solved it by my own:
 
I had to mount the boot directory of the sd card over the boot directory of the ssd. Therefore I added two lines to the /etc/fstab of my ssd:
 
/dev/mmcblk0p1  /media/mmcboot           ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0       1
/media/mmcboot/boot  /boot           none    bind
 
(had to create the directory /media/mmcboot first)
 
Now the kernel loads in the right version. Kernel update works. Topic can be closed.
 
 
Some information:
 
root@pi-nas:~# uname -a
Linux pi-nas 5.10.34-sunxi #21.05.1 SMP Thu May 6 20:13:21 UTC 2021 armv7l GNU/Linux

root@pi-nas:~# ls /boot
armbianEnv.txt                  boot.scr.bak              System.map-5.10.34-sunxi
armbian_first_run.txt.template  config-5.10.34-sunxi      uInitrd
boot.bmp                        dtb                       uInitrd-5.10.34-sunxi
boot.cmd                        dtb-5.10.34-sunxi         vmlinuz-5.10.34-sunxi
boot.cmd.bak                    dtb-5.4.20-sunxi          zImage
boot-desktop.png                initrd.img-5.10.34-sunxi
boot.scr                        overlay-user

root@pi-nas:~# mount | grep boot
/dev/mmcblk0p1 on /media/mmcboot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,x-gvfs-hide)
/dev/mmcblk0p1 on /boot type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600)