You are not logged in.
Hi. I'm posting here instead of Newbie Corner because it seems most relevant to the installation, but I'm happy to move it there.
I've used other Linuxes but am new to Arch, and am trying to get a basic working installation (complete disk, not dual-boot or anything complicated). I ran through the process in a VM, and everything worked OK.
I have a new Beelink GTi14 (Intel Core Ultra 9 185H). Secure Book is disabled in the BIOS. I copied the installation ISO to a USB stick, which loaded fine, and I ran archinstall. I did not (knowingly) choose any complicated options; I chose whatever video packages it suggested, partitioned the entire disk as it suggested (i.e. wiping out the entire disk, and having just one partition for everything), selected a small number of basic packages. The installation itself was fast and reported success.
However, when I try to boot the system, the following happens: It spins for a while, then shows the GRUB bootloader. I select "Arch Linux". It shows the graphical splash screen for a few seconds. Then the screen goes black, the monitor goes to "No signal", and the cycle repeats.
I am able to hit "c" to get into the GRUB menu, but I don't know where to even start once I'm here.
Thank you for any suggestions.
[EDIT:]
This was in fact coming from the Intel microcode bug mentioned later in this thread. As suggested, I added "dis_ucode_ldr" to my kernel parameters, and everything seems to be working fine.
Last edited by jnussbaum (2026-08-12 19:19:27)
Offline
If you're unlucky this will be related to https://bbs.archlinux.org/viewtopic.php?id=314577 try adding the suggested parameter in post #5 via the GRUB cmdline editor
Last edited by V1del (2026-08-12 17:27:33)
Offline
Ye gods! That was in fact it.
That's unlucky? At least I now know that I hit an incredibly subtle bug that was completely beyond me control. Here I thought I was just stupid!
I understand that there are a lot of moving parts involved in something like this, but how long is a fix likely to take?
Offline
Unlucky in the sense of just having done the installation to run into a pretty obscure bug that just so happened to coincide with the install ![]()
Not entirely certain for an ETA you'll want to follow the linked github report, "usually" linux-firmware relevant packages are updated monthly on checking, intel-ucode is a proper distinct package so likely somewhat exempt from this cadence (with the relevant updated having just happened), given the severity of this issue I could see this getting a faster uptick assuming upstream can identify and fix the issue (bad thing about firmware issues -- they are closed source, so the fix will have to come from someone at intel and within their hardware team), good thing about microcode updates/firmware updates that they are often not *that* strictly required, so omitting it via the param/downgrading the package for the time being is likely fine without obvious repercussion
If you're fine with this, please mark as [SOLVED] by editing the title in your first post (... or don't and wait for an update, verify things work without the parameter and mark as [SOLVED] then). You might have to shorten the title a bit, I'm suspecting you're close to the subject limit.
Last edited by V1del (2026-08-12 19:14:28)
Offline