Just updated my BIOS and made sure that the BIOS params/SSD/UEFI etc are setup again as it should…
Boot is okay, I can get to the grub menu, edit entries etc… The issue happen at the second the “Manjaro” splash screen is displayed – here a hard reset occurs and the system reboots.
The SSD host’s a LUKS’ed partition and I’m able to “chroot” it (writting this from the live USB) although, I’m a little left blind at where and what to look/hunt for… (full backup has been taken as well…)
Hi Stephane, I did test to edit the main/last Kernel entry by removing these keywords:
quietas well as splash
It didn’t display the splash screen but got a reset as well. I did a video and I’m currently trying to zoom on it mind you to get a clue at where this whole thing hangs… I suspect that LUKS may be unhappy somewhat… This is the last line I could read just before the reset:
::running hook [encrypt]
if anyone would have any clue…
Thanks again, will still wait a bit before well, starting over… kinda need the system =)
So I went ahead and tried a fresh setup on that box, again LUKS’ing the SATA SSD. Setup went all well although upon 1st reboot, the exact same behaviors occurs.
I guess it’s somewhat of a regression with that BIOS release although that sounds crazy somewhat. I’ll setup on an available nVME M.2 to see the behaviors and I’ll report…
I can of course provide you the wanted info although from the newly setup (still showing the issue) installation, let me know.
Do you have the original BIOS available to re-flash? It does sound to me like it’s either been corrupted somehow during the download or flashing process, or there may be one or more bugs in the new version affecting these distros / kernels.
I had a bad BIOS flash years ago; in my case, a good mate had the needed chip programmer and I’d saved the old BIOS.
Also, I’d remove plymouth form the HOOKS= line in /etc/mkinitcpio.conf to see if this does help.
tested to re-setup on SATA SSD (Samsung SSD 850 EVO on SATA BUS) with LUKS disabled → working
tested afterwards to re-setup on SATA SSD (Samsung SSD 850 EVO on SATA BUS) with LUKS enabled → had it working/booting once then the artefact showed again (hard reset upon splash)
Removed the SATA SSD (Samsung SSD 850 EVO on SATA BUS)
inserted a M.2 nVME (Samsung 870 Pro) and setup Manjaro with LUKS enabled → all working fine / kept this as my current setup.
So I don’t know what to take as a conclusion but my gut feeling is that it seems like a LUKS issue somewhat in correlation with the BIOS changes and the SATA bus / SSD.
Thanks for all your kind help,
Cheers,
m.
FYI: these were the “documented” BIOS changes in between the release I’ve been running previously and the last one (jumped two versions up):
(lastest BIOS release change log) → Modify Fan start up speed when boot up.
(former BIOS release change log) → Update Intel ucode 0x12B to fix voltage issues in 13th and 14th Generation Core Processors.
this point is very useful : i hope that this cpu Intel will not produce errors , because default value for motherboard can damage cpu execution and produce error result
USE ONLY DEFAULT VALUE Intel in your UEFI Motherboard
So after extensive testings, I did again suffer the hard reset upon splash screen this while running on nVME M.2.
The only viable solution seems to be to disable C State Support within the system BIOS CPU options. I regret a bit not having tested that on my former setup (using SATA bus/SSD)… If time permits I’ll test again to get to the bottom of this.
For folks more knowledgeable then myself, are there any cons to disable C State Support on a given CPU? To my understanding that would disengage any power saving while IDLE, I may have got that wrong though…
Trying to interpret your post, would you suggest me to test parameters passed to the Kernel from Grub this while leaving the C State Support = enable within the BIOS ?
