I'm looking for a clear tutorial on how to do this but I'm encountering insufficient information everywhere. Namely, I have a laptop with the following disk configuration: Drive one has Fedora 38 installed and the drive is encrypted. However, I have a second SSD, independent of the one on which Fedora 38 is installed, and I would like to encrypt it with LUKS as well. I have searched and read but I am lost. https://docs.fedoraproject.org/en-US/quick-docs/encrypting-drives-using-LUKS/#_remove_a_passphrase_or_key_from_a_device reading the official Fedora guide to LUKS encryption, I can not grasp the idea of how to implement this to the second SSD independent drive so that if, for example, I need to reinstall Fedora or another system on the drive on which the operating system is currently, I do not fear losing access to the second drive encrypted. 1) How to correctly implement the above (or other) guide to have the second SSD encrypted? 2) What steps would have to be considered in such a solution to have access to this drive in case of reinstallation of the system or blowing out the drive with the operating system? (I mean here a copy of the keys, etc. ?) 3) I tried this tutorial from point 4 and unfortunately ended up somewhere with my mistake and after rebooting the system I had to enter twice the password to the encrypted drive with OS and to the other SSD drive but unfortunately after entering both passwords correctly, I received a message about the need to log in as root to repair the system. 4) Is it possible to implement a solution so that it only asks for the password to the encrypted partition with OS, and to the second drive only from within Fedora ? I would be grateful if someone would try to explain it to me, I have searched really many places from Fedora, here, Youtube as well as other articles but I am probably too stupid to understand it.

