Because you destroyed Key Slot 1, this file (crypto_keyfile.bin) no longer has any use. Yes, invoking mkinitcpio will copy it over to the initrd “mini” filesystem, but it won’t be of any use. It just sits there.
Either deleting the keyfile (crypto_keyfile.bin), or commenting out the FILES line in mkinitcpio.conf, or destroying the associated key slot completely voids unlocking the container with that particular keyfile. Only your passphrase can be used to access the Master Key, thus to unlock the partition.
There are three common ways one can encrypted their system partition and unlock it during boot.
- The “legacy” way (which is my preferred method)
– This requires a separate non-encrypted /boot partition
– The executable kernel (vmlinuz), the “mini” filesystem (initrd), and the Grub files and configs live inside here, in the plain, non-encrypted
– This method uses AES acceleration to decrypt the Master Key (you have a working kernel and modules which handle decrypting the encrypted system partition)
– You can tell you’re using this method when the first thing you’re presented with is the (themed) Grub menu
Order of boot:
- Power up computer →
- EFI (or legacy-bios) Grub presents the menu →
- You make a selection in the menu (or the default entry) →
- The chosen menu item has instructions on root partition, encryption, LUKS options, etc →
- With immediate access to the kernel executable and initrd mini filesystem, everything required for accelerated decryption is ready and you are prompted for the passphrase →
- Upon success, the system partition is unlocked and the supplied LUKS options are remembered →
- Now that the system partition is accessible, /etc/crypttab is read for any additional partitions that must be unlocked (home, data, etc) →
- This is also why they discourage you from listing your system partition again in the crypttab, since it should be declared in the bootloader’s options
2. The exclusive EFI Grub method (rudimentary and “slow”)
– This only requires a small, non-encrypted EFI partition
– The Grub EFI executable lives in here
– Neither the root system partition nor the boot partition are accessible (fully encrypted system)
– The Grub executable has no bells or whistles, no acceleration, and thus its ability to decrypt the Master Key of the system partition is slow
– You can tell you’re using this method if you opted to also encrypt /boot, and the first thing you see when you power on is a basic black screen with white text that comes before the Grub menu
Order of boot:
- Power up computer →
- EFI Grub prompts you for the passphrase →
- Slow, rudimentary decryption of Master Key →
- With access to the kernel executable, initrd, and Grub files and configs, you are now presented with a (themed) Grub menu
- You make a selection in the menu (or the default entry) →
- The chosen menu item has instructions on root partition, encryption, LUKS options, etc →
- With system partition accessible, /etc/crypttab is read for any additional partitions that must be unlocked (home, data, etc) →
- This is also why they discourage you from listing your system partition again in the crypttab, since it should be declared in the bootloader’s options
3. Systemd-boot EFI boot (“faster” because it has access to vmlinuz and initrd)
– This only requires a small, non-encrypted EFI partition
– The systemd-boot EFI executable lives in here
– The executable kernel and mini filesystem initrd also live in here (plain EFI partition)
– Just like the “legacy” method above (#1), everything needed for accelerated decryption is accessible immediately
– While a plain, non-encrypted boot partition is not needed, you still need to have access to vmlinuz and initrd, which sit inside a plain EFI partition
Order of boot:
- Power up computer →
- EFI systemd-boot searches for boot entries on the ESP (e.g, entries/manjaro.conf)
- The boot entry, like a Grub menu entry, has instructions on root partition, encryption, LUKS options, etc →
- With immediate access to the kernel executable and initrd mini filesystem, everything required for accelerated decryption is ready and you are prompted for the passphrase →
- Upon success, the system partition is unlocked and the supplied LUKS options are remembered →
- Now that the system partition is accessible, /etc/crypttab is read for any additional partitions that must be unlocked (home, data, etc) →
- This is also why they discourage you from listing your system partition again in the crypttab, since it should be declared in the bootloader’s options
You can probably see a pattern here. If you want accelerated decryption of the system partition’s LUKS Master Key, you need a legitimate “mini” filesystem and executable kernel immediately avaiable. This is possible either with a separate non-encrypted boot partition or by having vmlinuz and initrd sitting in the plain within a non-encrypted EFI partition.
UPDATE: I encourage someone to tell me if I made a mistake or if I’m wrong. I’d rather be wrong and corrected so that we all have better information and understanding, rather than simply assuming I’m correct. 
