FS#18087 - [initscripts] 2010.01-1 unlocking encrypted devices fails

Attached to Project: Arch Linux
Opened by Igor Donev (gile) - Sunday, 31 January 2010, 14:15 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 30 January 2011, 18:09 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No

Details

Description:

Recently initscripts got upgraded to initscripts 2010.01-1

At boot time, just after the message "Unlocking encrypted volumes: home...failed"
There are bunch of error text that looks like output from cryptsetup.static being improperly called. It includes a bunch of what looks like option flags enclosed in square brackets and separated by spaces (i.e. [--usage] [--vl-verbose] )

Additional info:
* package version(s)
initscripts 2010.01-1

* config and/or log files etc.

I have this config files for the cryptsetup, if I comment them, there are no errors, and my drive is of course not unlocked.

/etc/fstab
/dev/mapper/home /home ext3 defaults 0 1

/etc/crypttab
home /dev/lvm/Home ASK

This has worked in the past, and it still does with the previous version of initscripts (I've downgraded).

I have kernel26 2.6.32.6-1 and use this setup on a thinkpad T60. Let me know if you need any additional info.

Steps to reproduce:
Probably having an encrypted drive.
This task depends upon

Closed by  Thomas Bächler (brain0)
Sunday, 30 January 2011, 18:09 GMT
Reason for closing:  Fixed
Additional comments about closing:  This was fixed a year ago, please open a new report instead of reopening.
Comment by Franck V. (franck_v) - Sunday, 31 January 2010, 15:35 GMT
I have a similar issue. It looks like /dev/lvm no longer exists on my system (but the devices are still available as /dev/mapper/lvm-* though).
It looks like this is happening because the following line was removed from rc.sysinit:
/sbin/lvm vgscan --ignorelockingfailure --mknodes >/dev/null
Comment by Igor Donev (gile) - Sunday, 31 January 2010, 20:14 GMT
I also use LVM, and had no issues with it. Only unlocking the encrypted lvm partition was an issue. lvm root and rest worked fine.
Comment by Igor Donev (gile) - Sunday, 31 January 2010, 21:10 GMT


So I get this with the new initscripts package:

:: Unlocking encrypted volumes: home..failed swap..ok mand failed: Error opening device: No such file or directory [FAIL]


The only difference (for the cryptsetup / lvm part) which I saw between the two versions is this line:

/sbin/lvm vgscan --ignorelockingfailure --mknodes >/dev/null

Which is missing in the latest package, but I am no expert in sysinit scripts, and I confirm that adding that line doesn't resolve the issue.

Online

Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 31 January 2010, 21:26 GMT
Not sure, but maybe because initscripts was moved to [core] without the rest of related packages: udev 150-1, device-mapper/lvm2 2.02.60, cryptsetup 1.1.0
Comment by Thomas Bächler (brain0) - Sunday, 31 January 2010, 22:16 GMT
Well, the LVM issue is due to that, until we move device-mapper with it, the /dev/vgname links will be missing. However, cryptsetup should otherwise work fine, there were no changes.
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 01 February 2010, 15:36 GMT
  • Field changed: Severity (Critical → High)
All related packages are now in [core]. Is fixed now?
Comment by Jon Gjengset (Jonhoo) - Sunday, 30 January 2011, 14:34 GMT
This problem is still present..
My system gets the exact same problem reported here, though it is fully updated.. See https://bbs.archlinux.org/viewtopic.php?pid=882610#p882610
Comment by Thomas Bächler (brain0) - Sunday, 30 January 2011, 18:09 GMT
I don't mean to be very rude here, but I have to. This issue was fixed a year ago, and while your symptoms may be similar, the problem is probably different.

Reopening an old bug report with nothing more than "I have same problem" is confusing and not helpful:
1) The old bug report gets filled with probably unrelated information.
2) I don't know the package versions and precise description of the bug. You claim it is "the same as above", but it probably isn't.
3) It is very hard to find out what "the same problem" means from an original report and a long list of comments.

I am closing this report again, please open a new one, summarize your problem again and state what package versions you use. And for the bug wranglers: Don't reopen bug reports that are years old, it's of no use to anyone.

Loading...