Created attachment 985445 [details] rdsosreport.txt Description of problem: A system restored from backup (or cloned) with new filesystems fails to boot on UEFI because the EFI System partition can't be found by dracut-initqueue. Dracut should not be responsible for the EFI System partition mounting, systemd should be looking at fstab to find out what UUID to mount - and at least in the case of the EFI system partition whether to even mount it at all. Version-Release number of selected component (if applicable): dracut-038-32.git20141216.fc21 How reproducible: Always Steps to Reproduce: 1. Restore a system to a new disk, new files systems. 2. Update fstab to contain correct volume UUIDs 3. Copy required files to EFI System partition, update grub.cfg so it contains correct root=UUID= for the new volume. 4. Reboot Actual results: [ 188.409072] f21s2.localdomain dracut-initqueue[263]: Warning: /dev/disk/by-uuid/083A-7E6C does not exist This is the UUID for the old EFI System partition. Expected results: The system should boot. The equivalent task on BIOS is bootable. Additional info:
As mentioned initially in http://lists.freedesktop.org/archives/systemd-devel/2015-January/027216.html and elaborated beginning at http://lists.freedesktop.org/archives/systemd-devel/2015-January/027554.html with subject modification, I believe BIOS UUID is also baked in. I often clone BIOS partitions. After cloning, before attempting use of clone, I modify clone's UUID, volume label and fstab. Using initrds generated by dracut without any modification to default dracut configuration, (non-rescue) clone initrds have never yet succeeded to boot, only into an emergency shell, in spite of using kernel cmdlines that specify accurately via root= on cmdline the clone's device name, volume label or new UUID. At this point I don't remember if rescue initrds have worked. I typically regenerate via chroot of the clone.
can you please attach the output of: # dracut -f --debug
Chris? Me? Both?
Created attachment 987896 [details] dracut debug This is the same physical system as previously reported but it's a new installation of of Fedora 21+updates+kernel-3.19.0-0.rc7.git0.1.fc22.x86_64. The version of dracut is the same as reported. blkid reports EFI System partition /dev/sda2: UUID="0CAF-7498" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="79ddf34c-ff80-4026-b7c8-70464810c12f" The first instance of this UUID is line 7755. The section from 122782 to 122827 seem most relevant, which includes the check for whether it exists and if not to printf the warning that it doesn't exist.
Created attachment 991233 [details] rdsosreport.txt This happened to me again on a BIOS system, host gx150, F21, and apparently volume label rather than UUID: 1-cloned working installation on sda19 to sdb13 2-cloned same working installation on sda19 to sdb17 3-configured unique volume labels and UUIDs on the two clones 4-reconfigured bootloaders and fstabs on the two clones 5-booted sdb13 successfully 6-changed UUID and volume label on sda19 clone source 7-dracut emergency shell reports obsolete volume label from sda19 does not exist
Comment on attachment 991233 [details] rdsosreport.txt Disregard comment 5 and attachment. My bootloader reconfiguration was incomplete. sdb17 is working.
workaround for now, until I make it the default: # echo 'hostonly_cmdline="no"' > /etc/dracut.conf.d/no_hostonly_cmdline.conf
http://git.kernel.org/cgit/boot/dracut/dracut.git/commit/?id=38e217704a734cb6ff46d95a46ef04123a6b89e7
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.