Error allocating crypto tfm

Arch Linux

You are not logged in.

#1 2021-01-09 19:47:30

Crypto: Error allocating crypto after system update

I am hoping someone can help me. I’m afraid I may have lost all of my data since the drive is encrypted. I recently updated my system and upon reboot I am receiving «device-mapper: table: 254.0: crypt: Error allocating crypto tfm device-mapper: reload ioctl on failed: no such file or directory». The system is setup to use anubis chiper. Any ideas on what happened during the update? When I mount the boot partition, there is nothing there. It’s as if it was deleted.

#2 2021-01-09 20:04:14

Re: Crypto: Error allocating crypto after system update

Please post the pacman.log for the update. Are you sure you mounted the correct partition? The system loaded the kernel from somewhere.

#3 2021-01-09 20:11:26

Re: Crypto: Error allocating crypto after system update

I can’t access the pacman.log as the entire system is encrypted.

#4 2021-01-09 20:13:49

Re: Crypto: Error allocating crypto after system update

I tried mounting the encrypted partition separately, and I am receiving the same error. It appears something about the partition is damaged. so there goes 20 years of data. What the fuck could possibly have happened during an update to damage a partition?

#5 2021-01-09 20:18:21

Re: Crypto: Error allocating crypto after system update

Correlation is not causation.

Can you boot the falback initramfs?

Registered Linux User #482438

#6 2021-01-09 20:28:27

Re: Crypto: Error allocating crypto after system update

I cannot boot the fallback at all.

#7 2021-01-09 20:30:01

Re: Crypto: Error allocating crypto after system update

I have 3 different kernels installed. Zen, LTS, and regular. None are working and neither are the fallbacks. I can’t even load it using an archlinux bootable ISO. Is it possible support has been removed for anubis across all of the kernels?

#8 2021-01-09 20:39:33

Re: Crypto: Error allocating crypto after system update

What confuses me is that I cannot even attempt to use the same chiper and hash on the partition as if I were creating a new encrypted partition using dm-crypt from the latest bootable arch ISO. SOmething has definitely changed with support.

Источник

Error allocating crypto tfm

name : twofish
driver : twofish-asm
module : kernel
priority : 200
refcnt : 1
type : cipher
blocksize : 16
min keysize : 16
max keysize : 32

name : wp512
driver : wp512-generic
module : kernel
priority : 0
refcnt : 1
type : digest
blocksize : 64
digestsize : 64

name : sha512
driver : sha512-generic
module : kernel
priority : 0
refcnt : 1
type : digest
blocksize : 128
digestsize : 64

What could cause the «Error allocating crypto tfm» error other than missing algos in the kernel? Could this problem be caused by the fact I used a Debian package on a Gentoo system? As soon as I post this I’ll install TrueCrypt 6.0a from Portage and see if that works better.

Последний раз редактировалось: aryaniae (пн дек 01, 2008 10:15 am), всего редактировалось 1 раз Вернуться к началу

treysis
n00b

Зарегистрирован: 02 мая 2007
Сообщений: 15

Вернуться к началу

aryaniae
n00b

Зарегистрирован: 18 сен 2006
Сообщений: 40
Откуда: Sunnyvale, CA U.S.A.

Вернуться к началу

bgm_weber
n00b

Зарегистрирован: 27 фев 2008
Сообщений: 14

Вернуться к началу

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах

Copyright 2001-2023 Gentoo Foundation, Inc. Designed by Kyle Manna © 2003; Style derived from original subSilver theme. | Hosting by Gossamer Threads Inc. © | Powered by phpBB 2.0.23-gentoo-p11 © 2001, 2002 phpBB Group
Privacy Policy

Источник

Booting encrypted root partion fails after system update

I have a problem booting my Debian Linux server. After a system update, GRUB loads the initrd and the system should ask for the password, but it doesn’t. Instead, I get dropped to BusyBox. After trying to mount the encrypted volume manually with cryptsetup luksOpen , I get this error:

1 Answer 1

Your kernel lacks support for aes-cbc-essiv:sha256 . “Error allocating crypto tfm” refers to the kernel’s cryptographic subsystem: some necessary cryptographic data structure couldn’t be initialized. Your support for cryptographic algorithms comes in modules, and you have a module for the AES algorithm and a module for the SHA-256 algorithm, but no module for the CBC mode. You will not be able to mount your encrypted device without it.

