So it was possible to use one of the other keyslots to open the encryption?

No it wasn’t. Luckely the luks parition was still mounted on my system so im making a backup, recreating the partiiton and the restoring …

I found an article from RedHat on how to restore a luks1 partitions keys while it is still mounted but this isn’t possible with luks2 :/

Just to give you an update. The other keyslot was the key i added earlier for testing which i removed … So its time for me to copy over a lot of data to another system en recreate the luks volume. Thanks for your help!

:D while your steps were very clear i think i fked up.

cryptsetup luksAddKey /dev/mapper/raid /etc/crypttab.d/keyfile-data.bin --new-key-slot 1 gave: Device /dev/mapper/raid is not a valid LUKS device.. I assume this is a typo from your end since /dev/md0 is my luks volume. But altering this gave me: slot is already in use kind of error.

That can be explained since i tested something simular like you suggested earlier. Afterwhich i removed my key i generated and added to the volume. Then i did cryptsetup luksRemoveKey /dev/md0.

Now when i try to add it i get No key available with this passphrase.

I don’t have enough knowledge about cryptsetup to know what excactly i did wrong.

Do you by any change have an explaination?

In case this is usefull:

[root@nfs-rocky-1 ~]# cryptsetup luksDump /dev/md0
LUKS header information
Version:       	2
Epoch:         	6
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	485df758-6cec-49e3-aceb-438aaaedc833
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 4096 [bytes]

Keyslots:
  1: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  4
	Memory:     1048576
	Threads:    4
	Salt:       17 c5 ff 7f b9 10 43 41 16 5a c8 28 44 b9 df 64
	            a8 1d 40 41 9f a1 70 85 34 06 52 8d ba 29 bd ef
	AF stripes: 4000
	AF hash:    sha256
	Area offset:290816 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
  2: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  12
	Memory:     1048576
	Threads:    4
	Salt:       64 97 db 49 f1 18 b9 57 3b 02 53 37 b3 11 8e 44
	            71 d1 70 b2 b9 58 4c db e2 6b 36 95 7c dd d2 be
	AF stripes: 4000
	AF hash:    sha256
	Area offset:548864 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 105703
	Salt:       ae ac f1 9f df 47 27 9e 64 28 52 53 9a 9b cd 77
	            74 15 66 f6 8b 3c bd f4 29 dc f1 b1 c5 15 3b f6
	Digest:     07 5f 2f 6b d3 c5 bf b6 54 58 5e b4 44 df 8c b8
	            2b da fa 5c 40 a5 89 cc 0e 3b 70 69 57 d5 7c f5
[root@nfs-rocky-1 ~]#

Is the /etc/crypttab.d path that you are using specificly chosen or can it be whatever? This path doesn’t exists on my system and online i don’t see any mentions of it.

Thanks for your response!

I will give it a try. Have a great rest of your day!

path is part of the http protocol. Most firewalls only parse the first couple layers (ethernet->ip->tcp/udp), not http as well, unless they do deep package inspection. Idk if openwrt/banip has functionality

I don’t think openwrt can do this. Im running k3s with nginx as ingress but the issue is it doesn’t see the actual ip but rather the ip of the container so i can’t use nginx to block countries.

That is what i currently have setup but cert-manager is giving me a headache and not working correctly so im looking into http instead since its easier to setup

Oh that is actually a great idea thanks!

Very valid point.

Im actually running k3s on it so im not looking for any NAS specific OS. But if i picked a more general OS like fedora this issue might not have appeared. The reason i picked Alpine is since everything is running in containers i don’t need any fancy OS i just need to install k3s. But apperently Alpline can cause some issues :D

Oh i just did ethtool -I eth0 and now it does show up as being able to do 1G.

k3s-alpine-lap-6:~# ethtool -I eth0
Settings for eth0:
	Supported ports: [ TP	 MII ]
	Supported link modes:   10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Supported FEC modes: Not reported
	Advertised link modes:  10baseT/Half 10baseT/Full
	                        100baseT/Half 100baseT/Full
	                        1000baseT/Full
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Advertised FEC modes: Not reported
	Link partner advertised link modes:  10baseT/Half 10baseT/Full
	                                     100baseT/Half 100baseT/Full
	                                     1000baseT/Full
	Link partner advertised pause frame use: No
	Link partner advertised auto-negotiation: Yes
	Link partner advertised FEC modes: Not reported
	Speed: 1000Mb/s
	Duplex: Full
	Auto-negotiation: on
	master-slave cfg: preferred slave
	master-slave status: slave
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: external
	MDI-X: Unknown
	Supports Wake-on: pumbg
	Wake-on: d
	Link detected: yes
	Link Down Events: 2

As additional troubleshooting step i connected a know working device to the cable and was able to get 1GB

1. Im not 100% certain but I assume yes. Im trying to set it up as a nas. I just did setup-alpine, rebooted it and placed it in my basement. It should have services consistently running on it like sshd, k3s, … which become unavailable/available every few minutes.
2. Except for a keyboard that i used for troubleshooting no usb devices are connected. Should i attach an usb to see if it gets unmounted?
3. I notices this aswell which i quite strange since it is connected using a cat 5.e cable which should be able to do 1G. The cable is connected to a gigabit switch so that also shouldn’t be the problem. Asfar as cabling and switching is concerned everything should be able to do 1G

If you need additional information let me know!

I did the step i mentioned above but this wasn’t able to solve my issue :(

Thanks for your reply! This is a path i wanna look into. Just to confirm that im understanding correct running /sbin/modprobe -i r8169 && sleep 1 && /usr/sbin/ethtool --set-eee eth0 eee off and then rebooting is what i should try right?

Additional information im on Alpine 3.22.3. If this is an Alpine specific issue im able to switch distros but i prefer not to if it isn’t needed.

Civial war, can recommend

1. simply don’t run an exit node (from home)
2. run you relay no mether the type of a cheap vps that’s tor friendly

Oh alright, thanks a lot for your explanation. I learned a lot, im going with the operator route!

Thank you for your help!

Thanks for your response, could you explain what the advantages of an operator are in this example?

And what is the matter with the licensing? I never heard this issue before.

The link that you attached looks like it is for the pgvecto.rs extention instead of vectorchord.

Ceph is really cool, i also wanna use it in the future but i need way more disks for that :). Are those 25 worker nodes virtual machines? How did you attatch the disks to the ceph nodes?