View previous topic :: View next topic |
Author |
Message |
Nuvola n00b
Joined: 01 Nov 2013 Posts: 9
|
Posted: Sat Nov 02, 2013 2:49 pm Post subject: Risolto [Problema] dm crypt sotto gentoo |
|
|
Ciao ragazzi,
procede la configurazione del mio sistema gentoo, che spettacolo *.*
Ho un hardisk cifrato con luks che volevo aprire anche sulla mia nuova gentoo, ma ho dei problemi, vediamoli insieme:
Installo quanto segue:
[ebuild R ] sys-fs/cryptsetup-1.4.3 USE="nls udev (-selinux) -static -static-libs"
Eseguo:
#cryptsetup luksOpen /dev/sdb1 nome_hd
Enter passphrase for /dev/sdb1:
device-mapper: reload ioctl on temporary-cryptsetup-2022 failed: Invalid argument
Failed to setup dm-crypt key mapping for device /dev/sdb1.
Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).
Failed to read from key storage.
Dal kernel mi son mossa abilitando quanto segue:
Da Device Drivers / Multiple devices driver supporto (RAID and LVM) -> Device Mapper support + Crypt target support + Device mapper debugging support.
Successivamente da Cryptographic API ho abilitato supporto per AES cipher algorithms + CBC support + SHA224/256 digest algorithm.
Bon, fatto cio', ricompilato ma il problema persiste.
Sicuramente mi saro' persa qualche pezzo per strada! Idee? Consigli? Come potrei muovermi al meglio per risolvere il problema?
Grazie anticipatamente a tutti e sopratutto a coloro che avranno voglia di dare un'occhiata al post e di aiutarmi
EDIT:
General setup --->
[*] Initial RAM filesystem and RAM disk (initramfs/initrd) support
[*] Enable loadable module support
Device Drivers --->
[*] Multiple devices driver support (RAID and LVM) --->
<*> Device mapper support
<*> Crypt target support
[*] Block Devices --->
<*> Loopback device support
[*] Cryptographic API --->
<*> SHA224 and SHA256 digest algorithm
Inclusi anche questi ma sempre stesso problema.
Last edited by Nuvola on Sat Nov 02, 2013 8:50 pm; edited 1 time in total |
|
Back to top |
|
|
sabayonino Veteran
Joined: 03 Jan 2012 Posts: 1008
|
|
Back to top |
|
|
Nuvola n00b
Joined: 01 Nov 2013 Posts: 9
|
Posted: Sat Nov 02, 2013 6:44 pm Post subject: |
|
|
Ciao, grazie per la risposta.
sabayonino wrote: |
riavviato ? o caricati i moduli ?
|
Si certamente!
Eh, ho seguito proprio quel documento per sapere cosa abilitare dal kernel...
Questo e' quello che succede:
# cryptsetup --debug luksOpen /dev/sdb1 hd
# cryptsetup 1.4.3 processing "cryptsetup --debug luksOpen /dev/sdb1 hd"
# Running command luksOpen.
# Locking memory.
# Allocating crypt device /dev/sdb1 context.
# Trying to open and read device /dev/sdb1.
# Initialising device-mapper backend, UDEV is enabled.
# Trying to load LUKS1 crypt type from device /dev/sdb1.
# Crypto backend (gcrypt 1.5.3) initialized.
# Reading LUKS header of size 1024 from device /dev/sdb1
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Activating volume hd [keyslot -1] using [none] passphrase.
# dm status hd OF [16384] (*1)
# Interactive passphrase entry requested.
Enter passphrase for /dev/sdb1:
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-1989
# Udev cookie 0xd4de7e5 (semid 65536) created
# Udev cookie 0xd4de7e5 (semid 65536) incremented to 1
# Udev cookie 0xd4de7e5 (semid 65536) incremented to 2
# Udev cookie 0xd4de7e5 (semid 65536) assigned to CREATE task(0) with flags DISABLE_SUBSYSTEM_RULES DISABLE_DISK_RULES DISABLE_OTHER_RULES (0xe)
# dm versions OF [16384] (*1)
# dm create temporary-cryptsetup-1989 CRYPT-TEMP-temporary-cryptsetup-1989 OF [16384] (*1)
# dm reload temporary-cryptsetup-1989 OFR [16384] (*1)
device-mapper: reload ioctl on temporary-cryptsetup-1989 failed: Invalid argument
# <backtrace>
# Udev cookie 0xd4de7e5 (semid 65536) decremented to 1
# Udev cookie 0xd4de7e5 (semid 65536) incremented to 2
# Udev cookie 0xd4de7e5 (semid 65536) assigned to REMOVE task(2) with flags DISABLE_SUBSYSTEM_RULES DISABLE_DISK_RULES DISABLE_OTHER_RULES (0xe)
# dm remove temporary-cryptsetup-1989 OFR [16384] (*1)
# temporary-cryptsetup-1989: Stacking NODE_DEL [verify_udev]
# Udev cookie 0xd4de7e5 (semid 65536) decremented to 1
# Udev cookie 0xd4de7e5 (semid 65536) waiting for zero
# Udev cookie 0xd4de7e5 (semid 65536) destroyed
# temporary-cryptsetup-1989: Processing NODE_DEL [verify_udev]
Failed to setup dm-crypt key mapping for device /dev/sdb1.
Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info).
Failed to read from key storage.
# Releasing crypt device /dev/sdb1 context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 5: Failed to read from key storage.
Non riesco a capire perche'.
Se ovviamente metto l'hd su un'altra macchina riesco ad aprirlo senza problemi con la medesima procedura... quindi son sicura che non dipenda dal dispositivo di per se!
Buh ..
EDIT:
Cioe', io sto mettendo in dubbio ogni cosa lol, non so se so cretina io o succedono robe strane... mi sono limitata a ricompilare nuovamente il kernel togliendo e rimettendo i moduli d'interesse, riavvio per l'ennesima volta e funge, praticamente senza cambiare nulla! Cioe' bo!! Non riesco a capire come sia possibile una cosa del genere, finalmente (inspiegabilmente) funziona... |
|
Back to top |
|
|
sabayonino Veteran
Joined: 03 Jan 2012 Posts: 1008
|
Posted: Sun Nov 03, 2013 9:20 am Post subject: |
|
|
Nuvola wrote: | Ciao, grazie per la risposta.
Cioe', io sto mettendo in dubbio ogni cosa lol, non so se so cretina io o succedono robe strane... mi sono limitata a ricompilare nuovamente il kernel togliendo e rimettendo i moduli d'interesse, riavvio per l'ennesima volta e funge, praticamente senza cambiare nulla! Cioe' bo!! Non riesco a capire come sia possibile una cosa del genere, finalmente (inspiegabilmente) funziona...[/b] |
Gentoo ti mette alla prova psicologicamente _________________ LRS i586 on G.Drive
LRS x86-64 EFI on MEGA |
|
Back to top |
|
|
djinnZ Advocate
Joined: 02 Nov 2006 Posts: 4831 Location: somewhere in L.O.S.
|
Posted: Sun Nov 03, 2013 12:45 pm Post subject: |
|
|
Alcuni pacchetti dipendono dal kernel e non da kernel-sources (come ifconfig ed ovviamente tutti quelli che installano moduli kernel) questo è il punto da tenere sempre a mente ed è bene partire da una configurazione valida, quella di default del kernel non lo è. Ti ho suggerito la "via maestra" se puoi preferisci andare a farfalle per i prati solo per avere la soddisfazione (da mentecatti IMHO) di lanciare una sequenza di comandi invece di uno solo ed abilitare le giuste opzioni una alla volta.
Fai pulizia nella configurazione ed evita di mettere modulare quello che puoi avere builtin.
Code: | MODVERSIONS=y
MODULE_SIG=n | se vuoi evitare problemi con i pacchetti che installano moduli kernel ma resta, a mio modestissimo avviso, una soluzione da bimbiminkia se non usi strani driver proprietari che ti ci costringono; una ragione per sconsigliare di ablitare la prima e per mettere in guardia dalla seconda c'è ed è scritta chiaramente. _________________ scita et risus abundant in ore stultorum sed etiam semper severi insani sunt
mala tempora currunt...mater stultorum semper pregna est
Murpy'sLaw:If anything can go wrong, it will - O'Toole's Corollary:Murphy was an optimist |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|