Cryptsetup doesn't support comments in lines not starting with an #.

Bug #185380 reported by Hannes
2
Affects Status Importance Assigned to Milestone
cryptsetup (Debian)
Fix Released
Unknown
cryptsetup (Ubuntu)
Fix Released
Low
Unassigned
initramfs-tools (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: cryptsetup

The documentation says: "Lines starting with "#" are comments, empty lines are ignored.". It doesn't cover the case with lines containing both filesystem information and comments. In fact, the maintainer scripts don't support this case at all.

Revision history for this message
Hannes (derhannes) wrote :

A similar behaviour is described here: http://ubuntuforums.org/showthread.php?t=672132

Revision history for this message
Reinhard Tartler (siretart) wrote :

The cryptsetup package correctly triggers an initramfs rebuilt, which does not finish. We need to find out what actually happens here. Please try to trace the steps initramfs-update does (running in sh -x or similar), and attach that output to this bug.

Changed in cryptsetup:
status: New → Incomplete
Revision history for this message
Hannes (derhannes) wrote :

Here's two straces of "apt-get install cryptsetup". One called with parameter "-f", one without.

The console output was:
----
Reading package lists... Done
Building dependency tree
Reading state information... Done
cryptsetup is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Setting up cryptsetup (2:1.0.5-2ubuntu2.1) ...
update-initramfs: deferring update (trigger activated)
dpkg: error processing cryptsetup (--configure):
 subprocess post-installation script killed by signal (Interrupt) <--- killed manually
Processing triggers for initramfs-tools ...
update-initramfs: Generating /boot/initrd.img-2.6.22-14-generic
Errors were encountered while processing:
 cryptsetup
----

I'm not used to strace, but to me it looks like line 1349 in the non-fork trace marks the beginning of the endless loop.

Revision history for this message
Hannes (derhannes) wrote :

The strace with forks is about 50MB please tell me if you want me to upload it, too.

Revision history for this message
Reinhard Tartler (siretart) wrote :

please avoid using apt-get to reproduce it. it just unnecessarily complicates the diagnostics.

work with /usr/sbin/update-initramfs directly instead.

Revision history for this message
Hannes (derhannes) wrote :

Sorry for being so slow. I really appreciate your comments on my report.

Unfortunately, I don't know how to reproduce the issue without APT. Can you tell me?

Here's, what "dpkg -l cryptsetup" says (perhaps this tells you in what state cryptsetup currently is on my system):
---
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
iF cryptsetup 2:1.0.5-2ubunt configures encrypted block devices
---

Revision history for this message
Reinhard Tartler (siretart) wrote :

The script that fails for you can be found in /var/lib/dpkg/info/cryptsetup.postinst. It is run by dpkg (which is itself invoked via apt-get) with the parameter 'configure'.

most probably the call to 'update-initramfs -u' is failing. Please try to run that command as root. Does it return?

If not, please add the parameter '-v' to it. Attach the output of 'update-initramfs -u -v' to this bugreport.

Revision history for this message
Hannes (derhannes) wrote :

"update-initramfs -u" does work fine. Takes about 25 seconds, then returns.

However, if I call " /var/lib/dpkg/info/cryptsetup.postinst configure" as root, it hangs. Please find the result of "sudo sh -x /var/lib/dpkg/info/cryptsetup.postinst configure 2>&1" attached.

Revision history for this message
Reinhard Tartler (siretart) wrote :

Ha, that's interesting.

your trace indicates that the postinst script is caught in an endless loop. It seems that you have a line in your /etc/crypttab that reads like this:

luks,retry=1,cipher=aes-lrw-benbi # ab Kernel 2.6.20 (gutsy, feisty): cipher=aes-lrw-benbi

IOW: a line that contains a comment. This is not supported by the postinst script, please insert a newline before the hashmark, or remove that comment.

Revision history for this message
Reinhard Tartler (siretart) wrote :

has nothing to do with initramfs-tools

Changed in initramfs-tools:
status: New → Invalid
Revision history for this message
Reinhard Tartler (siretart) wrote :

could you please attach your /etc/crypttab file that causes this problem to this bug?

description: updated
Changed in cryptsetup:
importance: Undecided → Low
status: Incomplete → Triaged
Revision history for this message
Hannes (derhannes) wrote :

Thanks a lot, Reinhard!

Moved the comment to a separate line (newline before "#") and the upgrade ("dpkg --configure -a", actually) went right through.
The /etc/crypttab file that caused this problem is attached.

Thanks again!

Hannes

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cryptsetup - 2:1.0.6-1ubuntu3

---------------
cryptsetup (2:1.0.6-1ubuntu3) intrepid; urgency=low

  * Parse comments in lines not starting with '#', LP: #185380
  * in cryptroot hook, don't rely on 'udevadm settle' to wait long enough
    for the cryptdevice to appear. Reimplement the busy waiting loop found
    while waiting for the root file system. Patch based on work by Swâmi
    Petaramesh. LP: #164044
  * debian/crypdisks.functions: call 'env' with full path. LP: #178829.

 -- Reinhard Tartler <email address hidden> Mon, 26 May 2008 22:12:32 +0200

Changed in cryptsetup:
status: Triaged → Fix Released
Changed in cryptsetup:
status: Unknown → Fix Committed
Changed in cryptsetup:
status: Fix Committed → 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.