Ugoos X4Q Cube, S905X4 2GB, booting from a brand new Sandisk microSD card purchased from a reputable retailer. Attempting to boot CoreELEC-Amlogic-ne.aarch64-21.2-Omega-Generic.img with the ugoos x4 device tree, flashed with Rufus.
Issue persists across other SD cards and USB sticks, and across various versions of CoreELEC (ng/ne/21.2/20.5/nightlies), and across both the x4 device tree and the generic device tree.
Roughly 90% of the time when booting up CoreELEC, the system reports a fatal kernel panic, “not syncing - Fatal exception”. I will attach logs, however I can only access proper logs on the boots that are successful so it may be they don’t contain any relevant information. https://paste.coreelec.org/SmackedBuzzed https://paste.coreelec.org/MumblingBetcha
The exact error message reported on the screen during the panics varies - sometimes it is “attempting to kill init”, or mentions no specific error besides a varying trace. I have attached an example video.
After crashing, it reboots and repeats the same process often 10+ times, before either successfully booting Kodi or getting completely stuck with no further rebooting. This process happens regardless of how the system was powered off, such as a full shutdown, or a reboot.
With how variable and inconsistent the crashes are, across many different attempts to change the setup, I am worried it’s something to do with the hardware. However I bought the X4 as it was listed with official support, and I don’t see anything to indicate I’ve got a counterfeit box from their official store.
Does anyone have any suggestions on what I could try next? If the booting odds were better I’d just try and avoid turning it off, but that probably isn’t a stable solution.
Appreciate the help.
Booting CoreELEC-Amlogic-no.aarch64-22.0-Piers_alpha1-Generic.img does not work at all with the ugoos_x4.dtb, it gives a fatal error before ever reaching the CE boot logo where my previous errors have mostly been.
If I use sc2_s905x4_2g_1gbit instead, it acts in much the same way as earlier versions of CoreElec. On first boot it got stuck after flashing some error text too quickly to read. Unplugged it, waited, then it worked on the second boot (albeit after probably silently crashing again in the process as it went back to the Amlogic logo for a moment).
Attached is the log from that boot: https://paste.coreelec.org/BulletinRemote
Reboot then worked flawlessly for two more boots, but selecting shutdown then caused the same fatal errors as previously. Further boots Anecdotally the odds of booting seem better, though, I’ve not had as many that get completely stuck or take many many reboots to load.
I also just tried the x96 version of the dtb. First boot seemed okay: https://paste.coreelec.org/LasersScurry. Again reboot worked fine. Power off caused a kernel panic, and then crashed silently until Kodi went into safe mode (which has happened previously but is rarer). Here is the log for that as well: https://paste.coreelec.org/MarigoldTurban
Unfortunately I only get a black screen with that, not even to the usual 1st boot partition resizing step.
However, just to be sure I tried swapping out the provided .dtb with the generic one, and as far as I can see that works flawlessly. https://paste.coreelec.org/BeachesPebbles
The filesizes are very slightly different, unless there was a deliberate edit I wonder if there was some weird problem there?
Anyway, thank you very much for your help, I wasn’t expecting it to be fixed so quickly. I’ll reply back here if I run into something else while actually using it, but so far it seems good.
Oh, that’s interesting. I mean it works completely fine with the generic dtb, I’ll try with the edited one too but if that’s all you changed, maybe it was already fixed in the nightly?
I actually thought I had already tried the nightly before posting this thread, but I didn’t mention it as I didn’t think that was intended or stable enough for a proper test.
For completeness, the edited x4 .dtb is able to get to the CE boot logo unlike the original, but it starts with a flash of static and then crashes with a fatal exception. After a few tries it did successfully boot Kodi, but the underlying problem still seems to be there. https://paste.coreelec.org/RupertSchmidt
I also went back and tested the nightly I tested before asking here (CoreELEC-Amlogic-no.aarch64-22.0-Piers_nightly_20251021-Generic.img) which still gives fatal exceptions in the same way regardless of .dtb.
So I guess if there’s a fix, it happened coincidentally in some nightly after the one I downloaded, up until the one your test is based on?
I let it download the update to the latest nightly after testing and fatal exceptions still occur, so to me it feels like there must be something different in your test version that fixed it. Or some other ghost now haunts my device from the auto-update.
But, however it happened, it works now with your test image and sc2_s905x4_2g_1gbit.
…and as of writing this post, it has just thrown another fatal exception, with the test image. The first boot it told me there was a missing super partition, but I’ve been completely unable to reproduce that, and media plays fine, so…different bug? Here’s a log from after a different boot that also gave a fatal exception, but without the super error: https://paste.coreelec.org/QuicklyFreaking
Fatal exceptions in general seem rarer now, though. Most boots are fine, maybe 10% crash now once before rebooting successfully?
Let me know if there’s something further you’d like me to test, but it’s certainly usable as it currently is and I wouldn’t blame you for not wanting to spend more time on this. I can always see how I go for a bit of actually using Kodi and come back later to see if the issue persists in future nightlies.
Update: I got the super partition error again, after a crash during media playback. I am unsure if the auto-update really did break something on the android side, or if I just got lucky before.
As I wrote there is nothing special in the image except my changed DTB. If it doesn’t work for you then I don’t know what it could be. I will do some reboots with my device to see if works stable or not.
To try and narrow down the testing I will now stick to using the latest nightly and the ugoos_x4.dtb included, which looks like it now has the changes you’ve made.
Initial behaviour seems somewhat consistent now: first boot has a fatal exception, but then it reboots itself and works well for a while.
After a while the errors return (possibly it seems more frequent if I attempt to boot the device after having unplugged the power, or if I’ve just come from the Android side).
Partition super errors seem to occur at random rarely, but are not persistent. If I can dig up a suitable cable I’ll reflash the android side, but surely that would not be possible to break by booting CoreElec?
I have tried both USB and uSD: that last log in the previous post was using the USB, most of my earlier tests were with uSD. I’ve not seen any significant differences between the two, but I can test with both in future if that would be useful.
With the new .dtb, it seems to work! No fatal errors, and the flash of static from before is gone as well.
However I suspect there are now different crashes, even if it overall works basically fine now.
On first boot, I never see the usual “resizing partitions” text. It remains on a black screen with the LED cycling that looks as though it is repeatedly trying and failing to boot: green → white → red, repeated a few times. Eventually it boots and from there on out it seems to work fine.
With future boots, I still sometimes see the same LED cycling on a black screen, with those boots taking ~2-3x as long. That’s not a problem, it ultimately boots fine, but I suspect there are silent crashes occuring that aren’t showing evidence on my screen for whatever reason.
When it eventually boots, Kodi does have a crash log to upload: https://paste.coreelec.org/TeethingSpeakin. I then rebooted a few times until it happened again, and got a very similar log with new timestamps: https://paste.coreelec.org/CovertBarter.
On the times where I get a normal speed boot, there is no crash log: https://paste.coreelec.org/HestonKilled
Finally, just in case, here is a log from where the first boot after a fresh flash, there is still the same crash: https://paste.coreelec.org/DecorAnchor
So, overall, it seems much more stable. I’ll give it a proper go with media etc later, but it now boots reliably, even if it does take longer at times. Behaviour seems the same on both USB and SD.
Looks like that fixed the display, I’m now seeing the usual early-boot stuff like the amlogic logo and the resizing partitions message.
I started with the USB, and at first it seemed great, first 10 boots worked flawlessly, with none of the looping seen before. But after that I got a kernel panic and became unable to boot it at all, it would either keep panicking or just freeze entirely.
Switched to the uSD, and saw kernel panics from the start, it took several tries to get to a normal Kodi boot.
Crash log: https://paste.coreelec.org/PolishVideos
dmesg: https://paste.coreelec.org/KickerWedding
Subsequent boots just got to the CE logo before crashing in a loop. If I left them looping long enough they sometimes eventually reached Kodi.
Went back to the USB with another fresh flash to try and get logs. It rebooted several times on first boot and ended up in safe mode. Oddly Kodi restarted itself when I went to enable SSH as it suddenly lost the red safe mode theme and went back to the usual first-boot dialog (not a full reboot of CE).
Here is the crash log: https://paste.coreelec.org/MercerCouture
Tried a few more times to get a log from directly after a visible kernel panic but was unsuccessful. No new crash log was generated after a bootloop that eventually led to a normal Kodi boot.
As in there is a Kodi bug responsible rather than a CE bug? With how well Kodi worked earlier it felt more like the kernel panics in CE were then causing the later instability in both.
For example I just went and reflashed the uSD again, and it booted flawlessly several times. Then I get a kernel panic, and from there onwards it is very rare to get a successful boot. I assumed some sort of corruption was occuring. These errors look like they occur too early in the process to be Kodi related.