<div dir="ltr">Hi Lennart, Thanks for the reply. System is not always going in emergency mode, sometimes it boots successfully. But when the system goes in emergency mode we can see this unit is masked. We are not masking the cryptsetup.target file. Regards, Sumit Kumar</div> <div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 16, 2025 at 9:08 PM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Do, 16.01.25 14:18, Sumit Kumar (<a href="mailto:sumit.kumar1@trellix.com" target="_blank">sumit.kumar1@trellix.com</a>) wrote: > Hi , > > Our Linux based system uses an external storage disk called capture. > The capture disk is encrypted with LUKS to protect stored data. During > system boot, system uses the LUKS utilities to decrypt the disk before > mounting the file systems containing the stored data. Due to an issue with > inconsistent ordering of decryption and mounting services during system > bootup, during reboots the system with capture disk can get into emergency > mode. You void your warranty if you mask fundamental units of systemd: > LoadError=org.freedesktop.systemd1.UnitMasked "Unit cryptsetup.target > is masked." This disables key synchronization points, and the things just fail. Lennart -- Lennart Poettering, Berlin </blockquote></div>