If you compiled your own kernel, make sure to enable all necessary crypto algorithms. If your kernel comes from your distribution, this may be a bug that you need to report. In either case, there must be a module /lib/modules/2.6.32-5-amd64/kernel/crypto/cbc.ko . If the module exists, then your problem is instead with the initramfs generation script.

In addition to the cbc module, you need other kernel components to tie the crypto together. Check that CRYPTO_MANAGER , CRYPTO_RNG2 and CRYPTO_BLKCIPHER2 are set in your kernel configuration. Debian’s initramfs building script should take care of these even if they’re compiled as modules. As the crypto subsystem is rather complex, there may be other vital components that are missing from the initramfs script. If you need further help, read through the discussion of bug #541835, and post your exact kernel version, as well as your kernel configuration if you compiled it yourself.

You will need to boot from a rescue system with the requisite crypto support to repair this. Mount your root filesystem, chroot into it, mount /boot , and run dpkg-reconfigure linux-image-… to regenerate the initramfs.

Источник

berryboot enrypt destination drive #602

If I try to create a new encrypted drive or use my old encrypted drive I get the following error:

device mapper: table: 254:0 crypt: Error allocating crypto tfm
device mapper: reload ioctl on failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/sda2.
Check that kernel supports aes-xts-plain64 cipher (check syslog for more info).

Seems like the kernel does not support the required cipher. Can this be fixed or can I fix this myself?
This does only affect my raspberry pi 4b with the newest berryboot version for raspberry pi 4
My raspberry pi 3b works fine with the newest berryboot version for raspberry pi 3.

The text was updated successfully, but these errors were encountered:

Also running raspberry pi 4b
I am having the same issue. Happens right after I am prompted to enter the first passphrase. After I enter a passphrase and hit enter I get directed back to the Disk Selection Screen with an error (Error Formatting data partition (ext4)).
Attempting to try it again I can see the terminal log with the following text.

[ 2531.566322] device-mapper: table: 254:0: crypt: error allocating crypto tfm
device-mapper: reload ioctl on failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2.
Check that kernel supports aes-xts-plain64 cipher (check system log for more info).
Device /dev/mmcblk0p2 is not a valid LUKS device.

Thank you for any help!

I noticed that when doing an encryption on an older pi it prompts the formatting warning and asks you to respond with «yes». When I try the encryption on the pi 4 it goes straight to asking me to enter first passphrase.
Going to try and find more information on missing files/ directory.

Has anyone solved this? I used to use berryboot on my PI3’s to get encrypted sd cards, but I get the above error on the PI4.

I have not been able to get it to work through Berryboot. I was able to manually encrypt an sd card running on the PI4 using the walk-through on this link. https://github.com/johnshearing/PrivateKeyVault#setup-luks-full-disk-encryption

I am still trying to get the Berryboot to work becuase it’s a lot more convenient.

Has anyone solved this? I used to use berryboot on my PI3’s to get encrypted sd cards, but I get the above error on the PI4.

The kernel needs to be recompiled with support for the aes-xts-plain64 cipher. So I guess there is no easy solution, at least via berryboot. But the link from the previous poster provided a link for a solution without berryboot.

@maxnet i am also having this same issue on pi4

I’m also having the same issue. I’m also on raspberry pi 4.

I had the same problem when I used the downloaded zip file. However, it worked when I cloned the repo and build it myself. I believe the encryption was broken in the pi kernel when the package was build but it is fixed now.

@marcrossinyol , thanks for the tip. I’ll try this.

I confirm, it works when building berryboot manually.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Arch Linux

You are not logged in.

#1 2008-10-12 15:31:02

[partly SOLVED] problems booting encrypted raid (. add.with grub-gfx)

Since I managed to setup an encrypted system properly I am now about to do the same with 2 identical fresh disks and simple raid1-mirroring (no lvm). This is the layout:

while md0, md2 und md3 are encrypted. These are the given wikis: raid mkinitcpio luks, installation media is the archlinux-2008.06-core-i686.

Setting the system up was no problem — creating the md-arrays, then encryption, then installation. Anyhow, booting up is always ending like this:

