Created attachment 1510936 [details] rdsosreport Description of problem: After a recent update, my Rawhide box no longer boots up to login. It reports the root partition missing which an encrypted partition along with /swap and /home. Version-Release number of selected component (if applicable): libxcrypt-4.4.0-2.fc30.x86_64 How reproducible: constant Steps to Reproduce: 1. Install Rawhide image released prior to November 2018 (use luks encryption on /home, /swap, and /(root) 2. Update 3. Actual results: Boot process enters emergency mode with error that / (root) partition cannot be found. This happens after entering the decryption passwords during the boot process. Expected results: the login screen or tty login Additional info: see attached
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.