So I exchanged my device for a new one and after setting it up today, it unfortunately has the exact same issue. This is evidence that it’s not a fault device and in fact something else is going on. I tested further with ElementaryOS distro and that does not have the same issue. It’s only happening with EndeavourOS
I have this(or very similar issue) but only on Wayland?! On X11 I have not gotten this.
Here is an example of what I see:
Sometimes also the welcome window.
I can open terminal and start some programs (kodi as an example).
I hope someone can offer a solution. I need to resolve this.
This is one of the problems where it is quite difficult to offer advice from a distance.
Is your RAM among the intel-approved ones? You didn’t give a full NUC type name, make sure that I guessed correctly.
If not, get a compatible RAM. Transient RAM issues are really difficult to fix, if anything in your setup is borderline, there’s no guarantee it will work all the time even if it seems to work now.
Why would RAM be an issue if almost every distro boots fine except EndeavourOS? Shouldn’t I be experiencing this across the board if its my hardware? I have a hard time making sense of that.
Intel NUC 12 Enthusiast
This black screen needs to be investigated further to resolve the issue.
I have a black screen sometimes when I cold boot into EnOS. It’s an issue of my Nvidia card. A warm boot from my parallel Ubuntu install resolves this. If your situation is similar, I would agree that this issue is specific to EnOS.
Can you answer these?
- Is nvidia graphics part of my hardware?
- Does the computer work even with a black screen?
- Is it accessible via
ssh?
If all these are true, RAM has nothing to do with it, and it’s most likely due to EnOS/Arch missing some initialisation step for the GPU.
My graphics card is Intel Arc. The black screen is not really a freeze. It’s a more a very extra long delayed boot from what I notice. Like maybe 1 or 2 mins and then suddenly it carries on.
That’s vital to know. Clearly, you can exclude the RAM, this is most likely really a EnOS issue.
This sounds like some systemd service timeout. Hopefully, someone with good system log analyzing skills can chime in how to best analyze issues like this.
1 Like
This thread is very strange, people jumping to conclusions, OP jumping to actions without attempting basic troubleshooting
At least posting inxi and journalctl logs would help much more
Also - what do you mean by “carries on” ?
I’m at the mercy of the help I receive as I’m new to Linux and still learning. “Carries on” means it eventually boots. Just takes way longer than what’s norm. It’s like the OS is constipated during boot.
While awaiting for your logs, this is very similar thread:
That thread is certainly the same issue I am having. I did a clean install and haven’t run into the issue just yet, since I haven’t rebooted much. Soon as I reboot and it happens, I will post logs.
Help yourself and others by posting your logs.
1 Like
Not an excuse, but for me, black screen equals “he’s dead, Jim”. Never in my life would I assume that OP meant a delayed boot.
When I first made the post, I assumed it froze. Just recently I walked away after a boot that appeared to choke and when I came back it finally booted. That’s when I realized it’s not actually frozen, but the boot is just very delayed. I can’t see most people sitting there and waiting, so it’s very easy to assume it’s frozen, especially because the keyboard backlight remains off during the delay.
It just happened again, and this time it wouldn’t boot in at all. I had to hard reboot 4x to get it to finally load. I really need to sort this out asap, as it’s beginning to become a nuisance, especially when I’m clocked into work.
Any developers I can PM my logs to?
BUMP . . . . . . . . . . 
Try this.
Oh, and make sure you are using Plasma on a blank home directory. Sometimes, using a preconfigured home directory from a previous install can cause issues.
This is true for any DE, just to clarify.
Try keeping the comments in this thread.
My recommendation is the same, though. Even from reading that thread, you still haven’t indicated that you have tried a base install of EnOS with a different DE (and just that DE).
That is the only way you can be absolutely sure that it is a KDE issue.
Using a different distro with a different DE only proves that a different distro doesn’t have the same issue.
As the Arco maintainer loves to say, “It’s all Arch.” It doesn’t matter (in most cases) which one you use because you can add Repos from another distro if you need them.
If it is that you absolutely want EnOS as your base install (maybe the theming is what you want?), then you need to try a different DE first (and again only install that DE) to test if you have the same issue.
Then and only then can you work out for yourself (with certainty) that KDE is the issue.
The logical part of my mind agrees with you that it’s most likely just Endeavour and not the DE, otherwise why does this happen as the BIOS splash screen is loading. Doubt a DE affects that early of a boot up, but what do I know? I’m just a consumer.
I was banking on one of the developers reaching out to me at some point, considering it’s an issue I would imagine they’d be interested in learning about, but that hasn’t happened yet. May just have to do some extreme testing as you’ve suggested and rule out the variables even further than I already have