Control: reassign -1 cryptsetup
Hello CryptSetup Maintainers, This bug was hit on openrc. The issue is very particular to users running LUKS / dm-crypt rootfs. The root cause is mentioned in this bug report. Can we have some insight on my that endless while loop is needed ? Can we drop it ? On 10/10/2014 02:07 PM, Ritesh Raj Sarraf wrote: > 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." -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature
