Odroid XU4 not responding after Upgrade

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version
    G_LIVE_PATCH_STATUS[1]=‘not applicable’
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
  • Kernel version | uname -a
    root@Dietxuu44:~# uname-a
    -bash: uname-a: command not found
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    Odroid XU3/XU4/MC1/HC1/HC2 (armv7l)
  • Power supply used | (EG: 5V 1A RAVpower)
    12V on Clamshell 2
  • SD card used | (EG: SanDisk ultra)
    SD card

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
  • Was the software title installed freshly or updated/migrated?
  • Can this issue be replicated on a fresh installation of DietPi?
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. I upgraded as per menu and I got a bunch of failed actions
  2. wont reboot

Expected behaviour

  • root@Dietxuu44:~# reboot
    Failed to open initctl fifo: No such device or address
    Failed to talk to init daemon.

Actual behaviour

Extra details

  • will reboot and see what happens.

Tried to reboot, Does not reboot!
Cloudshell drives make noise but can’t SSH into it!

Might be time to get a monitor on the SBC to see where the boot is hanging…

Dangerous to reboot without a backup when facing errors during upgrade. When those errors happened during or affected a kernel upgrade, this can make the system unbootable.

The errors look bad indeed, like systemd hangup. Filesystem corruption likely.

~# uname-a
-bash: uname-a: command not found

It’s uname -a with a space. uname is the command/executable, -a an option to show all details about your kernel.

Do you have another Linux system where you can attach and inspect/repair this Odroid’s system drive?

I do have a few other Linux systems. What am I checking for?

Backup? that was my next task on this system. What are the best solutions? was thinking of getting the image on another SD card.

This is the second time the upgrade on this XU4 goes wrong.

Yes, a full image backup is best of course. A dietpi-backup onto another drive, or even the same, is simpler to setup as regular task, and allows as well to restore kernel and boot configs e.g., when broken.

Filesystem errors:

fsck /dev/sdb1

or whatever the drive is named :slightly_smiling_face:. And then, try to mount and check its /boot directory.

Thanks will try this!

Is this like RPI-Clone? I will look at the documentation.

More like a GUI for rsync with some wrapping features. rpi-clone clones a disk, dietpi-backup copies the files within the filesystem, excluding partitioning, bootloader etc. Files can be restored from a running system, a disk clone/image not, but from an external system instead.

Actually doing more regular a dietpi-backup (which doesn’t take so much time and writes, as it is incremental), and less regular a full disk clone/image, either via something like rpi-clone or manually from an external system, is a good combination.

You can use dietpi-backup e.g. to a locally mounted USB disk (mount via dietpi-drive_manager).
See DietPi Documentation - DietPi.com Docs for details.
Also, our blog post DietPi-Backup in an multi-device environment - DietPi blog could give some advise.

I was able to check for filesystem errors, none found. went into /boot and all looks good but I am no expert and don’t know what to look for.
Guess I will retry with a new SD card.

1 Like