Created attachment 884645 [details] Boot logs and grub2.cfg. Description of problem: After updating my system today I found what appears to be a problem caused by the kernel update kernel-3.13.9-200.fc20.x86_64. When the system is booted there is a very long delay of about 1 minute and 45 seconds before I received a message to: "Please enter passphrase for disk ...(luks-37ed....)" and the graphical entry field. After the entry of the passphrase the started-up continues and I am presented with the user login screen. The systems seem to have no other problems other than the abnormal start-up. From start of the boot to the login is over two minutes. I re-booted on the previous kernel and it boots normally. From start of boot to presentation of the passphase graphical entry is 1-2 seconds (with no "Please enter..." message). After entry of the passhrase the login screen appears in about 10 seconds. I booted on the problem kernel and escaped to the console and noticed that the long delay appeared to be a loop waiting for the passphrase. The problem is the failure to present the graphical entry field. The loop apparently times out and then you can enter the passphase. I removed the new kernel and then re-updated and got the same bad results. Version-Release number of selected component (if applicable): kernel-3.13.9-200.fc20.x86_64 How reproducible: It happens on every boot. Steps to Reproduce: Boot. Actual results: Boot takes over two minutes due to failure to present request for passphrase. Expected results: A boot time of 10-15 seconds with an SSD drive. Additional info: I have attached a boot log from a normal boot with the previous kernel and a boot log from the problem kernel. I also attached a copy of grub2.cfg.
What version of dracut do you have installed?
The following are installed. dracut-037-10.git20140402.fc20.x86_64 dracut-config-rescue-037-10.git20140402.fc20.x86_64 dracut-network-037-10.git20140402.fc20.x86_64
OK, that is the version impacted by a recently reported bug. Harald can reassign if necessary.
I'm not sure this is related to https://bugzilla.redhat.com/show_bug.cgi?id=1084766 if that's what you're thinking of, Josh, but it may well indeed be a dracut bug. Still, I have a system with an encrypted partition and haven't seen this bug on it; I have the right stuff on the cmdline so it isn't affected by 1084766, and I get the graphical encryption passphrase prompt on boot as expected. Reporter, can you post the contents of /proc/cmdline after a boot affected by the bug, and the output of 'dracut --print-cmdline'? Can you also try downgrading dracut to an older version - "yum downgrade dracut dracut-config-rescue dracut-network" should do the job - and reinstalling the affected kernel, and see if that 'solves' the problem, just to confirm the new version of dracut is the culprit? Thanks!
After reading comment 3, on April 11 I did the following: 1. I saved the image created with dracut 037. 2. I downgraded to the previous version of dracut. 3. I created an image with dracut 034. 4. I rebooted with no problems. I have had no problems booting since April 11. On April 12 dracut was updated to version 037. I have had no updates that would use dracut since it was last installed. Today: 1. I saved the initramfs-3.13.9-200.fc20.x86_64.img created with 034 on 4/11. 2. I rebooted with the 037 initramfs-3.13.9-200.fc20.x86_64.img saved on 4/11 and the BUG is back (this image was created on 4/9 when the kernel was last updated). [root@rosebud grub2]# ls -l total 40 -rw-r--r--. 1 root root 164 Nov 12 16:05 device.map drwxr-xr-x. 2 root root 4096 Nov 12 16:05 fonts -rw-------. 1 root root 6009 Apr 9 14:48 grub.cfg -rw-r--r--. 1 root root 1024 Apr 9 14:48 grubenv drwxr-xr-x. 2 root root 12288 Mar 3 17:20 i386-pc drwxr-xr-x. 2 root root 4096 Mar 3 17:20 locale drwxr-xr-x. 3 root root 4096 May 9 2012 themes I looked at bug 1084766 and it seems to be the same bug. I should have provided the steps on 4/11 that I did on 4/11 which cleared the problem. After boot on 037 initramfs: [bogwan@rosebud ~]$ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-3.13.9-200.fc20.x86_64 root=UUID=cd79d2e8-8295-4893-9bb9-a00628fad021 ro rd.md.uuid=0ddcd542:f1409c58:c44c77eb:7ee19756 vconsole.font=latarcyrheb-sun16 vconsole.keymap=us rd.md.uuid=5cbb22ec:84b59785:70521c17:3b93b41e rhgb quiet LANG=en_US.UTF-8 [bogwan@rosebud ~]$ su -c "dracut --print-cmdline" Password: rd.luks.uuid=luks-b9ce98fe-fd3f-4c94-84a5-690d0ece3c2d rd.lvm.lv=VG00/SWAP rd.md.uuid=cffcf9bc:0417594f:98dfecc0:672edd95 rd.md.uuid=5cbb22ec:84b59785:70521c17:3b93b41e rd.md.uuid=0ddcd542:f1409c58:c44c77eb:7ee19756 resume=/dev/mapper/VG00-SWAP root=UUID=cd79d2e8-8295-4893-9bb9-a00628fad021 rootflags=rw,relatime,seclabel,data=ordered rootfstype=ext4 I have raid consisting of two SSDs and one conventional drive. [bogwan@rosebud ~]$ cat /proc/mdstat Personalities : [raid1] md3 : active raid1 sdc3[2](W)(S) sdb3[1] sda3[3] 47184824 blocks super 1.2 [2/2] [UU] md127 : active raid1 sdc1[2](W)(S) sda1[0] sdb1[1] 1048512 blocks [2/2] [UU] md2 : active raid1 sdc2[3](W)(S) sdb2[1] sda2[2] 25164728 blocks super 1.2 [2/2] [UU] md3 is encrypted and is a LVM PV. [root@rosebud log]# pvscan PV /dev/mapper/luks-b9ce98fe-fd3f-4c94-84a5-690d0ece3c2d VG VG00 lvm2 [44.99 GiB / 5.99 GiB free] Total: 1 [44.99 GiB] / in use: 1 [44.99 GiB] / in no VG: 0 [0 ] [root@rosebud log]# vgscan Reading all physical volumes. This may take a while... Found volume group "VG00" using metadata type lvm2 [root@rosebud log]# lvscan ACTIVE '/dev/VG00/VAR' [20.00 GiB] inherit ACTIVE '/dev/VG00/HOME' [15.00 GiB] inherit ACTIVE '/dev/VG00/SWAP' [4.00 GiB] inherit [root@rosebud log]# ls /dev/mapper control luks-37ed608e-50bf-42dc-b820-69f3d05887f8 luks-b9ce98fe-fd3f-4c94-84a5-690d0ece3c2d VG00-HOME VG00-SWAP VG00-VAR I have a fourth conventional drive with an encrypted partition which is mounted from fstab at boot. /dev/mapper/luks-37ed608e-50bf-42dc-b820-69f3d05887f8 on /var/backups type ext4 (rw,relatime,seclabel,data=ordered) If you need any more info please let me know.
After another look at bug 1084766 I noticed that he has encrypted root. I do not have encrypted root.
Can you try with the scratch build of dracut I posted on https://bugzilla.redhat.com/show_bug.cgi?id=1084766 and see if that produces a 'working' initramfs too? Thanks!
Created attachment 887743 [details] Boot Log test http://koji.fedoraproject.org/koji/taskinfo?taskID=6751545 I installed http://koji.fedoraproject.org/koji/taskinfo?taskID=6751545. I created a new image dracut --force. I rebooted and it displayed the passphrase entry correctly. I find no problem with this fix. I have attached the boot log which looks completely normal to me, but sharper eyes my see something I don't.
Thanks very much for testing. It sounds quite a lot like you have another variant of 1084766, then, so I'll close this as a dupe. *** This bug has been marked as a duplicate of bug 1084766 ***