EOS Bootup is stalling at encrypt hook

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.

So I reset my motherboard’s CMOS and tried to go through the boot up. While speed of scrolling through the grub boot menu sped back up, I still had to wait a long time to get to the grub decrypt password prompt and I still stall upon the loading of the initramfs booting up. I didn’t edit the menu to get rid of the quiet bit in the linux boot command statement, but I imagine it’s still stalling at the decrypt step.

One thing that I didn’t mention is that ever since I followed the tutorial to fix the grub boot to uefi error I’ve been getting the following statements printed to screen by grub: “error invalid sector size 65535.” I get this several times. After I cleared the CMOS before I proceeded to boot up the computer, I unplugged the power to my sata hard drives. So all that remained were the the 3 gen 3 NVMe drives I have and my blu ray disk player and dvd burner. One of the NVMe drives has my Windows installation and Windows bootloader. An identical one has my boot partition and my EOS installation. And the third one is the newest and just hosts Windows game installations that I share with the Linux side, launching these installed games through the Steam launcher and its proton wine prefixes (so that I’m less inclined to boot into Windows). These were all working fine before the grub boot to UEFI error and were still working fine even with the invalid sector size error once I got into EOS, until I ran into this decrypt error.

Do you guys have any tips? Is there any chance this could be related to problems I’ve been seeing from other people in regards to openssl?

Hi skcII

Welcome to the forum :slightly_smiling_face:

I found an old post about a grub bug that seems like it could be the same issue:

The fix for them was to unplug SD cardreaders cable (usb drives cable?) during boot.
I don’t know if this helps with your problem, but i guess it’s worth a try.

So I fixed this issue by arch chrooting into my OS and running yay -Syu. Since there was an update to the kernel, it ran mkinitcpio with the correct parameters and what not to put together a new initial ramdisk.

As to the invalid sector size bug, Melways is correct.