Thank you, however I’ve tried Hardkernel’s Ubuntu image, and it doesn’t boot from that one either
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?
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 .
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 .
would it be possible to stick to a single post and not to communicate the same in 2-3 other post? This is not helpful. It is confusing to follow all the different strings. Let’s keep all information together on 1 post. Otherwise it is hard to follow for others.
Not that different kernel versions and boot configs can indeed consume different amount of power during boot. We had several cases where a kernel upgrade revealed an (before only close to) insufficient PSU. So that is not ruled out.
What somehow indicates any kind of hardware issue (PSU, cable, SD card/eMMC, attached peripheral/USB devices, or the SBC itself) is that the new official Ubuntu images fail to boot as well. If DietPi and Armbian were the only ones to fail, I wouldn’t have wondered, since there have been quite some cases where Armbian kernel upgrades broke things, but the Hardkernel images, used by a lot of users, are unlikely affected by the same bug. Another indicator for this is that it sometimes succeeds booting, sometimes not, so obviously there is no general issue with the image, like a faulty boot config, missing or invalid file or such.
You do not have a UART adapter to watch early boot messages, do you?
New images are btw up with haveged pre-installed instead of rngd, resolving at least the hanging Nextcloud installation.
Tried new image it boot up this time but it’s hanging during the installation , flash different emmc and micro sd still the same , when it load up to systemcrl-unmask command line it blue led gone and xu4 stop .
The blue led stop and the OS stop also , now i also having problem to boot from armbian , i double check everything and trying to recover eMMC bootloader using this official method , Both eMMC works so i don’t really know why i cannot boot ubuntu 22.04 armbian and dietpi but any other OS works .
I mean i cannot boot Ubuntu 22.04 directly i must install 18.04 then upgrade to 22.04 , I also tried install Armbian bullseye it won’t boot up too no matter eMMC or micro-SD
Edit : Just recovery eMMC bootloader it seems works again with Dietpi Bullseye , Installed Nextcloud without hanging like before , but i will keep my eyes on if there any auto shutdown again .
Edit : Is that a reason why it works again ? because new U-Boot config requires a single ext4 partition without a dedicated boot partition. After recovery eMMC bootloader i can boot the new dietpi image . This makes me think it’s partition problem and that’s why xu4 refuse to boot the new dietpi image
Coming back on this thread after a hiatus.
Tried to boot Hardkernel’s Ubuntu 18.04.3 (20190929) as was suggested earlier, but it doesn’t even boot that. Tried both the full and minimal images. Also tried the Android 4.4.4 (v7.1) image, all of them produce the same result.
Hmm there ia really no EEPROM, SPI bootloader like petitboot or similar on XU4 or do I overlook something? I’m still puzzled how the order of flashing images can hence affect whether one image boots or not.
Can you describe how you “recover” the bootloader? You mean to recover it on the same image/drive (eMMC) where the DietPi image was flashed to, right? And you use a recovery image from Hardkernel for this, attached via SD card or so? Not sure how compatible it is, but AFAIK the Hardkernel images all have a dedicated boot FAT partition while ours has a single ext4 partition for everything. The bootloader (U-Boot) however is flashed outside of/before the filesystem, so a recovery won’t break partitioning as long as it flashes the bootloader only and no partition table.