Meanwhile I succeeded in booting porperly with adding the specific filesystems into the MODULES=line in /etc/mkinitcpio.conf though that shouldn’t be necessary because of the filesystems-hook. This was very fine, because I was beeing able to tune up my installation with X-stuff, DE, office-proggies and all.
Then I liked to have a more colorful boot-screen and installed grub-gfx; still booting normally, but no splashimage was showing up. Then I added «raid1» into the MODULES=-line, and from now on booting always hangs!

Nevertheless it’s no problem getting into my system using the installation-cd and doing this:

I’ve been trying alot with disabling hooks in grub, reinstalled the normal grub, reinstalled the kernel, building initrd’s, changing mkinitcpio.conf-settings,and checking the output of # mdadm -D —scan >>/etc/mdadm.conf. Well, /etc/mdadm.conf is always the same (ARRAYS, UUIDs) except of additional metadata-stuff:

which appeared again as ignored errors while biulding the initrds and booting (actually the manpage just says it’s the defult version of mdadm). Again: mdadm -Q -D /dev/mdX and mdadm -E /dev/sdX don’t show any complications, so I deleted this metadata. And of course belonging to how many arrays are actually set up, so many ARRAY-lines appear in mdadm.conf (with the same UUIDs than before, so I left all of the original working ARRAYs). Finally I even reinstalled the system two times.

Maybe something of interest: # grub-install doesn’t work:

, but installing grub within its shell into any of the harddrives’ mbr does.

OK, here’s some more data:

— the actual /proc/partitions contains as well all sd[a b]X and all md[0 1 2 3], but also loop[0 1] and only (1) dm-0 (because I actually mounted only /dev/mapper/root), I guess this is still OK.

I don’t know what to do anymore Another combination of hooks or modules.
So I hope somebody has got a proposal or the solution.

Last edited by nexus7 (2008-10-16 20:28:21)

we are Arch .
you will be assimilated!
resistance is futile!

#2 2008-10-13 19:08:31

Re: [partly SOLVED] problems booting encrypted raid (. add.with grub-gfx)

I don’t think the problem depends neither on grub or grub-gfx, therefor I changed the thread’s topic.

Probably it is the order of the hooks and/or modules. I just have built another initrd with an additonal dm-mod and without filesystems like this:

Same output

— kernel panic at boot

results again into

Followed by thus using 1:

hey great. it WORKS

. but I guess my mkinitcpio.conf is somewhat overloaded

Will it still work after putting it on diet. And what’s about installing grub-gfx again.
I think I’ll have to go to sleep and to dream about it first

Last edited by nexus7 (2008-10-13 20:41:27)

we are Arch .
you will be assimilated!
resistance is futile!

#3 2008-10-16 19:11:57

Re: [partly SOLVED] problems booting encrypted raid (. add.with grub-gfx)

After fumbling around a lot with the configs and building another dozen of initrds with

and booting them up I got a final solution!
The gist of the matter is including dm-mod in the MODULES-line of /etc/mkinitcpio.conf, though the basic system had been set up with modprobe dm-crypt for creating the encrypted partitions, and I don’t use lvm as well.
Additionally, there must not be a line CRYPTO_MODULES=»blah» at all, otherwise you’ll end up within the passphrase-looping shown above!

Let’s have a look how an ordinary boot up then looks like:

(The keymap-hook is optional for people like me who use another than the US-keyboard; it must be before the encrypt hook.)
You may notice then as well the absence of

while everything is running fine if you’d enter the correct password.

Finally, to speed up booting noticably and to suppress the harmless but annoying warning about missing padlock drivers at the same time, it is not necessary to load tons of modules explicitly (though it’s not harmful) — just two of them are sufficient! This is a brief listing of my actual /etc/mkinitcpio.conf’s contents:

So, if you use aes-encryption it’s enough to use either the aes-i586- or the aes-generic-module, even with a sha-enrcyption of swap. As said before, logging into your machine will succeed without that modules, but then that warnign appears. If you use other or additional methods then you’ll probably also need to specify other drivers.

I don’t know if it is necessary or even possible to shorten this config (it’s your turn to find this out ), but with the right passphrase booting this raid is almost as fast as light!

Hurray, the main part of my problem is now solved!
Another intention for this thread has been about how to get to work grub-gfx properly with this raid; it is booting smoothly, but no spalshimage is showing up

