Myron

Currently your donations only covers electricity for building images so you are very far away.

I am sure donate button is easy to find and when donation(s) comes on the levels that we will be able to hire people that will support you, then we will proceed. Until then, we are forced to drop support in order to maintain sanity and contact with our families.

solved with https://github.com/armbian/build/pull/3613
thanks @the-going

Previous estimate I totally pulled from my rear end, because I have no idea. 
 
But sounds like maybe a little more often than I was thinking.  Probably whatever system default is doing is likely fine, unless you really know what you are doing and/or have some reason for changing it?

Sounds way too frequent to me.  Unless you are maybe constantly writing to it or something.  In which case you should use something more robust like the sort of (industrial, expensive) hardware they recommend for ZFS cache.
 
In normal usage I would think like twice a year (or quarterly, monthly?) maybe, I dunno.  Why do you think you need to do it so often?
 
 
Yes and a lot of info out there on the Internet about trimming SSD are out of date.  In most cases all that is done automatically now.  As you point out though, I am not sure how this works on flash devices.

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!

So this is a 64GB Samsung. EVO, EVO+, Pro or Pro+? Anyway there's still the 1% reserve present and this is not 'the average' SD card but Samsungs all contain rather good controllers and NAND dies.
 
Regarding 'reserve sectors' and overprovisioning: If a card claims it's n bytes in capacity it has internally a larger capacity. This is used as reserve (if the controller detects bad sectors, then reserve sectors are mapped in) and to allow somewhat ok-ish write performance when the card gets full. On flash media you can't overwrite directly, it's always a very time consuming read/delete/write cycle, the number a flash cell can be written to is determined by the count of program/erase (P/E) cycles it is designed for, the controller has to take care of this so that all flash cells wear out equally (wear leveling).
 
Since the controller has no idea which sectors contain real data and which not (there's no TRIM support for SD cards) as soon as you completely fill the card once (all space partitioned) from now on the controller considers every sector containing useful data (even if you deleted the data in the meantime -- since there's no TRIM support the controller doesn't know what's empty or not, from now on the whole capacity is considered in use). Now only the 'reserve sectors' are available to perform read/delete/write cycles and if this amount of sectors is small things slow down a lot on average SD cards (not those more recent Samsung).
 
Just check articles explaining SSDs and keep in mind that SD cards behave like crappy SSDs from a decade ago containing slow/primitive controllers and do not support TRIM.
 
BTW: This is the only great use case for SD Association's 'SD Formatter'. This tool is used to format SD cards appropriately (partitions it while choosing the 'correct' file system which is either FAT or exFAT) which obviously is pretty useless from Armbian's perspective since burning an OS image as next step both overwrites the partition table and the filesystems present before. So why using SD Formatter in the first place? Since this tool implements ERASE CMD38. It tells the card's controller that every sector/block of the card does not contain any real data any more and can be considered empty. On 'the average' SD card this also might restore horribly low performance back to 'factory default' performance. But more recent SD card controllers especially when paired with many reserve sectors aren't that much affected.
 
With Armbian's auto resize behaviour leaving at least 1% unpartitioned all that's happening in the background is that we ensure there are more sectors available for the controller's housekeeping which prevents older cards from becoming slow like hell as soon as they've been 'filled completely'.
 
Edit: A small note regarding 'SD cards don't support TRIM'. The SD protocol defines a block erase command and tools like fstrim are supposed to do the job. Whether your kernel + SD card combination supports that or not a simple 'sudo fstrim -v /' might tell. Whether this has the desired effect or not is a different question though (see this attempt to test this -- I'm not sure whether the method is sufficient since the point of marking data segments as already erased should not involve overwriting them, it's just that the SD card's controller knows that specific sectors/pages can be added to the wear level pool since marked 'emtpy' now)

I know, I already hired for nanopi neo plus2 🙂
https://www.armbian.com/nanopi-neo-plus2/

dpkg -i linux-dtb-current-sunxi_22.02.0-trunk_armhf.deb dpkg -i linux-image-current-sunxi_22.02.0-trunk_armhf.deb
This is mandatory, the rest optional.

I suggest watching here to stay up to date what has changed: https://github.com/armbian/build/commits/master

And in each SoC subforum (Allwinner A10/A20, Allwinner H2/H3, etc.) we could create a pinned locked thread named like "List of boards supported in this subforum" to improve navigation.

Here are a few hints how to tweak journal: https://askubuntu.com/questions/1238214/big-var-log-journal

I wonder if this may help from a u-boot cheat sheet I found at http://nerveware.org/u-boot-cheat-sheet/1.html
 
Boot into single user mode Single user mode is mostly used to reset forgotten passwords, but the command below might be usefull for debug purposes as well (omit init). U-Boot > setenv bootargs "${bootargs} reboot=cold,hard emergency init=/bin/sh" For embedded devices, the root partition is frequently mounted read only. $ mount -t proc none /proc $ mount -o remount,rw / $ passwd root Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully $ sync  
I am guessing that to do this you will need to connect a RS232 to TTL UART board to the debug serial port on the board to get to the U-Boot command prompt. I've yet tried this method on my board, but I have got myself to the U-Boot>_ prompt.

That's what I would do. If I found something then I certainly would contribute back to Armbian. The more I learn and remember (and getting helped along the way) then I can return the favour and help others with what I've learned.  I think I'll try get involved more with the Forums as so far, at least for me, the Armbian Distro on the BananaPi Pro is rock-solid reliable.
 
