Hi all,
So since the GRUB boot to bios bug (which I fixed with this helpful tutorial from you guys: The latest grub package update needs some manual intervention), I’ve had increasingly worsening issues booting into EOS, which has culminated in my not being able to boot into my system again, but this time with the initramfs images launching but stalling at “running hook [encrypt].” In addition to the increasingly worsening slowdown experienced here and here, even scrolling through the grub boot menu has recently become a laggard process. However, I’m able to select from the boot menu, but any one of the EOS selections (the other options are the Windows bootloader and boot to UEFI) leads to the boot up stalling.
When I edit the grub menu list (by pressing e) and delete “quiet” in the linux boot command, I see that it’s stalling when it’s running the encrypt hook. It’s nearing a year now, since I first installed EOS, so it’s a bit hard for me to remember, but I think I followed this tutorial: https://discovery.endeavouros.com/encrypted-installation/encrypted-installation/2021/03/). I have an unencrypted FAT32 boot partition that hosts my grub files and setttings and my initramfs images. Then I have a LUKS + btrfs encrypted partition that hosts the rest of the filesystem including the crypt key necessary for the encrypt hook to decrypt the system.
Btw, when I say stalling, I mean I’ve left the computer on over night for nearly 12 hours, and it’s still been stuck on that “running hook [encrypt]” step. And it’s not frozen, since any keyboard input shows up on the screen.
I was wondering what the right course of action was to troubleshoot the problem. I wish the encrypt hook step were more verbose. I was wondering if I should arch-chroot as in the tutorial above and run mkinitcpio with different settings to build new initramfs images to boot from (I backed up the existing ones to my opt folder in the encrypted partition, accessing the filesystem from an EOS live disk). The cryptkey file location seems to be hardcoded into the encrypt hook bash script, however. And it’s also listed in the files list in the mkinitcpio.conf file.
Also, I have 484 MB of free space in the FAT32 boot partition, and nearly 500 GB of free space in the encrypted partition, so lack of space shouldn’t be an issue.
To be fair, I’ve also putzed around with my UEFI settings since the boot to bios bug but without this stalling boot up issue stemming from it, changing CPU virtualization settings, resizeable bar settings, etc. The hope’s been to finally, finally use my system to do some deep learning. I’ve thought about perhaps trying to reset the UEFI to default settings. But I’m not sure how that would help with this issue.
