Reboot command

[Nick]

For some reason the reboot command doesn't appear to reboot the H3.

 

Is this because it doesn't have a PMIC in the same way that the A20's do or is it just a case of the correct assembly instruction not being called?

[Nick]

Sorted.

[quentin]

Could you tell us what was your issue and how you solved it ?
 

I have the same problem with my Orange Pi One, after the reboot command the board does not start again 

[Nick]

Sorry, I can't remember exactly, but it was something very silly like the USB -> UART converter had been disconnected. This ment that I was being logged out of SSH by the reboot command but the serial console didn't appear to change.

[Igor]

I just made numerous reboots on my Opi+, running desktop Jessie with latest build 3.4.111 (new kernel) and it reboots just fine.

 

Some USB keyboards or crappy UART converters can break this process in U-boot. It goes to prompt.

[lampra]

In my case, I have nothing connected to opi pc except of ethernet and power. I just run ssh daemon and nothing else.

I installed the latest kernel 3.4.111.

When logged in with ssh, reboot command does not work. Init 6 works some times but not always.

[tkaiser]

Show us the output from 'sudo armbianmonitor -u' please.

[lampra]

Here is the output

http://sprunge.us/QVXf

[tkaiser]

Well, the Armbian/armbianmonitor version is too old unfortunately.

 

I know exactly 4 reasons why reboot or init 6 fail or seems to fail with Armbian:

1. We had a bug in Armbian 5.03 which led to a system freeze at shutdown when wrong script.bin has been used (Ethernet driver issue). Fixed since 5.04
2. U-boot hassles Igor already mentioned (u-boot misinterprets things at startup and while the reboot worked the kernel will never be booted)
3. rootfs over NFS with changing IP addresses. Reboot works but Linux never comes up since it gets stuck at mounting the rootfs
4. Filesystem corruption due to a broken SD card led to the same symptoms as N° 1 above. The freeze prevents the reboot

So I would suggest checking the card since I can not imagine another reason. But without an attached serial console and enabled boot verbosity (sudo armbianmonitor -b and adjusted /boot/boot.cmd) it's hard to tell what's going on anyway.

[lampra]

I tried 3 different cards but no luck.

 

Then, I connected opi pc to hdmi tv and reboot started working.

Even if hdmi is detached from the tv and attached to opi pc, reboot works.

Detaching hdmi from opi pc again causes reboot to stop working.

[Igor]

We need logs otherwise it's hard to tell. I can't recreate those problems. It's working with and without HDMI on my Orange pi+

[lampra]

Let me know which logs do you need and I will try to recreate the problem on opi pc.

[Shamanches]

for rebooting i'm used command:

 

sudo /sbin/shutdown -r now

 

for sudo dont ask password i'm edited:

 

sudo visudo

 

and add bottom

Defaults:nameuser !authenticate

 

(change you name user in this line)

[immutability]

I know this is an older topic, but after facing very similar symptoms and spending frustrating hours trying to figure it all out, the forum search pointed me to this discussion. I was also encountering random failures to boot, and incidentally, it almost always worked when I moved to the living room and connected the HDMI. Just wanted to share my story in case it would help someone:

 

In my case the issue turned out to be hardware related. On my desk, I was powering the OPI PC+ via the GPIO pins over some wires with crocodile clips while taking current readings. The contact resistance was enough to cause a brownout during boot, with the voltage at OPI dropping to some 4.3 V (voltage at the 5V/2A adapter was about 4.9 V). With the same adapter connected directly to the GPIO pins with no extra wires or crocodile clips, it works nicely.

[tkaiser]

In my case the issue turned out to be hardware related. On my desk, I was powering the OPI PC+ via the GPIO pins over some wires with crocodile clips while taking current readings. The contact resistance was enough to cause a brownout during boot, with the voltage at OPI dropping to some 4.3 V

 

