Reboot is not working

[alm]

I have an issue with the latest releases since Yammy on a Orange Pi Zero LTS. Reboot is not working (system shuts, but not starting again)

[Werner]

Providing logs with 

armbianmonitor -u

 helps with troubleshooting and significantly raises chances that issue gets addressed.

[alm]

I have experimented with changing kernels and when I install 6.6.16 it is still working.

https://paste.armbian.com/akaceraduc just made with kernel 6.12.20

[alm]

And now loaded with kernel 6.6.16 https://paste.armbian.com/kecigabete which is working

[djurny]

Hi @alm,

You should try with the legacy kernel, 6.6.75. That still has reboot working on my (first gen) Orange pi zero.

Grt,

[Moklev]

The same bug also occurs on the Orange Pi Zero non-LTS board: shutdown instead of reboot (Armbian 25.5.1, kernel 6.12.30).

[alm]

Does anyone know if this will be solved in new releases or should we use an old kernel 6.6.75 as alternative?

Then the next question : can we avoid an update of the kernel when using the apt command upgrade?

 

Already found the solution: Use armbian-config and disable upgrade of firmware

 

Edited June 10 by alm

[kolla]

I have the same problem, and for me it seems unrelated to kernel revisions. I have a whole bunch of Orange Pi Zeros, all running the same kernel and all with the same updated packages. However, the ones that run from old SD cards and have been updated from earlier releases, they reboot fine, while those that running from relatively recently flashed SD cards struggle and halt instead of reboot. Since this is super annoying, I wish to find out what's causing this, so I will do some diffing between the systems to see if I can find the culprit.

[David Cameron - VE7LTD]

I know this is kind of an old thread, but I am having the same issue with the NanoPi Duo2. When I install the latest community build based on 6.12 kernel, the reboot just powers down the unit. I tried the legacy 6.6.75, and this also has the issue. The only way I could restore functionality was by going back to a 6.6.16 kernel build, and disabling kernel updates in armbian-config.

 

There must have been something changed in the way the kernel issues the reboot command that the H3 is not interpreting correctly. If anyone finds a solution such as a kernel argument that fixes this, please share as this will prevent any further kernel updates until fixed.

[TRay]

For the Orange Pi Zero v1, it might be recommended to upgrade U-Boot to version v2025.4.
I remember having similar problems with the Orange Pi Zero 3, and after the U-Boot update, the reboot works correctly and doesn't shut down the computer.

Edited August 13 by TRay

[TRay]

Is anyone using Linux kernel-edge on an Orange Pi Zero v1? Are they kernel versions 6.14 or 6.16? Does that also cause the reboot problem?

[TRay]

While searching the internet for information about the reboot problem, I found this information but I don't know if it is helpful for us?

 

Quote

 

If Armbian with kernel 6.12 isn't rebooting properly, it could be due to a few reasons, including issues with the bootloader, kernel configuration, or filesystem corruption. Try updating Armbian and the bootloader, verify kernel configurations, and check for filesystem errors. 

Here's a more detailed breakdown of potential causes and solutions:

1. Bootloader Issues:

Outdated bootloader:

An outdated U-Boot (the bootloader) might not be compatible with kernel 6.12, causing it to fail during the reboot process.

Incorrect memory addresses:

In some cases, U-Boot might be assigning incorrect memory addresses for the kernel, leading to issues.

Solution:

Update the bootloader (U-Boot) to the latest version, especially if using an older build. Consider checking if the memory addresses for your specific SBC (Single Board Computer) are correctly set in the bootloader's configuration. 

 

 

[going]

2 часа назад, TRay сказал:

If Armbian with kernel 6.12 isn't rebooting properly, it could be due to a few reasons, including issues with the bootloader, kernel configuration, or filesystem corruption. Try updating Armbian and the bootloader, verify kernel configurations, and check for filesystem errors. 

Here's a more detailed breakdown of potential causes and solutions:

1. Bootloader Issues:

Outdated bootloader:

An outdated U-Boot (the bootloader) might not be compatible with kernel 6.12, causing it to fail during the reboot process.

Incorrect memory addresses:

In some cases, U-Boot might be assigning incorrect memory addresses for the kernel, leading to issues.

Solution:

Update the bootloader (U-Boot) to the latest version, especially if using an older build. Consider checking if the memory addresses for your specific SBC (Single Board Computer) are correctly set in the bootloader's configuration. 

Yes, that's right. This is relevant to the issue under discussion.

[going]

12 часов назад, TRay сказал:

recommended to upgrade U-Boot to version v2025.4.

Recommended to upgrade U-Boot to version v2025.07

This version has big changes for allwinner (sunxi) chips. This concerns the initialization of a non-standard size of RAM (1.5; 2.5 GB), downloads from eMMC.....

[going]

2 часа назад, TRay сказал:

Are they kernel versions 6.14 or 6.16?

Today it is EDGE v6.15 no v6.16.

[TRay]

11 minutes ago, going said:

Recommended to upgrade U-Boot to version v2025.07

This version has big changes for allwinner (sunxi) chips. This concerns the initialization of a non-standard size of RAM (1.5; 2.5 GB), downloads from eMMC.....

 

So maybe it would be enough if the community version of U-Boot were updated to version v2025.07 and it would solve the reboot problem for this SBC, just like it happened for the Orange Pi Zero 3 where updating U-Boot to v2025.04 solved the problem of decoding RAM size on the SBC

 

 

