You are not logged in.
Pages: 1
Topic closed
Just recently installed arch using the official arch installation script
It usually takes around 10 seconds after i insert the password, which is a really long time
systemd-analyze blame
879ms dev-mapper-luksdev.device
498ms lvm2-monitor.service
284ms systemd-journal-flush.service
261ms upower.service
200ms systemd-random-seed.service
160ms boot.mount
150ms user@1000.service
105ms udisks2.service
102ms accounts-daemon.service
80ms polkit.service
77ms systemd-udev-trigger.service
76ms systemd-logind.service
75ms systemd-fsck@dev-disk-by\x2duuid-CE2E\x2d8B5E.service
57ms systemd-journald.service
55ms systemd-resolved.service
55ms colord.service
53ms systemd-udevd.service
31ms systemd-modules-load.service
31ms systemd-tmpfiles-setup-dev.service
31ms systemd-networkd.service
29ms systemd-tmpfiles-setup.service
24ms gdm.service
20ms wpa_supplicant.service
19ms systemd-rfkill.service
16ms modprobe@fuse.service
15ms dev-hugepages.mount
14ms dev-mqueue.mount
14ms sys-kernel-debug.mount
13ms sys-kernel-tracing.mount
13ms kmod-static-nodes.service
12ms modprobe@configfs.service
6ms systemd-remount-fs.service
5ms systemd-update-utmp.service
5ms sys-kernel-config.mount
5ms systemd-sysctl.service
3ms user-runtime-dir@1000.service
3ms rtkit-daemon.service
3ms tmp.mount
2ms systemd-user-sessions.service
1ms modprobe@drm.service
1ms sys-fs-fuse-connections.mount
~ >>> systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @1.131s
└─multi-user.target @1.130s
└─systemd-logind.service @1.053s +76ms
└─basic.target @1.047s
└─sockets.target @1.046s
└─dbus.socket @1.046s
└─sysinit.target @1.042s
└─systemd-update-utmp.service @1.036s +5ms
└─systemd-tmpfiles-setup.service @1.003s +29ms
└─local-fs.target @1.001s
└─boot.mount @840ms +160ms
└─systemd-fsck@dev-disk-by\x2duuid-CE2E\x2d8B5E.service @759ms +75ms
└─local-fs-pre.target @756ms
└─lvm2-monitor.service @257ms +498ms
└─systemd-journald.socket @248ms
└─-.mount @228ms
└─-.slice @228ms
Any advice on how to fix it?
Last edited by Razer(x) (2021-05-26 09:08:28)
Offline
https://wiki.debian.org/BoottimeEntropyStarvation ("random.trust_cpu=on") ?
Offline
https://wiki.debian.org/BoottimeEntropyStarvation ("random.trust_cpu=on") ?
Tried adding it to Refind at boot, did not see a difference
Maybe too many iterations?
LUKS header information
Version: 2
Epoch: 3
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: ae6212f6-f2fe-4632-ab3f-904c127f0b71
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:
0: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2id
Time cost: 36
Memory: 1048576
Threads: 4
Salt: b6 28 d8 ae d9 65 44 a3 48 b3 0f 13 6c f0 1f 8d
ef f6 09 25 02 13 a8 15 c1 31 d7 32 1d ec 60 13
AF stripes: 4000
AF hash: sha512
Area offset:32768 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha512
Iterations: 154566
Salt: 35 a8 16 60 6e 2c d2 47 b2 a5 c6 c9 5f 64 87 45
71 6f a7 36 15 91 67 51 be a4 03 11 6c 55 90 fc
Digest: 82 72 3b 59 e4 04 1f d9 6f 5f cd 13 af 0c f3 21
a0 a7 49 01 02 a4 aa 45 4b de 1d c8 59 cb fb b5
2f 00 bc c0 e7 75 23 bd a2 5f 76 99 95 b4 08 c1
6b 2c 16 56 23 d3 52 05 51 40 73 d3 21 d3 7d 24
Offline
cryptsetup benchmark
Offline
cryptsetup benchmark
I must say, on the same system i have an Arch install that takes like 1 second to unlock, but i think they were done with different methods (there wasn't the official script at the time)
PBKDF2-sha1 2024277 iterazioni per secondo per chiave di 256-bit
PBKDF2-sha256 3530558 iterazioni per secondo per chiave di 256-bit
PBKDF2-sha512 1274089 iterazioni per secondo per chiave di 256-bit
PBKDF2-ripemd160 745786 iterazioni per secondo per chiave di 256-bit
PBKDF2-whirlpool 547845 iterazioni per secondo per chiave di 256-bit
argon2i 6 iterazioni, 1048576 memoria, 4 thread paralleli (CPU) per chiave di 256-bit (tempo richiesto 2000 ms)
argon2id 6 iterazioni, 1048576 memoria, 4 thread paralleli (CPU) per chiave di 256-bit (tempo richiesto 2000 ms)
# Algoritmo | Chiave | Cifratura | Decrifrazione
aes-cbc 128b 990,2 MiB/s 3301,2 MiB/s
serpent-cbc 128b 88,0 MiB/s 337,4 MiB/s
twofish-cbc 128b 168,2 MiB/s 343,2 MiB/s
aes-cbc 256b 769,4 MiB/s 2733,9 MiB/s
serpent-cbc 256b 90,3 MiB/s 338,1 MiB/s
twofish-cbc 256b 172,7 MiB/s 343,1 MiB/s
aes-xts 256b 2481,9 MiB/s 2463,0 MiB/s
serpent-xts 256b 326,0 MiB/s 326,9 MiB/s
twofish-xts 256b 333,6 MiB/s 338,6 MiB/s
aes-xts 512b 2103,1 MiB/s 2061,5 MiB/s
serpent-xts 512b 327,6 MiB/s 326,5 MiB/s
twofish-xts 512b 337,2 MiB/s 336,0 MiB/s
Last edited by Razer(x) (2021-05-26 13:48:33)
Offline
Digests:
0: pbkdf2
Hash: sha512
Iterations: 154.566
PBKDF2-sha512 1.274.089 iterazioni per secondo per chiave di 256-bit
Cipher: aes-xts-plain64
aes-xts 512b 2103,1 MiB/s 2061,5 MiB/s
Doesn't seem the be the issue.
Just recently installed arch using the official arch installation script
Does the script cleverly also encrypt the /boot partition?
Offline
Does the script cleverly also encrypt the /boot partition?
Boot partition seems to be in FAT format, so i suppose not (?)
Offline
lsblk; fdisk -l /dev/sda # assumes sda being the disk device.
Offline
sdb 8:16 0 111,8G 0 disk
├─sdb1 8:17 0 512M 0 part /boot
└─sdb2 8:18 0 111,3G 0 part
└─luksdev 254:0 0 111,3G 0 crypt /
Last edited by Razer(x) (2021-05-26 14:25:14)
Offline
No, is not :-(
If you boot a live system (eg. the install iso) and decrypt the drive from there, does that also take 10+ seconds?
Offline
No, is not :-(
If you boot a live system (eg. the install iso) and decrypt the drive from there, does that also take 10+ seconds?
Would it be the same if i decrypt it from the other Arch installation i have? If so i'll try
Offline
Yes… is that installation encrypted as well?
Offline
Yes just tried and it also takes 10 seconds
This is the other setup
LUKS header information
Version: 2
Epoch: 13
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID: c2686bd4-b950-4427-8379-10d9780e1e30
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:
1: luks2
Key: 512 bits
Priority: normal
Cipher: aes-xts-plain64
Cipher key: 512 bits
PBKDF: argon2i
Time cost: 5
Memory: 1048576
Threads: 4
Salt: b6 d5 fa 75 08 d9 31 27 2d f5 34 03 7f 48 90 52
d3 b0 9e dd 25 73 93 a2 ca d2 0a cb 6a a0 83 29
AF stripes: 4000
AF hash: sha256
Area offset:290816 [bytes]
Area length:258048 [bytes]
Digest ID: 0
Tokens:
Digests:
0: pbkdf2
Hash: sha256
Iterations: 211747
Salt: 29 ba c5 82 ee ef c9 3a 7e 94 fe b2 bd 3a 1d 9c
45 fb 0c 21 2b 90 52 92 8e 0d 57 4e fe ab f7 7b
Digest: d2 1a 85 14 da 39 8b ec 24 3f 0e ea c4 2f 55 f9
a9 ad ea 34 71 e3 32 14 45 4b 3e 33 4f 07 03 d2
Offline
From grub or also cross-wise (ie. is decrypting either drive from the other system faster)?
Did the other system use to decrypt that slow in the past?
What does your grub config look like?
Offline
From grub or also cross-wise (ie. is decrypting either drive from the other system faster)?
Did the other system use to decrypt that slow in the past?
What does your grub config look like?
Yes it takes something like 2 seconds to unlock the disk from the new setup
No it never did
I don't have Grub, i'm using Refind with default settings
Do you think it is an SSD issue? or just different encryption?
Offline
Decryption is fast from the other system, both systems decrypt slow from the bootloader, the other system (used to be the only one?) previously decrypted faster…
=> I think it's the bootloader, sol let's look at the refind config.
Offline
Decryption is fast from the other system, both systems decrypt slow from the bootloader, the other system (used to be the only one?) previously decrypted faster…
=> I think it's the bootloader, sol let's look at the refind config.
No it's not like this, decryption is the same on both systems, fast for the old setup drive, slow for the new one
Should i do a drive benchmark?
Last edited by Razer(x) (2021-05-29 11:28:19)
Offline
Hi, I also came across this issue and was wondering why it took so long while decrypting.
On a different arch install where I didn't use the archinstall script it took less time.
But it seems it is due to iter_time set to 10000ms in the archinstall script, while the default is 2000ms.
see: https://github.com/archlinux/archinstal … uks.py#L60
The default as of cryptsetup 2.7.1 is
Default PBKDF for LUKS2: argon2id
Iteration time: 2000, Memory required: 1048576kB, Parallel threads: 4
You can change the iter time with
cryptsetup luksChangeKey /dev/sdaX --iter-time <time in ms>
You can re-use the same password.
With
cryptsetup luksDump /dev/sdaX
you can see the changes.
Offline
Glad you found a solution. But please check the date of a thread next time before posting.
Closing this old thread.
macro_rules! yolo { { $($tokens:tt)* } => { unsafe { $($tokens)* } }; }
Offline
Pages: 1
Topic closed