I have one physical server and would like to configure full disk encryption for it. First I was playing around with an virtual machines (CentOS7) and have enabled it during installation: On reboot I get the following prompt and can successfully unlock the drive: [root@srv~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 20G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 19G 0 part └─luks-9ca13c53-317d-42c5-a3ea-c6039274bf38 253:0 0 19G 0 crypt ├─centos_otrs-root 253:1 0 17G 0 lvm / └─centos_otrs-swap 253:2 0 2G 0 lvm [SWAP] sr0 11:0 1 1024M 0 rom AFAICS the bootpartition is not encrypted. How could I possibly perform a true full disk encryption and still be able to use the crypt-ssh dracut module for remote unlocking of systems with disk encryption via ssh. Thanks!

I followed the advice from https://unix.stackexchange.com/questions/786259/guix-how-to-set-one-file-system-as-a-dependency-of-another-or-mount-one-devi , but it's halfway working for me. In my case, I still have to type the password before the GRUB menu. The second time during Linux boot, decryption happens automatically, so part of it succeeds.. When I ran guix system build, I saw a warning like 'possibly unbound variable mount-file-system'. My configuration right now

(apply raw-initrd
       (append (list file-systems) all-key-arguments
               (list
                #:pre-mount #~(begin
                                (use-modules ((gnu build
                                                   file-systems)
                                              #:select (mount-file-system)))
                                (mount-file-system (file-system
                                                     (mount-point
                                                      "/early-mnt")
                                                     (device (file-system-label
                                                              "USBDRIVE"))
                                                     (type "ext4"))
                                                   ;; This is needed otherwise the mount point
                                                   ;; will be prefixed by '/root'
                                                   #:root ""))
                #:helper-packages (append helper-packages
                                          (file-system-packages
                                           file-systems
                                           #:volatile-root?
                                           volatile-root?)
                                          (if keyboard-layout
                                              (list
                                               loadkeys-static)
                                              '())))))))

Say I have a LUKS partition which encrypts the root file system and whose key resides in another file system.

(mapped-devices (list
    (mapped-device
        (type (luks-device-mapping-with-options #:key-file "/early-mount/luks-key"))
        (source "/dev/sda1")
        (target "operating-system")
    )
))

How can I instruct Guix via the config.scm file to mount the second file system before the LUKS decrytion step? ### Attempt #1 I tried setting (needed-for-boot? #t) on the second file system but inspecting the generated initrd script it still tries to decrypt before mounting.

(file-system
    (mount-point "/early-mount")
    (device (file-system-label "early-mount"))
    (type "ext4")
    (needed-for-boot? #t) ; This doesn't move it to #:pre-mount
)

### Attempt #2 Also tried setting the root file system's dependency via (filter) and (file-system-mount-point-predicate) but I get the error: > error: file-systems: unbound variable which makes sense because it's in the middle of defining (file-systems)

(file-systems (cons*
    (file-system ...) ; early-mount definition
    (file-system
        (mount-point "/")
        (device "/dev/mapper/operating-system")
        (type "ext4")
        (dependencies (cons*
            (filter
                (file-system-mount-point-predicate "/early-mount")
                file-systems ; This is currently being defined so it's not available yet
            )
            mapped-devices
        ))
    )
    %base-file-systems
))

### Attempt #3 Tried creating a local variable via (let) for the second file system with the intention of inserting it under (file-systems) as well as under the (dependencies) but I get the error: > error: (let ...): invalid field specifier

(let
    (
        (early-mount
            (file-system
                (mount-point "/early-mount")
                (device (file-system-label "early-mount"))
                (type "ext4")
                (needed-for-boot? #t)
            )
        )
    )
    (file-systems (cons*
        early-mount
        (file-system
            (mount-point "/")
            (device "/dev/mapper/operating-system")
            (type "ext4")
            (dependencies (cons*
                early-mount
                mapped-devices
            ))
        )
        %base-file-systems
    ))
)

### Attempt #4 Then tried repeating the second file system (file-system) entry and this actually allows me to deploy the config:

(file-systems (cons*
    (file-system ...) ; early-mount definition
    (file-system
        (mount-point "/")
        (device "/dev/mapper/operating-system")
        (type "ext4")
        (dependencies (cons*
            (file-system ...) ; early-mount definition, copy/pasted
            mapped-devices
        ))
    )
    %base-file-systems
))

however this tries to prompts me for the password during boot, leading me to believe that it wasn't able to mount /early-mount before trying to do the LUKS open.

By googling, trial and error I came up with the following string:

cryptsetup benchmark -c aes-xctr-plain64

but I'm not sure whether it is correct. The cipher spec aes-xctr-plain64,polyval-generic fits also and gives the same speed results. Probably they mean exactly the same?

ZFS errors, I dont know why. Here are the step-by-step actions I took to attempt to mount the encrypted ZFS disk.

-shellsession
$ sudo zfs list

NAME                                               USED  AVAIL     REFER  MOUNTPOINT
bpool                                              322M  1.44G       96K  /boot
bpool/BOOT                                         320M  1.44G       96K  none
bpool/BOOT/ubuntu_uy913x                           320M  1.44G      320M  /boot
rpool                                             89.2G   802G      192K  /
rpool/ROOT                                        16.3G   802G      192K  none
rpool/ROOT/ubuntu_uy913x                          16.3G   802G     9.34G  /
rpool/ROOT/ubuntu_uy913x/srv                       192K   802G      192K  /srv 
rpool/ROOT/ubuntu_uy913x/usr                      3.85M   802G      192K  /usr 
rpool/ROOT/ubuntu_uy913x/usr/local                3.66M   802G     3.66M  /usr/local 
rpool/ROOT/ubuntu_uy913x/var                      6.92G   802G      192K  /var 
rpool/ROOT/ubuntu_uy913x/var/games                 192K   802G      192K  /var/games 
rpool/ROOT/ubuntu_uy913x/var/lib                  6.60G   802G     6.39G  /var/lib 
rpool/ROOT/ubuntu_uy913x/var/lib/AccountsService   244K   802G      244K  /var/lib/AccountsService 
rpool/ROOT/ubuntu_uy913x/var/lib/NetworkManager   1.46M   802G     1.46M  /var/lib/NetworkManager
rpool/ROOT/ubuntu_uy913x/var/lib/apt               120M   802G      120M  /var/lib/apt
rpool/ROOT/ubuntu_uy913x/var/lib/dpkg             89.7M   802G     89.7M  /var/lib/dpkg
rpool/ROOT/ubuntu_uy913x/var/log                   328M   802G      328M  /var/log
rpool/ROOT/ubuntu_uy913x/var/mail                  192K   802G      192K  /var/mail
rpool/ROOT/ubuntu_uy913x/var/snap                 5.57M   802G     5.57M  /var/snap
rpool/ROOT/ubuntu_uy913x/var/spool                 276K   802G      276K  /var/spool
rpool/ROOT/ubuntu_uy913x/var/www                   192K   802G      192K  /var/www
rpool/USERDATA                                    72.3G   802G      192K  /
rpool/USERDATA/edgard_7focix                      72.3G   802G     72.3G  /home/edgard
rpool/USERDATA/root_7focix                        1.56M   802G     1.56M  /root
rpool/keystore                                     518M   803G     63.4M  -

* After this one, I executed the command sudo zfs load-key -a, the output was

Key load error: Failed to open key material file: No such file or directory
    0 / 1 key(s) successfully loaded

* I tried to enter the key manually by this command

-shell
    sudo zfs load-key -L keylocation=rpool/keystore rpool

I got this output

Key load error: Invalid keylocation

* I executed this command to check different status

-shell
    sudo zfs get -Ho property,value encryptionroot,keystatus

output

keystatus	unavailable

It supposed to be **available** From now, I dont know where my-key-file is stored and how can I do to mount this **encryption disk**.

I recently set up Manjaro and noticed that my boot partition seems to be encrypted, neat! I got curious and read a lot about the details of the Linux boot process, however I can't make sense of one fact: I only have to enter my disk encryption password once. To my understanding, every stage of the boot process that needs access to encrypted files needs access to the passphrase. In my case at least two boot phases need access to encrypted files: GRUB (to load the initramfs and the kernel from /boot), and the kernel itself. Since I only have to enter my password once, the kernel must have a different way to access the passphrase. My search yielded [various](https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system#Avoiding_having_to_enter_the_passphrase_twice) [posts](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html#avoiding-the-extra-password-prompt) detailing how to add a keyfile to the initramfs in order to avoid the second prompt for the disk passphrase. That makes a lot of sense, however looking at my initramfs using cpio -t < /boot/initramfs-6.5-x86_64.img, it doesn't seem any keyfile is included in the initramfs, nor any other information that would help with the decryption (all files are located in usr/lib/modules and end in .ko.zst). My search then lead me to the [Linux x86 boot protocol](https://www.kernel.org/doc/html/latest/arch/x86/boot.html) . Again, I didn't find any trace of a standardized way for GRUB to pass the passphrase to the kernel. There is no direct field for a LUKS keys, I also didn't find any hint of GRUB using struct setup_data for that. The cmdline doesn't seem to contain decryption info either (luckily, since it's user-readable). I've also read (don't remember the source) about GRUB passing the "decrypted device" to the kernel via the root= cmdline, however that sounds weird to me; the concept of a "decrypted device" is only an abstraction, in reality the device is not decrypted; the key is simply held in memory to be able to decrypt what's needed on-the-fly, right? And that's where I am right now. The LUKS key seems to neither be included in the initramfs nor passed to the kernel by GRUB, so how does the kernel boot without asking for the passphrase a second time?

Fedora, similarly to other popular popular Linux distros, provides an easy way to set up [full disk encryption (FDE)](https://en.wikipedia.org/wiki/Disk_encryption) . As of Fedora 33, [Btrfs](https://en.wikipedia.org/wiki/Btrfs) has been the default file system (replacing [ext4](https://en.wikipedia.org/wiki/Ext4)) . I was curious to see a side-by-side comparison of a default installation with/without FDE in Fedora. I thought others might also be interested in this, so I decided to write a Q&A here.

I was given a "golden image" of an out of date production server and was instructed to update and harden the OS for production delivery. The issue I am running into is that LUKS. I am using Suse 12.5. When booting into an Ubuntu live CD to encrypt the root partition I get an error. * There are 8 total partitions. The root (system) is on sda3. * The command I am running is as follows:

-shell
    cryptsetup reencrypt /dev/sda3 --new --reduce-device-size 32m --type luks1

* The error that is returned is:

WARNING: Device /dev/sda3 already contains a 'dos' partition signature.
    Device /dev/sda3 contains broken LUKS metadata. Aborting operation.

* Running blkid /dev/sda3 returns

LABEL="SYSTEM" UUID=too long to type BLOCK_SIZE="4096" TYPE=ext4 PT type=dos partlable=primary partyuid=too long to type

I am using LUKS1 because I have read that GRUB only works with LUKS1 encryption. Any help or another route would be greatly appreciated. **Update:** I am still actively looking for a solution to encrypt an existing filesystem. If anyone has a different option I am willing to try that. My next idea is completely rebuilding the filesystem using a new hard drive, shuffling the data over. Will that sort of thing work? Still trying to get a good solution.

I had a dual-boot laptop setup with an encrypted BIOS. I then removed my Manjaro installation and deleted all of the partitions, including the Manjaro partition, which included my LUKS disk. When I now boot my laptop, I get the following error message:

error: no such cryptodisk found, perhaps a needed disk or cryptodosk module is not found.
error: disk 'cryptouuid/...' not found
Entering rescue mode...

I tried booting from a USB stick, but the rescue mode only allows me access (proc) and says that the file system is unknown if I try to boot from anything. Is there any way to fix this?

Ubuntu 22.04 can decrypt and read a BitLocker-encrypted device/partition without a need of installing any additional software (older releases can as well, perhaps, but I have not seen it) How can a block device or a partition be checked as to whether it is encrypted using **BitLocker** in a similar way a LUKS-encrypted device/partition can be verified using: sudo cryptsetup isLuks /dev/sda1 echo $? and sudo cryptsetup luksDump /dev/sda1 I have tried watching the dmesg log, checking with lsblk, but none of them seem to indicate the encryption type. My question is specific to Ubuntu 22.04, but answers for other distros will be helpful and are very welcome.

I would like to install new encrypted debian or mint on external flash disk while already having windows and ubuntu installed in dual boot on internal drives. For booting I use ubuntu's grub on internal drives and I worry about possibility of overwriting this grub after installation of debian/mint on external disk. How to avoid that ? It would be nice to have option in ubuntu's grub to boot into debian on external drive after pluged in that external drive. Can someone tell me how to achieve that ? Thanks in advance.

Recently I added a new disk to my computer. I had a free SATA slot, so nothing else changed. A few days after the disk was inserted the computer stopped to boot. I use Debian Bookworm. I have an encrypted partition which contains a LVM with several virtual partitions, including the root partition. Usually after Grub I am prompted for the password of sda2_crypt. Now Grub passes, then the computer hangs for a while and I land in something I think is BusyBox telling me some command timed out. I tried to run sudo grub-mkconfig but it did not help. I noticed that the boot fails only for a newer Kernel. Trying to boot the older kernel still works.

Are there any full-disk encryption schemes that can be done without an initramfs, rather getting the encryption key from the kernel cmdline? I know this sounds insecure, as an attacker could just read the bootloader files; but due this device's boot process, I have to manually enter the cmdline at every boot. I already compile my own kernels for this arm64 device, so custom kernel configuration options aren't a problem for me.

According to the guide at https://www.seagate.com/gb/en/support/kb/nas-os-4x-setting-up-volume-encryption-006007en/ there should be an option to encrypt a volume on devices running NAS OS 4.0. That option is missing from my LaCie 5big Pro although it is running NAS OS 4.0. According to the Seagate/LaCie support, the option is missing because my device doesn't support this feature. This is usually "a qualified truth", especially in the context of a Linux based OS. I assume the web based guide to prepare volumes is just an interface to a bunch of command line commands. I therefore asked the support for how to format and encrypt a volume from the command line but they refused to give me that information. The leads to a couple of questions 1. There should be a way to "eavesdrop" the command this guide executes in the background, shouldn't it? Maybe by following the process that way I could figure out how to prepare an encrypted volume. How can I "eavesdrop" this? 2. Anyone that knows how to do this from the command line? Or can perform (1) and figure it out? 3. Since NAS OS is Linux based it should be OSS and the source available somewhere (although not super easy to find, at least not for me) - any suggestions for how to figure out the answer to this question by reading the source (and find the source)? --- Edit: found the source code https://www.lacie.com/files/lacie-content/download/drivers/5bigNASPro_GPL_4.3.19.7.zip

I need encrypt esxi host by veracrypt or luks. Any idea how to done it? Can I install linux/windows first, than ESXI, than fix bootloader, than encrypt FDE in windows/linux by veracrypt? Best regards

I wanted to encrypt a flash drive but it didn't went well. Then I tried to remove the encryption but I am unable to do it. Here is some info: LUKS header information Version: 2 Epoch: 4 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: 9f4cbeda-4733-4aa9-873f-764705300bee Label: (no label) Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 512 [bytes] Keyslots: Tokens: Digests: 0: pbkdf2 Hash: sha256 Iterations: 100669 Salt: 59 c1 f4 ec 5a d2 17 ae 9f 2a 06 73 9c c2 b8 8e e8 02 0e 26 5c 8a 5a 33 a9 3e 98 ce 20 04 b8 c0 Digest: f2 f9 3b 7e 53 48 2b 24 05 4d c3 b9 42 4c 3b 1e ef 8a 1f f5 22 85 25 de fc f9 e4 02 ac 0f 8b 9d

I have a large LUKS2 device created with cryptsetup that holds an LVM2 with my root and other filesystems. The device is several TB in size and I don't have any others disks (or combinations of disks) that it could be intermediately copied to. I recently learned about DM-Integrity and that DM-Crypt has a built-in version of it that can be optionally enabled, and I would like to start using it with my encrypted devices. All of the documentation describes setting it up when the device is created, however, and the cryptsetup reencrypt function doesn't seem to mention it. I would imagine that the integrity info takes up more space than without it, but I have plenty of free space in that regard. I'm willing to settle for DM-Integrity on a separate layer, but would like to avoid it if possible.

I have an almost **fresh Kali linux installation** in an Hyper-V virtual machine. It is **configured with hard disk encryption** during installation. After some working days, I **reduced the amount of RAM** memory reserved for the VM, but when I boot up the reconfigured machine, the **password** used to decrypt the hard drive is **reported as invalid**. The reported error is:

: ERROR: sdaX_crypt: cryptsetup failed, bad password or options?

If I undo the configuration change the password is valid again... Does exist a relation between the LUKS decryption algorithm and the machine memory size? It doesn't have sense, in my opinion. Which can be the reason? Thanks in advance.

I have an Ubuntu system which boots from a small NVME disk using software encryption, TPM, etc. to mitigate against data loss in case of theft. The system is interfaced with customised PCIe hardware to record data (possibly very large quantities of data). The end-user interacts with the system via a web-interface and they are not intended to use any user accounts on the system or interact directly with it on keyboard/mouse/monitor. The system has several large drives which are intended to contain the data recorded by the system. These disks are able to be encrypted (or not) at the whim of the end-user. The large disks are SED capable (not OPAL compliant). When the SED password is set (hdparm --user-master u --security-set-pass "$password" /dev/...) we see that the disks are not accessible without password (hdparm --user-master u --security-unlock "$password" /dev/...) after they are removed and re-inserted to the host system. Excellent, the encryption is working - our data is safe (OK, safer). However, on power cycle the system pauses during the POST to prompt for a password for each drive (there are 12 of them!). This blocks the boot process. Obviously this is less than ideal for us as we have to connect a monitor and keyboard and tap in the authentication key for each disk. We don't need these disks to be unlocked at boot time. We can unlock them later (with the above unlock command) when the system is up and running and the system user asks for them to be mounted. Does anyone have any ideas about how we can prevent the password prompt from blocking the boot process?