Created attachment 6070 [details] rdsosreport.txt Mailing list thread where I brought this up 3.5 months ago: https://ml.mageia.org/l/arc/dev/2014-12/msg00043.html To reproduce: 1-forget to configure hostonly=no before HD dies 2-restore root filesystem from backup absent UUID onto labeled new HD partition 3-properly install grub to new HD 4-adjust fstab as necessary 5-adjust grub menu according either to new UUID or using valid root=LABEL= on cmdline 6-try to boot Actual results: 1-dracut rescue shell (see attached rdsosreport.txt) Expected results: 1-normal boot, without having to first rescue boot to build new initrd
Similar situation in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=1187007
CC: (none) => mageiaSource RPM: (none) => dracut
Looks fixed. On host g5eas, I eliminated hostonly="no" from both 50-mageia.conf and dracut.conf, leaving hostonly="yes" in 50-mageia.conf, before upgrading from 3.19.4 to 3.19.8, booted the new kernel OK, booted a different OS to change the / partition's UUID, and it still boots 3.19.8 if root=LABEL=<rootlabel> (or root=<device>) is included on bootloader cmdline.
Status: NEW => RESOLVEDResolution: (none) => FIXED
FWIW, there is also the (slightly new and under documented) hostonly_cmdline= variable. This variable embeds various command line switches into the initrd meaning that they are emulated if not explicitly provided. It shouldn't have caused this issue (the actual command line should override it always) but it might have been a factor. There was a recent update to dracut but it shouldn't have changed this (althouhg it did mess a little with cmdline stuff it should have only been for resume= argument parsing. But either way if it seems fixed, I won't complain :)