NanoPI R2S doesn't boot after shutdown

Troubleshooting
1
  • SD card: Kingston 32GB
  • SBC: NanoPI R2S
  • DietPi Version: latest available
  • Architecture: aarch64

I boot from the sd and everything works fine, I configure the eth0 and eth1 through /etc/network/interfaces
and still everything fine. I setup a PiVPN on the eth0 and everything works fine there too.
I run reboot and it reboots correctly without issues.
After that I run shutdown, I plug it in again and it does not appear to boot. the sys led keeps blinking and the device is not available in my LAN.

At this point in time I’ve reinstalled everything from scratch at least 3 times and every time I had this issue after the shutdown.

I’ve also checked that I’m delivering the right amount of power (5V, 2A).

I’ve been using dietpi on a raspberry pi 4 for a long time and never had a similiar issue so I really don’t know where to begin to debug this, maybe the logs will help me.

I’ve tried mounting the sd on my computer and I can read it witout issues.
Where can I fin useful logs to debug the issue?

Thanks

2

we don’t keep logs on a default configuration as they are located on a tmpfs. To be able to keep logs, you would need to make them permanent. But this would require access to the device. However, if the system is not booting, no logs will be written :wink:

Best would be to connect a serial console to be able to debug this situation.

3

Is that the thing about uart etc that it requests on the first boot? In that case I currently have that feature enabled but I’ve never used it, will look on how to interact with it as a serial console

4

I don’t use serial console myself but I guess @MichaIng could assist with this.

5

If you can provide me instructions on how to persist the logs, I can reinstall everythinf from scratch, trigger the bug and collect the logs from the sd

6

As said above, if the system is not booting, I doubt logs are generated at all.

persistent system logs:

dietpi-software uninstall 103 # uninstalls DIetPi-RAMlog
mkdir /var/log/journal # triggers systemd-journald logs to disk
reboot # required to finalise the RAMlog uninstall

Then you can check system logs via:

journalctl

which will then show as well logs from previous boot sessions. To limit the size, you can additionally e.g. apply the following:

mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' > /etc/systemd/journald.conf.d/99-custom.conf
[Journal]
SystemMaxFiles=2
MaxFileSec=7day
_EOF_

This will limit logs to 14 days split across two journal files, so that with rotation you will always have between 7 and 14 days of logs available.

7

First of all you could try our new image uploaded today. It ships with a major kernel upgrade, so probably it makes a difference.

To see serial console logs you need a USB-UART adapter. Something like this:

One with 3 cables is sufficient: RX, TX and 3.3V.

You need access the GPIO pins, i.e. open the metal case, in case. Between the Ethernet ports and the USB-C port, there are the 3 pins of the debug UART, which should be labelled so you can attach the UART adapter correctly:

r2s
r2s750Ă—405 84.3 KB

Attach the other end to a PC. PuTTY is not only a SSH client, but also supports serial ports. The console should appear as COM3 port, so in PuTTY switch to “Serial”, enter “COM3” and 115200 baud rate:
putty

Open it and then power the R2S. You should see early boot messages from bootloader stage, kernel logs and in the end a login prompt, depending on where it stops, respectively the step/reason where it crashes/hangs.

8

Will try ASAP (probably a few days) both the new image and the persistent logs. As for the UART, it could take me a little bit more (I have to order it, or ask some friends if they have one) but def can be done, will let you know wich approach works! Thanks for all the help, you’re the best

sidenote: Also, dietpi never ceases to amaze me with its stability and reliability, on my pi 4 it never had an issue, never destroyed my sd cards like other distros. It. just. works.
I really admire all the work that is put in to dietpi, many new hobbyist can now approach the idea of selfhosting things thanks to this.

1 Like
9

I am suffer the same experience too for more than 5 years now,
I have 2 units of NanoPI R2S (old version) come with micro usb port (Not USB-C).
Only 1 of my device have trouble to start after reboot.
The other one is just fine, very fast reboot without any glitch.

I already inspect what not the caused:

  • SD-Card 16GB 32GB 64GB not the caused.
  • OS / Firmware installed in the SD-Card not the caused
  • Power supply not the issue too
  • SD-Card reader (slot) not the caused

Finally I found how to resolve the issue (Not permanently !)

What I inspect the caused are:
cmos nand gate circuit (RTC CMOS BIOS),
somehow has micro-capacity (Electric not discharge immediately)
Since some power still floating (not discharge) the process halt to reboot.
Since Boot procedure not start (halted), the Bios halted Preboot Diagnostic Test
So the SD-Card never start to read… nothing start … just idle.

The Only way I did to success to boot after reboot:
== UN-Plug the power / disconnect the power
== wait minimal 6~8 minutes before connect the power again.
After connect the power, the Bios will start to run Preboot Diagnostic Test,
then start to read the SD-Card … Booting started … Done !!

No need to unplug other than the power.
I run many times to proof it works consistantly.
I did timer clock too set for 6~8 minutes before pluging the power again.
IT WORKS Boot…

Hope anyone of you can try this and back with the result.

Regards,
Yung

3 Likes
10

This actually sounds like an issue with the bootloader. You should be able to update it via dietpi-config advanced options. There are a few SBCs which have unreliable reboot indeed, unresolved until now. But I never heared of it with NanoPi R2S. Mine reboots successfully as well.

11

Yup can confirm the only way to make this work is to wait after plugging off the power for about 5 minutes. Seem to work reliably. Just a bit painful to use, such a waste of time :frowning:

1 Like