hmm, that is interesting.. So you have two entries 253.3-3 and I only have one..
My first one shows 253.3-1, which was the version when I installed the system.
So, this is indicating that indeed I’m stuck with 253.3-1 in my first EFI partition, that unlocks the drive..
Sure it helped, thanks for that.. I’ll now try to fix this, not sure how yet but it is definitely one more disadvantage that nobody spoke before..
I’ll try that.. I’ll try a bootcl install too..
If nothing helps, I’ll try to boot into the Rescue Image and fix it from there..
I’m not sure just thinking out loud? 
Man, it fixed 
reinstall-kernels
bootctl install
$ sudo dmesg | grep 253
[ 0.448253] acpi PNP0A08:00: _OSC: platform does not support [PCIeHotplug SHPCHotplug PME LTR DPC]
[ 3.582067] systemd[1]: systemd 253.3-3-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified)
[ 5.093653] systemd[1]: systemd 253.3-3-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified)
Thanks riki =)
There a few things that I’ve been observing that worth to mention here.
1- Every time a systemd update happens, you should run a #bootcl install to make sure that it updates the EFI entry accordingly.
2- In Windows, in Disk Management, select the EnOS SSD drive and set it to offline state, otherwise Windows will try to read it and this will make the drive to stay at 100% use.
If you want to go further, you can disable the drive entirely in Device manager.
3- sedutil-sleep-git AUR is working perfectly and I can suspend my system now.
Just one thing to keep in mind is that, to get the hash to create the systemd service, you will need to type the SSD password in the CLI, so after that, I think it is a good idea and just to be safe to edit ~/.bash_history and remove that command from there.
mcury thanks for the details. For anyone else that makes it this far the information/links/youtube videos earlier in this thread about OPAL being insecure and device makers recommending software encryption is all in reference to previous generation OPAL 1.
Glad it helped others
I’m using it for almost almost a month and no problems to report yet…
In case you find something that is not described in this topic, please share
And btw, welcome to the purple side of the force
fyi, dunno if you saw this https://github.com/systemd/systemd/issues/16089 … might be worth subscribing to. I wonder how much money could be raised on a bounty to get someone to complete the work.
That is interesting…
I have to boot the system twice, first boot is to unlock the drive and second boot to get systemd-boot working… But this happens once a day so not a big deal for me.
But it would be nice to avoid that boot just to unlock the SED. I think I saw something about it in the github issues, let me check
Edit:
Luks and cryptsetup now support self-encrypting drives. Kudos to the first person who gets it working and documents the process. 