Fresh install - Won't boot on XU4

Alright, will try out the new image and come back if I still have issues. Thank you.

Ah sorry, the new image hasn’t been moved into place yet and I did a little enhancement for it to our build script. Please wait for an hour, I’ll trigger the build now and report back once it’s online.

New image has been uploaded :slight_smile:.

Thank you Michalng, however, I still have the same issue, after flashing the image on the uSD card.
Here’s the partition table:

Tried the same things as in my initial post: different uSD, different reader, pinged the SBC (timeout errors), hooked it up to a HDMI monitor (which received no signal). Red LED on, blue off.

Okay, so the kernel/bootloader/partitioning is not the issue then. Did you try with a different PSU our power cable? Or if any peripherals or USB drives are attached, did you try to detach them, to rule out a powering/voltage issue?

Tried as you suggested. I had only an external HDD hooked in the USB 3.0 port in the front, and that HDD has its own power supply, so I don’t think it was drawing any power over USB.
I unplugged it, also unplugged the eth cable for good measure, but it’s still the same issue. XU4 turns on, the fan speed ramps up, and then does nothing.
It works fine booting with the Arch Linux ARM setup I have and the external HDD plugged in (actually, it doesn’t boot at all if it’s not plugged in as the external HDD has the home partition), so I’m not sure if it’s a power issue.
Also I have the 6A power supply with this XU4.
Unfortunately I don’t have another power supply to try out with this.

Anything else you could suggest I could try?

EDIT: the Arch Linux ARM also has a separate boot partition like the old version of DietPi had.
EDIT2: checked the sum of the image with sha256sum before I wrote the image to the uSD, it was valid, also let Balena Etcher verify the image it has wrote.

There is a switch on the board to choose if it boots from USB or from SD card. Did you set it to SD when you tried it with the SD card? (I know, it’s a stupid question, but maybe you forgot to check that?)

Thank you for the reply Jappe.
Yes you’re right indeed, it does have a switch, however I think it’s between booting from mSD and eMMC. Since I don’t have an eMMC on hand, that switch has always been on mSD, but I’ll check again.

Yes you are right, it is not for switching between µSD and USB, its for eMMC. My bad.

To rule it out, could you try the Bullseye image from Armbian: https://www.armbian.com/odroid-xu4/

Very strange that old and new image fail to boot since the old one did work for years for others and the new one is quite different and did work for at least some users (you are the first who reports boot issues with it) :thinking:. As if it’s something with the Hardkernel bootloader and/or kernel (source) itself. Which kernel version does Arch ARM ship with?

Here is the official Hardkernel Ubuntu image which shares mostly the same kernel, though not the same build: https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu_5.4/ubuntu_5.4

You don’t have a UART adapter, do you?

Thank you for the answer Michalng!

I tried that Armbian image (funny how I was about to try that next), and unfortunately same thing occurs.
Not sure what that says about this problem, but I think my XU4 might have an issue.

The ArchLinuxARM kernel I use on this:

$ uname -srm
Linux 4.14.180-3-ARCH armv7l

Unfortunately I don’t have that adapter. I’m guessing it’s not possible to get more info on what’s happening without it?
In that case I’d either have to try out buying a new uSD card (if by the slim chance all uSD cards I tried were faulty), or to buy that adapter.

As it’s Linux 4.14, I’m quite sure it’s the older Hardkernel Linux sources, used in our previous XU4 image as well. Still no hint why it boots while our old one that you tried first does not :thinking:.

Last thing you could try is the official Hardkernel Ubuntu image linked above and if it fails as well, report at Hardkernel forum: https://forum.odroid.com/viewforum.php?f=95

Probably someone there has a good idea what else to test/how to debug.

In /boot/boot.ini (on ext4 filesystem, so not directly accessible from Windows) or can downclock the RAM and change the initial CPU governor to reduce initial power draw, as a last idea I have.

same here flash install and now won’t boot

You need to update kernel to 5.4 it’s not a power adapter problem , Just install ubuntu mate 20.0.4 and update kernel :slight_smile:

Should be pretty similar to our new XU4 Linux 5.4 image then :thinking:.

Thank you, however I’ve tried Hardkernel’s Ubuntu image, and it doesn’t boot from that one either :face_with_diagonal_mouth:
It’s possible that I’m having some issues with the uSD cards or the card readers (even though I’ve used multiple of them), I’ll have to buy new ones and try with those instead.

Is there a specific thing I need to do to update the kernel?

As said, our image ships with the latest kernel already.

We however found another issue with the entropy daemon which might even be the reason why you don’t see the XU4 on network. I’ll generate a new image on a few hours to test first.

You’re right we have the same issues , if dietpi fail to boot up then Ubuntu 20.04 and 22.04 won’t boot up too , you can try flash ubuntu mate 18.04 or android image from www.hardkernel.com and see if boot up or not , i don’t think it’s the micro sd card/card reader or device hardware problem .

maybe some legacy stuff is needed that is shipped with Ubuntu 18.04 but missing on newer version? :thinking:

I don’t know i tried flash other OS like OGST and Android / Android TV with no problem to boot and run so 100% not power adapter ( i have orginal adapter and 6a adapter )or device hardware problem , and i have zero problem running dietpi before bullseye image , now if i want to make dietpi bullseye boot again on XU4 i have first run ubuntu 18.04 on other micro-sd/emmc then upgrade 20.04 from 18.04 . then unplug the 18.04 microsd and then flash back dietpi bullseye on another emmc , it boot up but not last longer and cause many error .

same problem like other user ’ andoru ’