You are not logged in.
Hello!
Hello, Arch forum! I have been using Arch for years, but today marks my first post here - happy to finally have an account.
So to my issue - when I boot into Arch I get a black screen shortly after I pick my choice from the GRUB menu.
Adding `nomodesetting` to the kernel parameters resolves this.
Since I'm using the encrypt hook I figured the resolution might be broken, so I entered the password blindly and voila - I'm in!
This started happening after the last upgrade to `6.15.5.arch1-1`, but not sure if it's a specific package causing this or the kernel itself.
Now I don't have a good understanding of the overall architecture, but I do have `kms` in my hooks - as far as I understand this is for the kernel to take control of the GPU instead of the display server to provide early hardware acceleration - however I don't understand how a kernel module setting resolves anything in this case - the `initramfs` hasn't started the kernel yet, so how could such a setting be taking effect during the `encrypt` hook?
I should also have you know that in general my system is slightly broken, so that might be related - a few weeks ago I restarted during an upgrade and since then after every kernel upgrade the new kernel image in `/boot` reverts to the old one after a restart causing all sorts of havoc since the installed kernel (pacman -Qi linux) is different than the one I booted into (uname -r). This is usually resolved by hopping onto the live USB to reinstall `linux`, `linux-firmware`, etc... and it works until the next upgrade. Since I haven't narrowed that down I assume that if the kernel itself is somehow being reverted that the `initramfs` can also be corrupted or something...
How would I go about debugging resolution issues in general?
Last edited by vimlucid (2025-07-20 16:19:14)
Offline
Adding `nomodesetting` to the kernel parameters resolves this.
"nomodeset"?
the `initramfs` hasn't started the kernel yet
And never will. The kernel loads the initramfs.
the new kernel image in `/boot` reverts to the old one after a restart
Means you're either booting from the root partition and mount a spurious boot partition or forget/fail to mount the boot partition before the update.
Please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.stOnline
"nomodeset"?
Yes - thanks!
I remember back then in `dmesg` there were errors about an unrecognized parameter. I wonder why such a parameter seemed to resolve the issue.
And never will. The kernel loads the initramfs.
The more you know - nice! There's this great Debian wiki linked from the ArchWiki that helped me fill the gaps - https://www.freedesktop.org/software/sy … ootup.html
Means you're either booting from the root partition and mount a spurious boot partition or forget/fail to mount the boot partition before the update.
It's the "spurious" boot partition at fault here (although I don't exactly know how that works) - after I read your comment a day or two after you wrote it I did check and noticed that the `mount` command didn't say the usual `/dev/nvme0n1p1 on /boot`, but the boot partition was rather mounted on `/efi` or something like that - I'm not sure how that happened. When I had broken the system with the update interruption I tried to fix it by deleting and reinstalling all packages - I wonder if that deleted some configuration somewhere and if it ended up with a default configuration that wasn't consistent with the rest of the system.
In any case - after reinstalling the bootloader, regenerating the configs, initramfs, etc... my upgrade procedure is fixed!!! And I no longer need to manually fix it via the live USB every time! Thank you very much!
Please post your complete system journal for the boot:
Sadly (or not sadly) yesterday after I upgraded to `6.15.7-arch1-1` the problem with the invisible decryption prompt disappeared. I tried restarting 5 times, but I can now always see the password prompt - so it was a kernel issue?
It's also weird that the incorrect `nomodesetting` parameter seemed to 100% fix it (at least as far as I remember, but I definitely remember seeing the "unrecognized parameter" error in `dmesg`).
Do you have any guesses what the issue might have been? I don't feel like bisecting kernel commits, but maybe the issue was tracked and fixed deliberately?
In any case - thank you for your input! I have no issues with my system for the time being!!!
Offline
Actually it seems quite old `dmesg` outputs are saved by `journalctl`. The unknown parameter error was apparently something that the kernel itself won't consume since it's meant to be understood by the encrypt hook. Also `nomodesetting` does seem to work somehow - maybe it doesn't validate that the parameter is longer
?
Jul 08 00:21:21 vimlucid kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=15cce427-48ab-4bea-833c-1af134bf876d rw loglevel=3 cryptdevice=/dev/nvme0n1p2:root crypto=sha256:aes-xts-plain64:256:: nomodesetting
Jul 08 00:21:21 vimlucid kernel: Booted with the nomodeset parameter. Only the system framebuffer will be available
Jul 08 00:21:21 vimlucid kernel: Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-linux cryptdevice=/dev/nvme0n1p2:root crypto=sha256:aes-xts-plain64:256::", will be passed to user space.Here's two `dmesg` outputs from back then when the issue was present:
- http://0x0.st/8dDv.txt - without the "nomodesetting" parameter that should have yielded the invisible prompt
- http://0x0.st/8dDw.txt - with "nomodesetting" for comparison
NOTICE: Both issues have been resolved as per my last post - one of them thanks to your advice! Thank you very much once again! This was very inconvenient to deal with and I wasn't finding the time to properly investigate as this is also my work laptop - the "spurious boot partition" should have been the first thing I had to check, but I never assumed it would mount somewhere else!
Last edited by vimlucid (2025-07-20 09:58:56)
Offline
[this post has been merged with the above post since I can't delete this one]
Last edited by vimlucid (2025-07-20 09:59:43)
Offline
after reinstalling the bootloader, regenerating the configs, initramfs, etc... my upgrade procedure is fixed!!!
…
after I upgraded to `6.15.7-arch1-1` the problem with the invisible decryption prompt disappeared.
I have no issues with my system for the time being!!!
\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
It's also weird that the incorrect `nomodesetting` parameter seemed to 100% fix it … any guesses what the issue might have been?
Jul 07 23:24:43 vimlucid kernel: Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=15cce427-48ab-4bea-833c-1af134bf876d rw loglevel=3 cryptdevice=/dev/nvme0n1p2:root crypto=sha256:aes-xts-plain64:256:: nomodesetting
Jul 07 23:24:43 vimlucid kernel: Booted with the nomodeset parameter. Only the system framebuffer will be availableSeems the kernel actually just treats "nomodesetting" as "nomodeset" - "The more you know" … ![]()
Jul 07 16:15:03 vimlucid kernel: amdgpu 0000:c4:00.0: amdgpu: [drm] Optional firmware "amdgpu/isp_4_1_0.bin" was not foundhttps://archlinux.org/packages/core/any … re-amdgpu/ - currently holds amdgpu/isp_4_1_1.bin
https://linux-hardware.org/?id=pci:1002-150e-1043-1df3 is also fairly new, maybe compatibility issue?
Online