So the HDCP handshake fails (it's designed for that, so no big surprise )
Do you have another HDMI cable? Are there any adapters involved?
And most importantly: does the simpledrm device still show up in your journal?
This is the journal :https://0x0.st/XrS8.txt
And i don't have any other HDMI cable
Sorry, got nerdsniped by this, but unless I'm missing something, is it possible there's a bug here? (based on current master, bae9594ac1806ce30f2af1de27c49bb101a00d44):
In pacman.c:1223, we call parseconfig() and pass it config->configfile (config is a global variable defined in conf.h:237/conf.c:43)
parseconfig() is defined in conf.c:1391, and passes the argument (named file) to parseconfigfile() on line 1394
parseconfigfile() is defined in conf.c:1374, and frees config->configfile on line 1382
file in parseconfigfile() and parseconfig() now point to freed memory (back in parseconfig(), on line 1400, we then finally see the effect of this in the output)
Not sure if this is directly related to the segfault described by qoneop above, but some memory corruption is happening here.
Interestingly, some cursory git-blaming shows that none of the lines here have been modified since 2020. But potentially some lines inbetween have been removed at some point (did not dig further, sorry)
It is not related to the segfault, and only happens when using --debug. But I see what is happening and will fix.
]]>As I also had the same issue and could finally resolve it, here are a couple of findings, hopefully this can help someone else running into this pesky issue. First of all thanks to @sailor-2, the remark using efibootmgr to visualize the specific boot loaders of the system brought me on the right track to understand what is going on and why! Thank you a lot! So in any case using efibootmgr to determine where the grub efi image is expected to be located by the UEFI subsystem and comparing this information with the EFI installation on the disk is always a good point to start!
In more detail it is important to know that grub uses two components when installed in UEFI mode: The grub core image (*.efi) and the grub modules (/boot/grub/x86-64-efi/*.mod). These two components have to match regarding the version, if they mismatch you get exactly these issues like "is_shim_lock_enabled" error messages. This has nothing to do with shim lock itself, the call to the specific method that is expected to be present in one component simply does not exist in the other one and so the call and the whole booting process fails. Starting with grub 2.12 there seems to be an additional pitfall that the default install location for the core module has changed from EFI/BOOT/BOOTX64.EFI to EFI/<dist>/grubx64.efi. So just updating grub und running grub-install is very likely to end up with a mismatching configuration because the UEFI subsystem already knows the old grub installation of EFI/BOOT/BOOTX64.EFI and tries to use them with the newly installed modules.
What can you do in this situation?
One thing to mention is the flag --removable of grub-install. This will install the grub core module into the old location EFI/BOOT/BOOTX64.EFI and therefore is likely to already resolve the issue. In this case you would end up having two core modules installed and we just hope that the UEFI loader uses any of them, but there is also not really a reason why it would not.
How I resolved the issue: After running efibootmgr I found out that I had multiple old boot loader installations and started to clean this up, I also tried at some point systemd-boot which was also not working, so I cleaned up everything that belonged to Linux and grub. So basically everything besides my MS Windows boot loader that resides in the same structure. I removed all boot loaders (again except Win) in the UEFI setup (can also be done in efibootmgr to spare the reboot) and installed grub again using grub-install --efi-directory=/boot. I checked efibootmgr again to veryfy that the installation is matching the newly installed boat loader on /boot/EFI and it did. After reboot everything worked again.
Hopefully this can help someone, I tried my best to explain the issue as good as I can. Please correct me if you have different insights into the problem!
Best regards everyone and thank you again for helping me out!
]]>It was a bad translation string for the provider selection dialog … pacman-6.1.0 (in [testing]) is fixed
This here is about the slovenian translation and rather not https://bbs.archlinux.org/viewtopic.php?id=293911
]]>Optionally, not required:
1. Make backup of your `mirrorlist` file
2. Generate new list of mirrors from https://archlinux.org/mirrorlist/
3. Sort mirrors using `rankmirrors` command https://wiki.archlinux.org/title/mirrors#List_by_speed
4. Re-check if problematic mirror isn't first
Might be worth looking into reflector to keep your mirrorlist up to date: https://wiki.archlinux.org/title/Reflector
]]>