Booting into rescue mode stalls the boot for me.
I'm using lvm thin provisioning, and had to update dracut and run dracut -f to make my system boot (Common F20 Bugs).
How to update the initramfs for rescue mode?
Assuming the OP meant the "Fedora, with Linux 0-rescue*" entry in GRUB.
Currently by default dracut builds the initramfs with 'hostonly=yes' (check /usr/lib/dracut/dracut.conf.d/01-dist.conf). To make dracut always build a generic non-hostonly initramfs you'd need to install dracut-config-generic.
IIUC, one can build the *rescue initramfs image using /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh from the dracut-config-rescue package (which was installed by default on my box), e.g. this should build a rescue initramfs image for the currently running kernel, as root:
/etc/kernel/postinst.d/51-dracut-rescue-postinst.sh $(uname -r) /boot/vmlinuz-$(uname -r)
most likely you won't need to create a new grub.cfg.
EDIT: one caveat of executing /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh is that it adds a new "rescue" entry to /boot/grub2/grub.cfg (or /boot/efi/EFI/fedora/grub.cfg if it's a UEFI system) to the top of the boot entries list. So you'll have two "rescue" entries, you can edit grub.cfg and delete the top rescue entry altogether since it just duplicates the older one.
I agree that It's much simpler to just use the dracut command from the script, instead of executing the whole thing.
FWIW, the command he executed is basically what /etc/kernel/postinst.d/51-dracut-rescue-postinst.sh executes eventually.
Well, my problem was that after updating dracut, the initrd initramfs-0-rescue- wasn't re-generate with dracut --regenerate-all. I did not know about the -a switch to the dracut command. @Ahmad Samir 's answer pointed me to the code that generated that initrd in the first place, so I was able to find out how to do it. Why would I not accept this?
First and foremost, check out the list of dracut bugs if you're trying to troubleshoot issues on your system pertaining to dracut. Since dracut is (just as many other projects in Linux) in continuing development, you should keep track of recent changes in dracut at the Wiki/Features page and read the documentation of the project for more detailed information.
As noted in the Original Post, the common-bugs page of Fedora 20 has noted that a significant change in dracut (after F20 was released) had created a problem booting LVM Thin Provisioning installations of Fedora20. The common-bugs page also has notes on rescue instructions.
LVM has introduced thin provisioning technology, which provides greatly improved snapshot functionality in addition to thin provisioning capability. This change will make it possible to configure thin provisioning during OS installation. Current status
Targeted release: Fedora 21
Last updated: 2013-07-16
Tracker bug: [#998527](https://bugzilla.redhat.com/show_bug.cgi?id=998527)
Subsequently, LVM Thin Provisioning has been pushed back for the Fedora21 release, and an update of the dracut package (dracut-034-64.git20131205.fc20.1.x86_64) has been released and should be in the stable repositories of F20.
Finally, the Fedora Admin page has a list of linked Test Cases for the dracut package; such as
using a locally built dracut generated ramdisk image on system whose kernel doesn't provide a host-built dracut ramdisk.
yum install dracut dracut-generic
Create a dracut enabled kernel ramdisk image
dracut /boot/initrd-generic-$(uname -r).img $(uname -r)
Tell your bootloader to use the new dracut ramdisk
grubby --make-default --title "Test dracut" \
--add-kernel /boot/vmlinuz-$(uname -r) \
--initrd /boot/initrd-generic-$(uname -r).img \
--copy-default
Now reboot the your system
Alternatively, one can also produce a No-HostOnly generic image with
# dracut -N
however, that will overwrite the default initramfs image in the /boot/ directory and it won't be readily configured for grub; so, therefore, I suggest using the other forms of action and this last one only in very rare cases and if you really know what you're doing.
I removed my answer completely for no confusion, but to inform: I ran the commands in my Fedora 20 and everything seems to regenerated properly. Both commands, first for the no-hostonly img (rescue included) sudo dracut --no-hostonly --regenerate-all -f and then sudo dracut --hostonly -f /boot/initramfs-xxxx.img in order to regenerate the fast .img.
Hey, thanks for your detailed answer! I suppose HostOnly=tailored to my system, NoHostOnly=generic/portable? However, the thin provisioning problem wasn't actually my problem. I successfully re-generated initramfs-3.11.10-301.fc20.x86_64.img after updating dracut (I did this immediately after Installation because I knew of the problem).
I missed the command line for generating initramfs-0-rescue-deadbeefdeadbeef.img, because this ("rescue") wouldn't boot presumably for missing lvm thin provisioning support int it.
Yes, the dracut-034-64.git20131205.fc20.1.x86_64 package was released to resolve the issues with LVM thin-provisioning, as is noted in the dracut bug-report--which is also pointed to in the LVM thin provisioning bug-report.
Asked: 2014-01-31 04:44:28 -0600
Seen: 15,850 times
Last updated: Feb 01 '14
Ask Fedora is community maintained and Red Hat or Fedora Project is not responsible for content. Content on this site is licensed under a CC-BY-SA 3.0 license.
