Myron

@TRS-80 Thank-you for the advise. @teknoid Thank-you for the pointer to the accepted pull request.

I'll stick with the system default. I was not sure if fstrim was being invoked on a schedule at the time.

I changed it to 24 hour intervals, out of curiosity and the result was ... /: 693.2 MiB (726855680 bytes) trimmed on /dev/mmcblk0p1 I think this is configured to do this this once per week via systemd, but I'm not sure if this is working hence creating a cron task. Looks like it is. I will wait for 4 days and look as /var/log/syslog. root@loki:/usr/lib/systemd/system# systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Mon 2022-03-21 14:20:12 GMT; 1 weeks 3 days ago Trigger: Mon 2022-04-04 00:00:00 BST; 3 days left Triggers: ● fstrim.service Docs: man:fstrim Thanks for your technical wisdom. 🙂

If possible you could try and login through the serial console (you'll need a USB to RS232 adapter) and configure SSHD that way. I had to do the same recently when I managed to mess-up SSHD's configuration recently. Not sure why your keyboard is not being recognised.

Nope. I didn't. My knowledge of the Linux Kernel is not that deep. I've got, at least, the analog-codec up-and-running. 🙂 The rest is on indefinite hold.

Is every 6 hours a good interval to fstrim an SD card? Is it safe for the SD card to be TRIMed often? I know that SD card trimming is not like TRIM on an SSD, but the operation performed on a SD card that supports CMD38 performs a similar function, to tell the SD card which pages do not contain valid data.

How would one get the proper kernel and userland environment on the board without starting from the beginning, or is that not possible? I think that would be a question for any Armbian user who's built from trunk and would wish to return to a supported build without undoing all the customisations? The trunk user compiled Armbian build is already on 22.05.

@teknoidI've for one of these BananaPi Pro boards, but I don't have the knowledge or expertise to be a maintainer. Currently jittery about updating the kernel as the last upgrade from 5.15.27 to 5.15.28 resulted in the board failing to getting "Starting Kernel ..." and this is with verbosity=7 set. Something's not right at the moment with the installed Linux so as I've type now I've got ./compile.sh compiling a U-Boot and kernel which will be version 5.15.30 when it's complete. Issue I've got is that all the laptops I've got are Windows. Unfortunately a necessity. Got one laptop which I may be able to install native Linux on it and can then use it to diagnose a non-starting BananaPi Pro. Will these patches and updates be available via the trunk builds? I do not know how that works. That's the route I took to keep my Banana Pro up-to-date.

@emk2203 What happens when you try login through the serial console? (aka. /dev/ttyS0) Why try this? Try find out if your OPi Zero is actually accepting any logins. Once you've got a # prompt over the serial connection, you can start diagnosing the SSH issue. Might be as simple as re-installing the SSH daemon with out-of-the-box settings. Also, any chance you have a firewall blocking access? There are my guesses. Werner is right that there is insufficient information to try and help you at this moment in time.

@teknoid To apply to be a board maintainer please visit this page:

@teknoid Please do make a pull request. I was thinking of attaching a SATA drive, didn't know it would not have worked and device trees are an absolute and complete mystery to me.

An update: I opted to install a previously built Armbian_22.05.0-trunk_Bananapipro_focal_current_5.15.27.img image which worked, but starting for near scratch, re-installing packages and copying previous configurations from /etc on SD card that won't boot. (A whole heap easier to get core services up and working quicker than with windows.) Does anyone know how to quickly back-up the Kernel before applying an update? I'm guessing here, but I think copying the /boot directory to another name on the root directory is enough and if an upgrade fails, put SD card in another computer, erase /boot and rename the backed up directory back to /boot ? Any takers for this puzzle and problem?

Moved to P2P help.

Ok. :-( What I've quoted in the first message is as much verbosity as I'm going to get. Is there any way to revert to the previous kernel or is this me creating a brand new installation on another 32Gb SD card, copying all the custom configurations across from old card and never upgrading the kernel again without a full sector-by-sector SD card backup? Sort of resigning myself to starting nearly from scratch, but there has got to be some way to rewinding the kernel to the previous working version? Anyone on the forum got the expertise and knowledge they can share on how to do to this that they can share with this community? PS: I can interrupt the U-boot start-up and get to the U-boot command line, if the answer lies somewhere in there.

Verbosity is already at 7, but will try create /boot/.force-verbose. Thanks for the hint, @Werner I think what may have happened is that apt upgrade took an Armbian update that also updated the Kernel, I didn't spot that and I use the Armbian Build framework to compile the latest 5.15.y Kernel. Installed the dtb and image as you instructed me to (as being mandatory for a kernel update) and then after a reboot it all went south. Luckily I have a backup of a working image from the beginning of Feburary so that's going on a spare 32Gb MicroSD card and then I have to remember what alterations I did since then. This is the first time a simple Kernel update had gone south and looking at the Internet's threat reports, I'm going to have to update the Kernel to the latest again because of some nasty CVEs that have been reported. Still, there has got to be some way to revert the Kernel to a previous version when using U-Boot and not GRUB or is it really the case of always back-up the SD card before a Kernel update as there might not be a way of reinstalling the Kernel? I would still like to learn how to fix the now broken installation. I'll have a fully working SBC soon and can plug in the non-booting MicroSD card into a reader and sticking that in the SBC's USB port then I have Linux tools available to try and solve the issue. If all of this is possible them my contribution to the Armbian community would be to write a guide on how to rollback a Kernel update on a non-starting SBC.

It's finally happened to me. :-( Compiled Kernel 5.15.28 using the Armbian Build Framework. The two commands issued to update the SBC's kernel were: sudo dpkg -i linux-dtb-current-sunxi_22.05.0-trunk_armhf.deb sudo dpkg -i linux-image-current-sunxi_22.05.0-trunk_armhf.deb Rebooted the SBC and now it's stuck. Serial console shows the output quoted below and then goes no further. I have a Windows 10 system with Paragon Software's Linux File System for Windows driver so I can access the SD card and alter its contents. I updated the Kernel as has a suspected issue which may have turned out not to be the case. The question is how do I revert back to the previous kernel and dtb. To me it seems simple, but I'm prettu sure there are gotyas. I do have the Armbian Firmware build deb files with Kernel version 5.15.27. Can anyone help me with this situation? I'm just not sure about the procedure to fix this problem. U-Boot SPL 2021.07-armbian (Sep 13 2021 - 23:19:26 +0200) DRAM: 1024 MiB CPU: 912000000Hz, AXI/AHB/APB: 3/2/2 Trying to boot from MMC1 U-Boot 2021.07-armbian (Sep 13 2021 - 23:19:26 +0200) Allwinner Technology CPU: Allwinner A20 (SUN7I) Model: LeMaker Banana Pro I2C: ready DRAM: 1 GiB MMC: mmc@1c0f000: 0, mmc@1c12000: 2 Loading Environment from FAT... Unable to use mmc 0:1... Setting up a 720x576i composite-pal console (overscan 32x20) In: serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@1c50000 230454 bytes read in 17 ms (12.9 MiB/s) starting USB... Bus usb@1c14000: USB EHCI 1.00 Bus usb@1c14400: USB OHCI 1.0 Bus usb@1c1c000: USB EHCI 1.00 Bus usb@1c1c400: USB OHCI 1.0 scanning bus usb@1c14000 for devices... 1 USB Device(s) found scanning bus usb@1c14400 for devices... 1 USB Device(s) found scanning bus usb@1c1c000 for devices... 1 USB Device(s) found scanning bus usb@1c1c400 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Autoboot in 1 seconds, press <Space> to stop switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3964 bytes read in 4 ms (967.8 KiB/s) ## Executing script at 43100000 U-boot loaded from SD Boot script loaded from mmc 225 bytes read in 4 ms (54.7 KiB/s) 11391806 bytes read in 630 ms (17.2 MiB/s) 8305768 bytes read in 459 ms (17.3 MiB/s) Found mainline kernel configuration 41126 bytes read in 15 ms (2.6 MiB/s) 267 bytes read in 10 ms (25.4 KiB/s) Applying kernel provided DT overlay sun7i-a20-analog-codec.dtbo 5532 bytes read in 10 ms (540 KiB/s) Applying kernel provided DT fixup script (sun7i-a20-fixup.scr) ## Executing script at 45000000 Kernel image @ 0x42000000 [ 0x000000 - 0x7ebc68 ] ## Loading init Ramdisk from Legacy Image at 43400000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11391742 Bytes = 10.9 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 EHCI failed to shut down host controller. Loading Ramdisk to 49522000, end 49fff2fe ... OK Loading Device Tree to 494af000, end 49521fff ... OK Starting kernel ... Any assistance would be greatly welcomed.

This may help you: https://www.systutorials.com/change-systemd-boot-target-linux/

Please provide more information. For example, the make and model of the SBC you are using. Have you tried to compile the Linux Firmware using the Armbian build framework? ( https://docs.armbian.com/Developer-Guide_Build-Preparation/ )

Welcome to the community @Ukhellfire. Any help is welcome.

For anyone visiting this thread, the issue was fixed when I moved to Kernel version 5.15.y.

@54ik1, What board have you got? Generally on the GPIO pins you'll have UART0 available for this. Quite some time ago I was in a similar situation you're in now. Have a read of https://forum.armbian.com/topic/18916-ambian-fails-before-the-first-hurdle-refuses-to-boot-on-banana-pro-soc-board/ as it should guide you towards how I got to diagnose a BananaPi Pro that appeared to refuse to start-up for an initial install. If you need any additional help, I'm willing to try to help you.

Can you provide the compile logs? Found in ./build/debug/ That would the first place to identify the issue. Also, before you do that I would advise that you clone the build framework again and try again. I had a similar problem recently where compilation failed for my own board. Cloning the build framework fixed the problem.

orangepipc, orangepipc2 and orangepiplus are located within the Show CSC/WIP/EOL menu boards menu within the build script. How to build an image is located within the Armbian documentation.

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. :-)