[laibsch]

@TRay Best way to find out is to change and recompile your own image, then you will know.  After that, push a PR so everybody can profit from your work.

[TRay]

34 minutes ago, laibsch said:

Best way to find out is to change and recompile your own image, then you will know.  After that, push a PR so everybody can profit from your work.

 

Hi, yes, I agree, but I am only a user of Armbian and I do not have such skills to do this solution you suggest

I can check the available Community Releases of Armbian and check how it works. Community editions, which are issued for testing and updated on average every week?

 

[laibsch]

Compiling your own image may sound dauting but is actually fairly easy.  Help is also available, just ask.

 

https://docs.armbian.com/Developer-Guide_Building-with-Docker/

https://evilolaf.github.io/docupreview/Developer-Guide_Build-Preparation/

https://www.youtube.com/watch?v=kQcEFsXEJEE

[TRay]

It seems that the problem has been under consideration since mid-May, so we are waiting for a bootloader update.

 

https://github.com/armbian/build/issues/8197

 

 

[laibsch]

That issue was just dealt with by disabling cruft instead.

 

If you want to test a newer uboot with a reenabled cruft you will again need to go into building and testing, followed by a PR.

[kolla]

Meanwhile, I upgraded the old rebooting (working) orangepi zero(1)s from U-boot "SPL 2019.04-armbian (Nov 18 2019 - 23:36:05 +0100)" to U-boot "SPL 2024.01-armbian-2024.01-S866c-P6b16-Ha5c2-V367a-Bb703-R448a (Apr 29 2025 - 02:50:09 +0000)" and they also now poweroff on reboot. So the problem is clearly u-boot, and not SD card vendor, kernel (they all run the same "6.12.43-current-sunxi #1 SMP Wed Aug 20 16:30:58 UTC 2025 armv7l") or whatever else. I'll see if I can manage to test U-boot v2025.07...

 

Btw, one thing I noticed with old working boot.cmd/scr was that load_addr was "0x44000000" while it is now "0x45000000" - no idea what significance may have.

Edited September 7 by kolla

[svvolf]

before:

Orange Pi Zero (H+),

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Zero
DRAM:  512 MiB

TF card is Samsung Evo Plus 64GB;
After writing the TF card with Win32DiskImager, the same issue occurred: normal boot-up and shutdown, but when executing a reboot, it gets stuck at the final stage of service termination before restarting.

......
[  OK  ] Reached target shutdown.target - System Shutdown.
[  OK  ] Deactivated swap dev-zram0.swap - /dev/zram0.
[  OK  ] Reached target umount.target - Unmount All Filesystems.
[  OK  ] Reached target final.target - Late Shutdown Services.
[  OK  ] Finished systemd-reboot.service - System Reboot.
[  OK  ] Reached target reboot.target - System Reboot.
[44967.125952] systemd-shutdown[1]: Failed to set timeout to 10min: Invalid argument
systemd-shutdown[1]: Failed to set timeout to 10min: Invalid argument
[44967.761002] reboot: Restarting system

This is where it starts to lose responsiveness!

 

after:
Following someone's guidance, I was told to install or update u-boot: run armbian-install, then selected “Install/Update the bootloader on SD card (/dev/mmcblk0)”. After the update completed, needed to shut down the system and disconnect the power (the first time I performed a reboot here, but it got stuck again at the final stage of stopping services before restarting, just like before). so I had to disconnect the power, then plug it back in for an automatic boot-up. After that, performing a reboot worked normally without getting stuck).

 

......
[  OK  ] Reached target shutdown.target - System Shutdown.
[  OK  ] Deactivated swap dev-zram0.swap - /dev/zram0.
[  OK  ] Reached target umount.target - Unmount All Filesystems.
[  OK  ] Reached target final.target - Late Shutdown Services.
[  OK  ] Finished systemd-reboot.service - System Reboot.
[  OK  ] Reached target reboot.target - System Reboot.
[44967.125952] systemd-shutdown[1]: Failed to set timeout to 10min: Invalid argument
systemd-shutdown[1]: Failed to set timeout to 10min: Invalid argument
[44967.761002] reboot: Restarting system

U-Boot SPL 2024.01-armbian-2024.01-S866c-P7738-Ha5c2-Vd711-Bb703-R448a (Aug 16 2025 - 02:09:48 +0000)
DRAM: 512 MiB
Trying to boot from MMC1
ns16550_serial serial@1c28000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19


U-Boot 2024.01-armbian-2024.01-S866c-P7738-Ha5c2-Vd711-Bb703-R448a (Aug 16 2025 - 02:09:48 +0000) Allwinner Technology

CPU:   Allwinner H3 (SUN8I 1680)
Model: Xunlong Orange Pi Zero
DRAM:  512 MiB
Core:  69 devices, 18 uclasses, devicetree: separate
WDT:   Not starting watchdog@1c20ca0
MMC:   mmc@1c0f000: 0, mmc@1c10000: 1
Loading Environment from FAT... Unable to use mmc 0:1...
In:    serial,usbkbd
Out:   serial
Err:   serial
Net:   eth0: ethernet@1c30000
starting USB...
Bus usb@1c1a000: sun4i_usb_phy phy@1c19400: External vbus detected, not enabling our own vbus
USB EHCI 1.00
......

 

You can see that immediately after the log entry "[44967.761002] reboot: Restarting system", the system begins booting.

Edited 6 hours ago by svvolf