But I’d like to have one — noblesse oblige — and Arch is noble!
. and I ilke eyecandy.

So here’s the /boot/menu.lst:

The reason therefor is probalby this:

Grub could only be installed within its shell:

Any proposals?
Or should I give grub-gfxmenu a try.

Last edited by nexus7 (2008-10-17 08:29:07)

we are Arch .
you will be assimilated!
resistance is futile!

Источник

Adblock
detector

Your kernel lacks support for aes-cbc-essiv:sha256. “Error allocating crypto tfm” refers to the kernel’s cryptographic subsystem: some necessary cryptographic data structure couldn’t be initialized. Your support for cryptographic algorithms comes in modules, and you have a module for the AES algorithm and a module for the SHA-256 algorithm, but no module for the CBC mode. You will not be able to mount your encrypted device without it.

If you compiled your own kernel, make sure to enable all necessary crypto algorithms. If your kernel comes from your distribution, this may be a bug that you need to report. In either case, there must be a module /lib/modules/2.6.32-5-amd64/kernel/crypto/cbc.ko. If the module exists, then your problem is instead with the initramfs generation script.

In addition to the cbc module, you need other kernel components to tie the crypto together. Check that CRYPTO_MANAGER, CRYPTO_RNG2 and CRYPTO_BLKCIPHER2 are set in your kernel configuration. Debian’s initramfs building script should take care of these even if they’re compiled as modules. As the crypto subsystem is rather complex, there may be other vital components that are missing from the initramfs script. If you need further help, read through the discussion of bug #541835, and post your exact kernel version, as well as your kernel configuration if you compiled it yourself.

You will need to boot from a rescue system with the requisite crypto support to repair this. Mount your root filesystem, chroot into it, mount /boot, and run dpkg-reconfigure linux-image-… to regenerate the initramfs.

Страницы: [1]   Вниз

0 Пользователей и 1 Гость просматривают эту тему.

Страницы: [1]   Вверх

Answer 229 (100.0% helpful)

The kernel doesn't have support for the cipher that was asked for. This could be due to a missing module (ciphername.ko, for example serpent.ko) for the cipher, or that the cipher was not included when the kernel was configured.

If the problem occurs during the boot process, the module is probably missing from the initrd.img (the initial ram file system loaded at boot time) corresponding to the kernel version and set up by the boot loader.

Answer 553 (100.0% helpful)

This config works for me, found out that adding x86_64 aes solved the problem, though I didn't use aes-cbc-essiv:sha256

# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_ECB is not set
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_AES is not set
CONFIG_CRYPTO_AES_X86_64=y
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_TEST is not set
# CONFIG_CRYPTO_HW is not set

Answer 679 (100.0% helpful)

modprobing dm-crypt, aes, cbc, sha256, and blkcipher were the final straws for me on this one (actually, it was aes_generic, sha512, sha256_generic, cryptomgr.  YMMV); that and making sure that my cryptsetup was the built in the same way as my kernel (for a gentoo system, this entailed re-emerging cryptsetup after doing a kernel rebuild)

Answer 895 (100.0% helpful)

Remember to have chaininiv.ko, rng.ko and krng.ko modules available.

Answer 938 (100.0% helpful)

If you're using truecrypt - you need to either use this :- 

--mount-options=nokernelcrypto

or TrueCrypt>>Settings>>Preferences>>System Integration and checking the box for "Do not use kernel cryptographic services" 

or possibly recompile your kernel to use whatever crypto routines were selected for the volume you're trying to mount.

Answer 955 (100.0% helpful)

adding LRW and XTS (in addiction to the modules for the encryption algorithms choosen for the volume) worked on my gentoo whithout the need of the --mount-options=nokernelcrypto flag for truecrypt.

[*] Cryptographic API --->
 .....
  <*> LRW support
  <*> XTS support
 .....

Answer 233 (83.33333% helpful)

If you use aes-cbc-essiv:sha256 as cipher you need the modules dm-crypt, aes, cbc, sha256, and blkcipher in the initial ram disk (added with i.e. --with=cbc when using mkinitrd).

Answer 455 (66.666664% helpful)

Well, in my case there was not loaded cryptomgr module. I'd think cipers are dependent on it but clearly it is not the case. I have module autoloading turned off and I've read that it would load it.