You are not logged in.
HI
I'm trying to find out what the difference between the rd.luks and luks kernel parameters is.
I know in the docs for systemd-cryptsetup-generator say that:
"rd.luks.uuid= is honored only in the initrd, while luks.uuid= is honored by both the main system and in the initrd."
But I cannot for the life of me find out what "homored" actually means.
I though maybe it meant that rd.luks will open an encrypted partition during boot, but that it will not be open by the time boot is complete; where as luks will leave it open after boot is complete.
But it doesn't seem to mean that because I have tried both ways and the partition stays open either way.
I'm using systemd-boot with the following kernel parameters in /boot/loader/entries/OSTest2.conf:
options rd.luks.name=bd436e85-ec12-4337-b75f-f4df44f398c1=OSTest2
options rd.luks.options=bd436e85-ec12-4337-b75f-f4df44f398c1=password-echo=masked,no-read-workqueue,no-write-workqueue,allow-discard
options root=/dev/mapper/OSTest2 rw
options rd.luks.name=f181af42-5bf7-4f80-baf5-0d0cbe2c8c78=TestPart
options rd.luks.options=f181af42-5bf7-4f80-baf5-0d0cbe2c8c78=password-echo=masked,no-read-workqueue,no-write-workqueue,allow-discard
I don't have any entry for either root or TestPart in /etc/fstab or /etc/crypttab , and I don't have a /etc/crypttab.initramfs at all.
However, the system still boots and runs fine, and the TestPart is still open when I login regardless of whether I used rd.luks or just luks kernel parameters.
Can anyone tell me what is going on, and what the difference between them is?
I have read:
https://wiki.archlinux.org/title/Arch_boot_process
https://man.archlinux.org/man/bootup.7
https://wiki.archlinux.org/title/Systemd-boot
https://wiki.archlinux.org/title/Unifie … _Interface
https://wiki.archlinux.org/title/Dm-cry … figuration
https://man.archlinux.org/man/systemd-c … enerator.8
https://man.archlinux.org/man/systemd-c … rvice.8.en
and a hundred posts infected with AI slop...
What am I missing?
Many thanks for any help
I just thought... is there another crypttab that is only in the initrd/initramfs (what's the difference between those, too!?) and is it that rd.luks uses one and luks uses the other?
Last edited by Midnight Sun (2025-09-06 16:28:45)
Offline
Use rd.luks.uuid=<ROOT-UUID> if encrypted device to be unlocked include only root partition.
Use luks.uuid=<ROOT-UUID> and luks.uuid=<HOME-UUID> if encrypted device to be unlocked include both root partition and additional encrypted volumes like home partitions.
Last edited by solskog (2025-08-23 05:46:31)
Offline
solskog
I don't think that is correct because, as I said in my post, I've tried unlocking both a root and another partition with both the luks parameters AND the rd.luks ones; it didn't seem to make any difference either way.
Offline
rd.luks.uuid= is used in the kernel command line via GRUB during the initramfs phase.
You can use rd.luks.uuid= to unlock all encrypted partitions, You mentioned this on your first post.
After the initramfs phase, you can also use luks.uuid= in /etc/crypttab to define how the encrypted partitions are unlocked, which is managed by systemd.
But you can not use luks.uuid= to unlock encrypted partitioin via GRUB during the initramfs phase.
A less confusing statement would be like:
rd.luks.uuid= is honored at the initrd phase, while luks.uuid= is honored after the initrd phase."
Last edited by solskog (2025-08-24 09:09:12)
Offline
solskog
I don't think that is correct either, luks.uuid= is not a crypttab option, nor is it a valid crypttab field value.
Also, you can use luks= to open volumes during boot, even the root file system.
Note: I am not using GRUB, I'm using systemd-boot
I should have said that, sorry. I've edited my original post to show this
Last edited by Midnight Sun (2025-08-24 14:27:02)
Offline
I have also tried removing one of the luks flags from the kernel parameters (no-write-workqueue) and putting an entry in /etc/crypttab to try and set it later instead; to see if the rd.luks opened volume's flags can be altered, but the luks opened ones not.
testPart UUID=f181af42-5bf7-4f80-baf5-0d0cbe2c8c78 none no-write-workqueue
But this does NOT change the flags. (checked with "cryptsetup status testPart"). It will open the volume if I completely remove the luks lines from the kernel parameters and just rely on the crypttab entry.
Note: the system does boot and run fine, I am just trying to understand the difference between luks= and rd.luks= and what the line in the docs means when it says:
"rd.luks.uuid= is honored only in the initrd, while luks.uuid= is honored by both the main system and in the initrd."
Don't know what else to try.
Last edited by Midnight Sun (2025-08-24 18:06:40)
Offline
I don't think that is correct either, luks.uuid= is not a crypttab option, nor is it a valid crypttab field value.
Not "luks.uuid=" but "luks UUID=" in /etc/crypttab.
Setting up encrypted block devices using this file supports four encryption modes: LUKS, ...
EXAMPLES
Example 1. /etc/crypttab exampleSet up four encrypted block devices. One using LUKS for normal storage, ...
... ...
luks UUID=2505567a-9e27-4efe-a4d5-15ad146c258b
For systemd-boot entry:
# /boot/loader/entries/arch.conf
...
# This is root partition, which must be unlocked in the initrd.
options rd.luks.uuid=<ROOT-UUID>
# An encrypted /home, It doesn’t need to be unlocked in initrd, systemd-cryptsetup will unlock it.
options luks.uuid=<HOME-UUID>
From the boot sequence point of view:
1, "rd.luks.uuid=<ROOT-UUID>" initramfs unlocks root.
2, "luks.uuid=<ROOT-UUID>" Systemd-based initramfs can unlock root, classic mkinitcpio with encrypt can NOT unlock root.
rd.luks.uuid= is honored only in the initrd, while luks.uuid= is honored in the systemd-based initrd and later systemd-cryptsetup
Last edited by solskog (2025-08-26 00:48:49)
Offline
I don't think you have a very clear understanding of the topic at all.
Not "luks.uuid=" but "luks UUID=" in /etc/crypttab.
This is incorrect. The use of the word luks in the first field at the start of an /etc/crypttab entry is only setting a name, you might as well say 'foo' or 'bar'; it has nothing to do with the encryption being used. Maybe you are confusing it with the fourth field where 'luks' is a possible option, but not relevant here. That is actually in the crypttab manual you quoted.
# /boot/loader/entries/arch.conf
...
# This is root partition, which must be unlocked in the initrd.
options rd.luks.uuid=<ROOT-UUID>
# An encrypted /home, It doesn’t need to be unlocked in initrd, systemd-cryptsetup will unlock it.
options luks.uuid=<HOME-UUID>
This is not relevant to the question. I'm asking what the difference between them is. Your suggestion doesn't help resolve that, and in fact could adversely affect some set-ups, adding to the confusion.
It is important to be clear and accurate because people may come here for help and think that a suggestion they find is reasoned, when in this case it appears to be a guess.
From the boot sequence point of view:
1, "rd.luks.uuid=<ROOT-UUID>" initramfs unlocks root.
2, "luks.uuid=<ROOT-UUID>" Systemd-based initramfs can unlock root, classic mkinitcpio with encrypt can NOT unlock root.
This is also just adding to the confusion, not relevant to the question, and incorrect.
1: root is always unlocked in the initramfs phase because the following phase requires root so it can switch to it; that would not be possible if it were not open. In any case you can do that with either 'luks' or 'rd.luks'; so the question is what is the difference.
2: This is incorrect, encrypt can unlock root. In fact this method is shown in the Archwiki here: https://wiki.archlinux.org/title/Dm-cry … crypt_hook
A better man systemd-cryptsetup-generator would be like, wrote:
rd.luks.uuid= is honored only in the initrd, while luks.uuid= is honored in the systemd-based initrd and later systemd-cryptsetup
Again, this is not a clear statement of anything, it merely repeats what the documentation already says without clarifying anything. Also, it seems a bit confused about when cryptsetup is used.
It sounds like you are using Google AI and just guessing, but that could be really harmful to someone looking for quality information.
Offline
[SOLVED]
I have done some testing, and I think I have worked out at least some of the differences between luks and rd.luks. It does kind of explain this in the Archwiki, but I found the wording difficult to follow.
https://wiki.archlinux.org/title/Dm-cry … -generator
Warning
If you are using /etc/crypttab or /etc/crypttab.initramfs together with luks.* or rd.luks.* parameters, only those devices specified on the kernel command line will be activated and you will see Not creating device 'devicename' because it was not specified on the kernel command line.. This is because the luks.* or rd.luks.* parameters control which devices from the crypttab get activated. To activate all devices in /etc/crypttab do not specify any luks.* parameters and use rd.luks.*. To activate all devices in /etc/crypttab.initramfs do not specify any luks.* or rd.luks.* parameters.
This is what I found by trial, ex machina:
Whilst both 'luks' and 'rd.luks' kernel parameter options in .conf files in /boot/loader/entries/ can trigger opening both the root and other encrypted filesystems during the boot process, the choice between 'luks' and 'rd.luks' affects which OTHER sources can trigger opening of encrypted filesystems.
The other sources are TWO DIFFERENT versions of /etc/crypttab. One in the initramfs accessed in early boot, and the other on the root filesystem accessed in late boot.
Selecting Sources:
If the kernel parameter options include ANY 'luks' entries then neither the initramfs /etc/crypttab, nor the root filesystem /etc/crypttab will trigger any openings. Only the ones in the kernel parameter options will trigger (early boot phase).
But note, if the 'luks' entry doesn't assign a name or LUKS options (ie it is just a 'luks.uuid=' entry rather than a 'luks.name=' entry) AND the initramfs /etc/crypttab has an entry with the same UUID, then the name and options from there will be used anyway. This does not seem to be true for entries in the root filesystem /etc/crypttab; it didn't work for me anyway.
If the kernel parameter options include NO 'luks' options, but ANY 'rd.luks' options, then the /etc/crypttab in the initramfs will not trigger opening, but the root filesystem /etc/crypttab will (later boot phase).
If the kernel parameter options include NO 'luks' and NO 'rd.luks' options, then both the /etc/crypttab in the initramfs and the root filesystem /etc/crypttab will trigger opening encrypted filesystems.
Note: you can just edit entries in the root filesystem /etc/crypttab file and the changes will be found during boot. But the /etc/crypttab in the initramfs has to be regenerated after changes by placing your desired crypttab at /etc/crypttab.initramfs on the root filesystem and using the mkinitcpio command, which will incorporate it into the initramfs. This will overwrite your existing initramfs in the /boot directory, which, if you made any mistakes, may make your system unbootable. So maybe copy your existing one aside somewhere and have another way to boot the machine so you can copy the good one back into place if needs be.
see here for details:
https://wiki.archlinux.org/title/Dm-cry … -generator
https://wiki.archlinux.org/title/Mkinitcpio
Hope that helps someone.
Last edited by Midnight Sun (2025-09-07 10:59:18)
Offline