I now brave applying the compiled 22.02.0 version to the BPi Pro and, yes, I've performed a sector-by-sector backup of the present stable installation.  (Wish me luck....)
 
ADDITION: YAY! Kernel 5.10.95-sunix installed and working.  :-)

Thank-you @lanefu. Your pointer to a solution worked, but it took some time for me to learn how to do this.  Finally came across this one page that explained how to automount a share using systemd.
https://anteru.net/blog/2019/automatic-mounts-using-systemd/
 
This worked for me:
root@loki:/etc/systemd/system# cat zeus-raspi.mount [Unit] Description=/zeus/raspi [Mount] What=//192.168.0.160/raspi Where=/zeus/raspi Type=cifs Options=rw,auto,uid=1001,gid=1002,file_mode=0755,dir_mode=0755,vers=3,credentials=/etc/.smbcredentials_raspi_01 DirectoryMode=0755 [Install] WantedBy=multi-user.target ----- root@loki:/etc/systemd/system# cat zeus-raspi.automount [Unit] Description=/zeus/raspi [Automount] Where=/zeus/raspi [Install] WantedBy=multi-user.target  

Any thing related Allwinner A20 SOC will go to "Allwinner A20 Forum section" 

Took a quick look on my system doing that.
 
Doing "systemctl status", I don't see any obvious services that were started or stopped.
 
You might learn more reading up on the options in the NetworkManager command line tool:
 
$ man nmcli  
Or check with the XFCE guys over at https://forum.xfce.org/ what exactly that network widget does.

I should have paid attention to what I did, but when the USB to TTL serial adapter arrived I promptly connected that and got the initial console and set-up which allows me to login as root and 1234, to then change the password and ask all the usual initial set-up questions.  Once I got past all of that then everything magically started working, including the HDMI port.  Without using the USB to TTL RS232 card on the debug port on the BananaPro, the SoC board appeared to be dead.  It was not.  I've got it working now.  [Just need to create an image back-up of the MicroSD card.

https://forum.armbian.com/index.php?/topic/3945-mmc-no-card-present-error-on-allwinner-boards
 

Thank-you everyone. I would mark multiple solutions, but the board only allows me to mark one.

I got it working. Used the cron @reboot method on user root.  The LEDs are useful where on the screen it may look like it's got stuck, the LEDs will at least show if there is some activity and if the SOC is still got a heartbeat.  I'm still a noob on the higher technical issues of Linux.  I have one more question to ask and that will be in another thread.    (Yes, I will donate!  I've seen the donate link on the Armbian home page, but as you all know, the budget that keeps the roof over the head, electricity supplied, food on the table, etc... is priority. Shall donate what I can, when I can.)
 
EDIT: I finally ended up using the /etc/rc.local method.  Thank-you @Werner and @guidol.

I usually do the noob way finding the trigger files for LEDs
code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } du -a /sys | grep led | grep trigger
 
I don't know what trigger is needed for mmc but heartbeat is self-explaining. code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } echo heartbeat > trigger
 
 

Pssst ... If you cat the trigger file, it'll tell you the valid options, and which one is currently selected.
 
tparys@laptop:~$ cat /sys/class/leds/input4\:\:capslock/trigger none usb-gadget usb-host rfkill-any rfkill-none kbd-scrolllock kbd-numlock [kbd-capslock] kbd-kanalock kbd-shiftlock kbd-altgrlock kbd-ctrllock kbd-altlock kbd-shiftllock kbd-shiftrlock kbd-ctrlllock kbd-ctrlrlock ACAD-online BAT0-charging-or-full BAT0-charging BAT0-full BAT0-charging-blink-full-solid disk-activity disk-read disk-write ide-disk mtd nand-disk cpu cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 panic mmc0 rfkill0 phy0rx phy0tx phy0assoc phy0radio rfkill1 audio-mute audio-micmute  
I'd wager the correct trigger is "mmc0", unless there's a both a SD card and eMMC slot on that board?

on my BananaPi M1 I can only control the green LED, but for that usage I do use the following command-line:
echo 'mmc0' > /sys/class/leds/bananapi:green:usr/trigger only green LED available: # ls -l /sys/class/leds/ lrwxrwxrwx 1 root root 0 Sep 11 22:11 bananapi:green:usr -> ./../devices/platform/leds/leds/bananapi:green:usr  

FAT partition is not needed, perhaps only for amateur usage. So that people who have Windows, can access this part and change thing. While most of them have no knowledge what to do with those files, so it is pretty irrelevant. FAT partition is there because all those distro tries to mimic Raspberry Pi, while cheap mainstream toy is not our amusement to follow. Raspberry Pi can't boot from anything else due its proprietary construction ...
 
Armbian controls this hardware with a very different modern hardware interface, written from scratch, from the moment you plug the power. There is no relationship with the demo level software you are mention as a working ones. Those were made just to present hardware functions and abandoned right after then. Many years ago. I am sure you don't want to use those and I highly recommend you to stay away from those other (fake) distros.
 
Also make sure to read this.
 

We need to know:

- exact version of boot loader (u-boot) very early print
- armbianmonitor -u (if you have network operational)
- cat cat /etc/armbian-release 
- do you have monitor attached and what kind of
- how do you power the board
 
Helping you is our expense. You can also try asking for support at Lemaker, but I am 100% sure nobody will answer to you. Not at any distro you are mentioning.