On Wed, Sep 7, 2016 at 1:00 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > On Wed, Sep 7, 2016 at 8:53 AM, Martín Marqués <martin.marques@xxxxxxxxx> wrote: >> 2016-09-07 11:01 GMT-03:00 Bruno Wolff III <bruno@xxxxxxxx>: >>> On Wed, Sep 07, 2016 at 10:36:29 -0300, >>> Martín Marqués <martin.marques@xxxxxxxxx> wrote: >>>> >>>> Hi all, >>>> >>>> Dependency failed for Cryptography Setup for luks-..... >>>> Dependency failed for Encrypted Volumes >>> >>> >>> Those sound like systemd messages. You probably need to find out which >>> dependency failed and that should be a big clueto which update broke things. >> >> Here's an oversite on my side: >> >> Warning: crypto LUKS UUID 9fe296b1-8aa9-4cd6-9868-b37e2720407b >> >> But looking at the /dev/mapper where the device is I see: >> >> /dev/mapper/luks-263bd743-5d1b-485b-9884-c3eda1a4d880 >> >> Looking at the /run/initramfs/rdsosreport.txt it's actually finding >> the device in the which I see in /dev/mapper, which is the correct >> UUID I have in /etc/fstab. >> >> So what is the UUID 9fe296b1-8aa9-4cd6-9868-b37e2720407b I see in the >> output from dracut? > > # blkid | grep 9fe296b1 > # sudo lsinitrd /boot/initramfs-4.7.2-200.fc24.x86_64.img | grep 9fe296b1 > > If the initramsfs really has any UUID in it, it's a bug. Do get more information from these failed boots, add this boot parameter: systemd.log_level=debug Post the resulting rdsosreport.txt somewhere, or you can sift through and find out a little more about why it's failing. There's something looking for a UUID that's not present, so we have to figure out what's asking for that UUID. Why this coincides with updates, I have no idea yet so far. There's no reason why a UUID would change with an update... well except.... Get a load of this weirdness. So I have a Fedora Server, with encrypted swap. It's using /dev/urandom at boot to get a new key everytime, so I don't have to plug in a passphrase at boot time. In the /etc/crypttab I'm using /dev/disk/by-id/wwn-<someserialnumberorportionthereof>-part5 to identify the exact partition. Works great. Then I did an update one day and boot starts failing waiting on this device that doesn't exist anymore. Guess what? The update changed how it was creating the /dev/disk/by-id/wwn- Before the update, it was bass ackwards, something like last 4+middle 4+middle 4 part 2+first 1 of the unique ID+the NAA+3 zeros (?). Whatever it was it was produced from the WWN but didn't match it exactly. After the update, it matches it exactly. So maybe you're using WWN somewhere? *shrug* -- Chris Murphy -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
