[PKG-OpenRC-Debian] Bug#764564: Bug#764564: openrc: fail to boot when encryption + lvm are present

[Ritesh Raj Sarraf]

Thanks to the folks on #openrc, I was finally able to root cause this bug.


In file /lib/cryptsetup/cryptdisks.functions

                 # if there's already a udev-triggered job running for this
                 # device, wait for it to finish, then re-process to confirm
                 # that it's started successfully.  In the general case this
                 # will just be a no-op, but we don't want to defer to the
                 # other job entirely because this is the fallback for 
fixing
                 # up any ordering-dependent decrypting.
                 while status cryptdisks-udev DEVNAME="$dev_match" 2>&1 
| grep -q 'start'
                 do
                         sleep 1
                 done

Which leads to.....


[....] + echo -n Starting early crypto disks...
Starting early crypto disks...+ log_action_begin_msg_post Starting early 
crypto disks
+ :
+ mount_fs
+ local point
+ MOUNTED=
+ egrep -v ^[[:space:]]*(#|$) /etc/crypttab
+ read dst src key opts
+ dev_match=UUID=ae658322-236d-489a-8a9c-371a369873ec
+ [ ae658322-236d-489a-8a9c-371a369873ec != 
UUID=ae658322-236d-489a-8a9c-371a369873ec ]
+ readlink -f /dev/disk/by-uuid/ae658322-236d-489a-8a9c-371a369873ec
+ dev_match=/dev/sda7
+ status cryptdisks-udev DEVNAME=/dev/sda7
+ grep -q start
+ sleep 1
+ + status cryptdisks-udev DEVNAME=/dev/sda7
grep -q start
+ sleep 1
+ + status cryptdisks-udev DEVNAME=/dev/sda7
grep -q start
+ sleep 1
+ + status cryptdisks-udev DEVNAME=/dev/sda7
grep -q start
+ sleep 1
+ + status cryptdisks-udev DEVNAME=/dev/sda7


Commenting the while loop solves the problem.


Should this be assigned to the cryptsetup maintainers ???


Ritesh




On Friday 10 October 2014 01:15 PM, Ritesh Raj Sarraf wrote:
> On Friday 10 October 2014 03:20 AM, Robbie Harwood wrote:
>> Don't think it's this, either.  I did not interrupt any part of boot in
>> order to get this failure; this failure happens*every time*.  It's
>> possible that the filesystem is read-only during boot here which would
>> cause failure, but I don't have a good way to check that.
>>
>>> >If you agree that this is the same bug, then I may close this one.
>> Unless you see something that I don't, I think this is a different bug.
>>
>
> I think you are hit by the same bug as me.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750559
>
> Unfortunately, I did not hear back from the maintainer or the upstream 
> dev on this one.
>
> -- 
> Ritesh Raj Sarraf
> RESEARCHUT -http://www.researchut.com
> "Necessity is the mother of invention."


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/openrc-devel/attachments/20141010/52a28439/attachment.html>