Yes this is kernel bug.
Kernel tries to autoload drivers for crypt accelerators (here VIA Padlock) but
such device is not avalible on that system.
The message is benign, sw implementation is used instead.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I am not sure if anyone from Ubuntu will even respond here, but I
checked upstream code and provided logs (btw thanks for them, very
usefull here).
What happens here is:
- system is fully udev managed, both userspace and kernel are recent enough
- according to logs, something during udev event
Please can Ubuntu upgrade to released version of cryptsetup (curently 1.1.2)
and do not rely on old beta version here?
All these problems should fixed there.
See bug 594365.
Thanks.
--
cryptsetup fails to build from source in linaro
https://bugs.launchpad.net/bugs/600179
You received this bug
On 07/14/2010 11:48 AM, Jaanus Rauk wrote:
Public bug reported:
Binary package hint: cryptsetup
I-m mounting a volume with following commands:
cryptsetup create crypt /dev/sda3
mount /dev/mapper/crypt /home
After cryptsetup upgrade to '2.1.1.2-1ubuntu1 (maverick)' the mount
doesn't
Btw if Ubuntu cryptsetup maintainers want to be backward compatible
in stable branch, I suggest reading package release notes and build
package with
configure --with-luks1-keybits=128 --with-plain-mode=cbc-plain
which set default to be fully compatible
(luks change is not problem here, plain
If blkid reports two signatures for one device (LUKS + ext3/swap) it is
bug (introduced when old cryptsetup did not wipe old signature).
You cannot solve it updating to new cryptsetup version but you can use
new cryptsetup version to fix it.
Read
On 09/06/2010 12:49 PM, SabreWolfy wrote:
I think has something to do with this via dmesg:
[ 479.983093] padlock: VIA PadLock not detected.
[ 480.056973] padlock: VIA PadLock Hash Engine not detected.
Don't have time to go down this rabbit hole. Downgrading back to Lucid.
Nope, this
Just to verify that internal cryptsetup defense against broken udev
rules work at least:
Can you post here output of dmsetup table of that orphaned
temportary-cryptsetup-* device?
(It should be already replaced by error segment to prevent keyslot access.)
--
[Lucid] [Regression] crypsetup
On 02/02/2014 03:20 AM, Brian Knoll wrote:
Public bug reported:
The SHA-1 hash has been, for years now, considered undesirable for new
installations. In Trusty, a new install using LUKS results in an
installation using SHA-1 hashing, as can be demonstrated by using the
following command:
On 03/15/2014 07:30 PM, cacahuatl wrote:
Looks like it's when it's trying to read from a socket, from what I can tell?
Socket is interface to kernel crypto API so it is just waiting for
output.
Anyway, we had few problems with benchmark code on fast machines but it
should be fixed in 1.6.4.
New 3.19 and 3.13 upstream stable kernel should have patches that should
allow old cryptsetup to run again, just backport these patches on top of
accept fixes (instead of revert).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Obviously it is wrong repository, upstream is
https://gitlab.com/cryptsetup/cryptsetup/ and mirror is
https://github.com/mbroz/cryptsetup
Please do not link random repos that some people create without any
communication with upstream...
Anyway, there were several changes to benchmarking, please
Volume (master) key digest is there only to verify validity of the key.
The digest iteration count is not relevant for the security of LUKS in normal
situation.
This iteration (slowdown) for digest will only help if the volume key
was generated by a flawed RNG, where brute-force is possible.
One day cryptsetup will link to liblkid, adding two "use friendly" things in
luksFormat
- warn if it detects something on disk before destroying it
- run wipefs to really destroy all the magic strings there (as Teo suggested)
So valid feature request also on the cryptsetup side, with the same
FYI libblkid/blkid detects LUKS for years already.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1713175
Title:
Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an
encrypted LUKS
Ehm, libcryptsetup in Ubuntu uses libcrypt? I do not think so.
(Crypto backend should be libgcrypt or openssl).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1742436
Title:
libcrypt being
Could you attach luksDump output?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1755322
Title:
logging in with luks2 converted encrypted disk only accepts keylsot #1
password
To manage
Thx. So, the keyslot 2 was not converted, but added later once device
was already in luks2 mode.
Anyway, all offsets and parameters look correct, I was able to recreate
the same sized device and it works for me (with upstream git, 2.0.2+).
Can you try from command line for each slot and
If you have properly installed device-mapper udev rules, cryptsetup is
internally synchronized to all symlinks and nodes creation (it should
never return only when udev is finished, that's why libdevmapper
internally uses semaphores and cookies per device).
Calling udev settle is just workaround
Look for "dmsetup udevcomplete" call in udev rules. This is the sync point when
libdevmapper continues. This must be the last call in udev chain rules related
to device-mapper devices.
(Run cryptsetup with --debug and you will see that sync point.)
Sometimes it is hidden by the fact that
20 matches
Mail list logo
