First a general remark, please copy/paste not only the (some) output from your terminla, but complete, with the prompt/command line at the top and the new prompt at the bottom. This so we can see what you saw and know what you did. Now we have only some output, but have to guess what you did to get it.
Then, to give you a quick first answer, as you may have understood, the fisrt password is asked by Grub, because it has to read parts of your system to start it to boot and second time the operating system asks for it to be able to mount and use the root file system. Thus, yes, that is normal.
How to avoid?
Others may have some nice solution (special @nrickert), but one way might be to use a separate unencrypted /boot partition.
My normal setup is to use a separate unencrypted “/boot”. And, in that case, I only need to enter the passphrase once. However, I do have a Tumbleweed system where “/boot” is part of the root partition, and there I have to enter the passphrase twice.
I also have a system in a virtual machine, where “/boot” is part of the root partition, and I only need to enter the passphrase once (for grub booting). I’ll get to that shortly.
Here’s the general story:
If you use a separate unencrypted boot, you only need to enter the passphrase once (for use by the kernel). In this case grub2 does not need the passphrase.
If you are using “btrfs”, then it is best to not use a separate unencrypted “/boot”. That’s because a “btrfs” rollback cannot roll back to an earlier kernel than is in “/boot”.
If “/boot” is part of what is encrypted, then “grub2” needs the passphrase to access the boot information (menu, kernel, “initrd”).
There is currently no safe way for grub2 to communicate the passphrase to the booting kernel. About the only way it could do that, would be with a command line argument to the kernel. But command line arguments to the kernel are visible (in “/proc/cmdline”).
As for the workaround:
You can put the encryption key in a file, with the file path in “/etc/crypttab”. That way the key can be read from the file system. The tricky part is that the key needs to be read before the file system is available. So you have to force that copy of the encryption key into the “initrd” file. Fortunately, the “initrd” is readable only by root. But I personally question the wisdom of that, which is why I am only doing it in one virtual machine. If you want details, ask in a follow up post in this thread.
I know this is an older topic and the OP didn’t ask for details but this thread came up in my googling and I think other people might find the details useful. The good thing is that it’s actually part of openSUSE wiki now: SDB:Encrypted root file system - openSUSE Wiki