I am trying to open a previously created raid1 on vero4k.
The two hard drives show up in blkid. After adding the array in the config file, I ran “sudo mdadm --assemble --scan --verbose”, for which I got:
mdadm: looking for devices for /dev/md/0
mdadm: no RAID superblock on /dev/dm-0
mdadm: no RAID superblock on /dev/mmcblk0boot0
mdadm: no RAID superblock on /dev/mmcblk0boot1
mdadm: no RAID superblock on /dev/mmcblk0rpmb
mdadm: no RAID superblock on /dev/data
mdadm: no RAID superblock on /dev/system
mdadm: no RAID superblock on /dev/boot
mdadm: no RAID superblock on /dev/instaboot
mdadm: no RAID superblock on /dev/misc
mdadm: no RAID superblock on /dev/crypt
mdadm: no RAID superblock on /dev/tee
mdadm: no RAID superblock on /dev/rsv
mdadm: no RAID superblock on /dev/recovery
mdadm: no RAID superblock on /dev/logo
mdadm: no RAID superblock on /dev/env
mdadm: no RAID superblock on /dev/cache
mdadm: no RAID superblock on /dev/reserved
mdadm: no RAID superblock on /dev/bootloader
mdadm: no RAID superblock on /dev/mmcblk0
mdadm: unexpected failure opening /dev/md0
So, I decided to run “sudo service mdadm-raid restart”:
systemd[1]: Stopping LSB: MD array assembly…
mdadm-raid[1487]: Stopping MD arrays…failed (no MD subsystem loaded).
systemd[1]: Starting LSB: MD array assembly…
mdadm-raid[1490]: Assembling MD arrays…failed (failed to load MD subsystem).
Finally we see the problem by running “sudo modprobe raid1”:
modprobe: FATAL: Module raid1 not found.
I suspect the kernel module is not included in the kernel compilation for the vero 4k.
How wrong am I?
No. The raid was created on another system where I was using it.
I am not sure if this is a recent issue or not since it is the first time I am trying to use mdadm in Vero 4K.
If you can, please add the MD modules to the next kernel update.
Unfortunately I have another request: cryptsetup. I can now open the raid, but I can’t open the LUKS partition because the kernel module is not available.
I have checked your vero364-000-add-kernel-config.patch and it has:
+# CONFIG_DM_CRYPT is not set
If you can, please enable it.
Alternatively, please direct me to somewhere I can understand how to compile and flash vero 4k, so that I am not nagging you all the time.
You’ve paid for a device and in turn, contributed to the further development of OSMC. It’s absolutely no problem for us to make these changes. These changes may also benefit users in the future.
I’ve now made the necessary change for you and this is now ready for testing.
Thanks a lot for doing this.
I updated and dm-crypt is loaded. Unfortunately I still get an error message:
device-mapper: reload ioctl on failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/md0.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).
After looking at the kernel config I found:
+# CONFIG_CRYPTO_XTS is not set
Possibly it is enough to enable this… If you could do so, I can quickly test and get back with results.
osmc@osmc:~$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 157918 iterations per second
PBKDF2-sha256 100824 iterations per second
PBKDF2-sha512 77101 iterations per second
PBKDF2-ripemd160 135125 iterations per second
PBKDF2-whirlpool 10336 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 25.6 MiB/s 29.0 MiB/s
serpent-cbc 128b N/A N/A
twofish-cbc 128b 31.3 MiB/s 36.9 MiB/s
aes-cbc 256b 20.8 MiB/s 23.0 MiB/s
serpent-cbc 256b N/A N/A
twofish-cbc 256b 31.8 MiB/s 38.5 MiB/s
aes-xts 256b 28.5 MiB/s 28.7 MiB/s
serpent-xts 256b N/A N/A
twofish-xts 256b 34.8 MiB/s 37.1 MiB/s
aes-xts 512b 22.8 MiB/s 22.5 MiB/s
serpent-xts 512b N/A N/A
twofish-xts 512b 35.2 MiB/s 37.2 MiB/s
On the Vero4K:
osmc@osmc:~$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 187245 iterations per second
PBKDF2-sha256 123652 iterations per second
PBKDF2-sha512 93622 iterations per second
PBKDF2-ripemd160 165913 iterations per second
PBKDF2-whirlpool 12272 iterations per second
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.
osmc@osmc:~$ sudo modprobe algif_skcipher
modprobe: FATAL: Module algif_skcipher not found.
So the Vero4K is a bit faster, but I think you’ll get poor LUKS performance unless you recompile OpenSSL to make use of the Vero4K’s crypto extensions (similar to AES-NI on Intel), or Sam builds an OpenSSL package that supports the Vero4K’s crypto extensions.
It’s a very useful feature of the Vero4K that you’re leaving unused. Supporting the hardware crypto extensions would also set it further above the Pi3 in terms of useful functionality.
Realistically, I’d guess OpenVPN would be near the top of the list but anyone tunnelling through ssh, eg rsync, would benefit. Not forgetting LUKS, of course.
Plus, as mentioned, IMO it would be a strong product differentiator.
Everything finally worked, thank you for the quick support.
Although I don’t need them, there seem to be some modules still missing:
$ sudo cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 204800 iterations per second for 256-bit key
PBKDF2-sha256 397187 iterations per second for 256-bit key
PBKDF2-sha512 150657 iterations per second for 256-bit key
PBKDF2-ripemd160 142469 iterations per second for 256-bit key
PBKDF2-whirlpool 20739 iterations per second for 256-bit key
Required kernel crypto interface not available.
Ensure you have algif_skcipher kernel module loaded.
Given the fact that there are space limitations aren’t really a factor for the Vero 4K, why not include most, if not all available kernel modules?
Any plans on getting onto kernel 4.x?
Interestingly enough I am using all of those: OpenVPN, RSYNC (on top of openvpn) and LUKS (src/dest of rsync data). I was using all of this before on RPI3 with raspbian. Granted, in my case, the processing power was never the bottleneck, the internet connection is. Also, since the USB is 2.0, we might have a bottleneck there as well.
In all truth, I believe the only real benefit would be if you would run a web server with SSL with many connections and traffic such as WebDAV.
While it would be nice to have crypto hardware acceleration, I fear stability problems. I have faced an issue in the past, where the codepath that made use of the crypto extensions was buggy (and detected at runtime) and crashed all the time if the extensions were present. So, this would have to be properly tested for the Vero4K CPU.