Just to add another potential reason why reboot seems to not work: since the board gets stuck on u-boot prompt due to some noise on serial RX line or via USB devices. The latter was one of the reasons why we disabled USB in u-boot for H3 boards (still can't remember whether this change made it already in the available 5.14 releases) and we just recently discovered that on NanoPi NEO obviously noisy power sources lead to u-boot waiting endlessly for input on the prompt since it misinterpreted some signals before and stopped autoboot behaviour.

 

In other words: reboot works perfectly but then the board waits sitting at the u-boot prompt for instructions (had this several times with NanoPi NEO the last days but only when connected to a specific PSU source).

 

BTW: Since you mentioned contact resistance and also consumption measurements in another thread. Contact and cable resistance might influence your consumption readouts (too much) and on the other hand I did a lot of research/tests the last weeks how to lower idle consumption especially of various H3 based boards. Good starting points might be

• http://forum.armbian.com/index.php/topic/1748-sbc-consumptionperformance-comparisons/
• http://forum.armbian.com/index.php/topic/1614-running-h3-boards-with-minimal-consumption/
• http://forum.armbian.com/index.php/topic/1728-rfc-default-settings-for-nanopi-neoair/

[immutability]

Thanks for sharing those links, very good reading!

 

For my project, I plan to power on the OPI only once a day to perform its task, send the data over (a photo, hence the choice of OPI with its budget CSI camera module) and power off (by disconnecting DC voltage). Controller would be an ATtiny in power-down sleep with RTC, so this way I hope to achieve the battery life in the weeks range, as this will be a birds nest in a remote location. So I'm not so concerned about the long-term idle consumption as long as it boots quickly, does it job, etc.

 

That said - I don't want to get too off-topic, but what is the typical boot time for Armbian 5.16 on an Orange Pi? In my case it takes about 80 seconds to boot, but there seems to be an idle period between the 20 and 70 second mark. The logs look something like this:

[    7.074242] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro
[    7.310713] Adding 131068k swap on /var/swap.  Priority:-1 extents:1 across:131068k SS
[    7.772098] ip_tables: (C) 2000-2006 Netfilter Core Team
[    7.794153] nf_conntrack version 0.5.0 (16003 buckets, 64012 max)
[    7.843567] ip6_tables: (C) 2000-2006 Netfilter Core Team
[    8.638005] systemd-journald[178]: Received request to flush runtime journal from PID 1
[    8.919436] gmac0: probed
[    8.919755] gmac0 gmac0: eth0: eth0: PHY ID 00441400 at 0 IRQ poll (gmac0-0:00)
[   19.320045] eth0: no IPv6 routers present
[   71.261063] ADDRCONF(NETDEV_UP): wlan0: link is not ready

[zador.blood.stained]

@immutability

Try looking at output of

systemd-analyze blame

to check if any userspace service takes a long time to start, also you may want to run

systemd-analyze plot > plot.svg

and open plot.svg on another machine to see graphical representation of startup time of different services.

 

I would guess that your delay is related either to waiting for network connection or to slow SD card read/write speed.

[immutability]

@zador.blood.stained - thanks for these ideas! 

 

The first one, systemd-analyze blame, reported 1min 3.879s networking.service so I'm guessing it was waiting for eth0 all this time, as (according to the power consumption) the wireless was not being brought up until after the long wait (there's a visible spike in current consumption).

 

So I tried commenting out eth0 in /etc/network/interfaces and voila! It went down to: 2.855s networking.service, and the overall boot time went down to about 12 seconds, excellent!

 

I forgot to mention I'm booting from the internal eMMC but that's irrelevant now. Thank you so much again for all your help guys!

[sfx2000]

On 8/15/2016 at 8:56 AM, tkaiser said:

Just to add another potential reason why reboot seems to not work: since the board gets stuck on u-boot prompt due to some noise on serial RX line or via USB devices. The latter was one of the reasons why we disabled USB in u-boot for H3 boards (still can't remember whether this change made it already in the available 5.14 releases) and we just recently discovered that on NanoPi NEO obviously noisy power sources lead to u-boot waiting endlessly for input on the prompt since it misinterpreted some signals before and stopped autoboot behaviour.

 

In other words: reboot works perfectly but then the board waits sitting at the u-boot prompt for instructions (had this several times with NanoPi NEO the last days but only when connected to a specific PSU source).

 

This is actually still an issue with noisy power supplies (cheap cell phone chargers and the like) - it's not an Armbian issue... if anything, it's a HW issue on the front-end - a good clean PSU that is intended for SBC's should be ok.

 

Devices that have MicroUSB and OTG capability can get stuck there in uBoot as the noise can be interpreted as a key stroke with some boards and some PSU's - the Nano Pi NEO is good example of this... and this happens before uBoot even can sort things out.