cryptsetup: failed to setup lvm device

Bug #151532 reported by Nick Barcet
24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

After setting up gutsy-server-am64.iso RC date 20071010 with crypted LVM, at each boot :
- enter the pass phrase during boot
--> message appears stating "cryptsetup: failed to setup lvm device"
but boot continues normally and everything seems fine...

Revision history for this message
Martin Pitt (pitti) wrote :

This is known and ugly, but only cosmetical. The cryptsetup initramfs scripts should not really attempt to manually set up LVM. udev does it all for us, in a much more robust and automatic fashion. The only thing cryptsetup initramfs needs to do is to read the configuration file to find out which physical device has the root partition and call luksOpen on it.

Changed in cryptsetup:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
secure bit (ahmad-hamad-777) wrote :

I have this problem in the ubuntu studio and once I see it the system stop loading, what should I do to rescure my data ? thank you

Revision history for this message
secure bit (ahmad-hamad-777) wrote :

luks never opened that partition, and I had to format the hard disk, I've lost all my important data !

Revision history for this message
bJXjLjEHIaWT0tFd (bjxjljehiawt0tfd-deactivatedaccount) wrote :

I can confirm this on an up-to-date hardy installation.

Kernel: 2.6.24-19-server
Architecture: amd64
Cryptsetup: 1.0.5

Indeed only cosmetical but irritating nonetheless.

Revision history for this message
Tore Anderson (toreanderson) wrote :

Still present in Intrepid alpha-2.

Tore

Revision history for this message
Kirit Sælensminde (kayess) wrote :

This is still happening in intrepid alpha 4 (IBM Thinkpad R61, 32 bit intrepid)

Revision history for this message
Chris Jones (cmsj) wrote :

I never saw this in hardy, but I see it after an Intrepid upgrade, both with and without usplash.

Revision history for this message
Dave Shaw (dave-shawr) wrote :

Agree with Chris, I use dm-crypt & LUKS with root on LVM inside the encrypted partition, and I see this on Intrepid (latest patches) with 2.6.27-2. Doesn't seem to have any negative effect mind :)

Revision history for this message
Dave Shaw (dave-shawr) wrote :

Secure bit could you elaborate on your luks not being able to open the partition problem? I'm using AES256-CBC-ESSIV with SHA-256 as the hash algo, and I have had no such pain.

Its purely cosmetic for me, as mentioned already.

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (5.6 KiB)

This bug was fixed in the package cryptsetup - 2:1.0.6-6ubuntu1

---------------
cryptsetup (2:1.0.6-6ubuntu1) intrepid; urgency=low

  * drop almost all ubuntu specific changes from the cryptsetup package,
    because they have been merged in debian. Thanks a lot!
  * merge from debian, remaining changes:
    - remove versioned build-depency on libdevmapper-dev, we are using a
      rather sophisticated loop for making sure the root filesystem appears.
  * debian/rules: fix location of ltmain.sh
  * don't exit usplash anymore in the init script. LP: #110970, #139363
  * Disable error message 'failed to setup lvm device'. It is harmless, and
    caused by the fact that the udev rules provided by lvm2 are setting up
    the lvm on their own. In debian the scripts here are responsible for this
    but obviously fail in ubuntu. LP: #151532

cryptsetup (2:1.0.6-6) unstable; urgency=high

  * Don't cat keyfile into pipe for do_noluks(). cryptsetup handles
    --key-file=- different for luks and plain dm-crypt mappings. This time
    really (closes: #493848). Thus again upload with urgency=high.

cryptsetup (2:1.0.6-5) unstable; urgency=high

  * Fix watch file to not report -pre and -rc releases as superior.
  * Remove the global var $SIZE from cryptdisks.functions again but keep the
    extended value checks.
  * Remove the udev rules file also in preinst, code taken from example at
    http://wiki.debian.org/DpkgConffileHandling. Thanks Marco d'Itri.
    (closes: #493151)
  * Remove duplicated configuration of --key-file in $PARAMS at do_noluks().
    (closes: #493848).
  * Invoke mount_fs() and umount_fs() in cryptdisks_start, add
    log_action_begin_msg() and log_action_end_msg() to both cryptdisk_start
    and cryptdisks_stop.
  * Copy fd 3 code from do_start and do_stop to cryptdisks_start and
    cryptdisks_stop to fix "keyscript | cryptsetup". (closes: #493622)
  * This upload fixes two RC bugs, thus upload with severity=high.

cryptsetup (2:1.0.6-4) unstable; urgency=medium

  [ David Härdeman ]
  * Make sure $IGNORE is reset as necessary, patch by Thomas Luzat
    <email address hidden> (closes: #490199)
  * Use askpass in init scripts as well (closes: #489033, #477203)

  [ Jonas Meurer ]
  * Don't copy_exec libgcc1 in cryptopensc initramfs hook, as it's already
    copied by copy_exec /usr/sbin/pcscd automaticly. Thanks to Evgeni Golov
    <email address hidden>. (closes: #490300)
  * Remove the udev rules file again as the relevant rules are now provided
    by dmsetup package which cryptsetup depends on.
  * Add splashy support to askpass, thanks to John Hughes <email address hidden>
    for the patch. (closes: #492451) The support is limited to cryptroot
    though, as splashy freezes for passphrase input dialogs from initscripts.
    Document that in README.Debian.
  * Now that askpass is used as keyscript for interactive mode, it's not
    necessary to set cryptsetup parameter '--tries=$TRIES' and TRIES=1 for
    interactive mode anymore in cryptdisks.functions.
  * Implement special treatment for random passphrases now that we use
    "--key-file=-" for all situations. Only necessary in do_noluks.
  * Fix the passphrase prompt string in...

Read more...

Changed in cryptsetup:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.