Bug 1655603

Why do you think this bug is related to libxcrypt?  libxcrypt does not provide disk encryption services.

To me it looks like a problem with the cryptsetup package.  The actual problem might be introduced by updates to openSSL (Nov 9th) and/or libgcrypt (Nov 20th).

Adding tmraz to CC for further investigation.

Let's assign this to a package that provides the disk encryption setup.

(In reply to Florian Weimer from comment #1)
> Why do you think this bug is related to libxcrypt?  libxcrypt does not
> provide disk encryption services.

Sorry.  Any package having anything to do with "cryptography" that arrived with my last update was suspect.  I made a guess between libgcrypt and libxcrypt.  Sorry about that.

Reading the log, there is no problem with LUKS at all.

You have these boot parameters:
root=UUID=73c67e69-ea17-4cc2-b032-26a7845c0dc0
resume=UUID=81be95d7-7e26-4f6f-9656-e384da3c3df6
rd.luks.uuid=luks-6f0b53a7-e7cf-40c1-9fde-95eef0b60912

According to the log, the device with this LUKS ID is activated successfully but contains different filesystem than expected root UUID,
and the resume UUID is also not found (and systemd timeouts waiting for it).

/dev/mapper/luks-6f0b53a7-e7cf-40c1-9fde-95eef0b60912: LABEL="fedora" UUID="7966e01e-9c33-4112-86e2-82d71267e19c" TYPE="ext4"

So, my guess is that either your root and resume device is placed on a different device (there is another LUKS device), or you have wrong /etc/fstab in initramfs. Why it worked before I have no idea though :)

These devices are present (and apparently there are some windows partitions - is it dual boot?):
/dev/sda1: LABEL="Recovery" UUID="748C65D08C658E04" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="00fedfd2-36ab-4779-b1d7-1b1012fdf278"
/dev/sda2: UUID="0266-F989" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="d20c642a-8b72-4aff-bd12-5ab920330012"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="91846753-58d4-4da1-9aaf-71b62b18844f"
/dev/sda4: UUID="D2DE6920DE68FDDB" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="8091fc68-e13f-459b-a719-1a1aa270d61c"
/dev/sda5: LABEL="boot" UUID="6e57f0a7-abab-4b27-bf8c-2d127d78e10a" TYPE="ext4" PARTUUID="725e3784-2c2e-4983-8887-5c9a095bc9d9"
/dev/sda6: UUID="6f0b53a7-e7cf-40c1-9fde-95eef0b60912" TYPE="crypto_LUKS" PARTUUID="11fe3a0c-3bcf-4f9f-a590-041e13d31270"
/dev/sda7: UUID="64f60249-0f89-47f0-8031-7c082e952270" TYPE="crypto_LUKS" PARTUUID="bb543f86-a1a4-474f-b893-e104301a7893"
/dev/sda8: LABEL="swap" UUID="96f2d134-d89c-44b0-819a-17f84bbabdf2" TYPE="swap" PARTUUID="b757485c-9a95-4bdf-8e98-ddb2051c30da"
/dev/mapper/luks-6f0b53a7-e7cf-40c1-9fde-95eef0b60912: LABEL="fedora" UUID="7966e01e-9c33-4112-86e2-82d71267e19c" TYPE="ext4"

Try to replace kernel boot option with the second LUKS device and remove resume UUID

rd.luks.uuid=luks-6f0b53a7-e7cf-40c1-9fde-95eef0b60912

Anyway, this is not bug in cryptsetup but just some system misconfiguration.

(In reply to Milan Broz from comment #5)
> So, my guess is that either your root and resume device is placed on a
> different device (there is another LUKS device), or you have wrong
> /etc/fstab in initramfs. Why it worked before I have no idea though :)

Its one device. One hard-disk in one laptop
I didn't touch initramfs -- unless a package made alterations in the update.
This issue surfaces after an update ... one that involves packages from 28th November 2018.  Prior to that, the machine booted fine.

> These devices are present (and apparently there are some windows partitions
> - is it dual boot?):

Yes, its a dual boot

> 
> Try to replace kernel boot option with the second LUKS device and remove
> resume UUID
> 
> rd.luks.uuid=luks-6f0b53a7-e7cf-40c1-9fde-95eef0b60912
> 
> Anyway, this is not bug in cryptsetup but just some system misconfiguration.

What is altering the configuration then?
I have reinstalled Fedora Rawhide and applied updates prior to November 28,2018. It boots fine.  I will run "grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg" next then try applying the rest of the updated packages. 

so far:
$ cat /etc/fstab 

output:
#
# /etc/fstab
# Created by anaconda on Sun Dec  2 16:24:51 2018
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/luks-6f0b53a7-e7cf-40c1-9fde-95eef0b60912 /                       ext4    defaults,x-systemd.device-timeout=0 1 1
UUID=eaae2f5f-964f-4797-8690-4cc02a9404c5 /boot                   ext4    defaults        1 2
UUID=0266-F989          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
/dev/mapper/luks-64f60249-0f89-47f0-8031-7c082e952270 /home                   ext4    defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/luks-32ceb1a2-1d78-4b1d-bbad-409ec0a074c7 swap                    swap    defaults,x-systemd.device-timeout=0 0 0

see you on the other side :)

eh ... *cough* ... I can't seem to replicate the issue any more after the most recent update.  Perhaps I needed one or more of the newest packages.  I am immensely sorry for the trouble.