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.

https://docs.armbian.com/User-Guide_Fine-Tuning/#how-to-toggle-verbose-boot

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.

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.

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?