Red Hat Bugzilla – Bug 159287
add rescue mode functionality to initrd images (patch included)
Last modified: 2014-06-18 03:34:58 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050512 Red Hat/1.7.8-1.4.1
Description of problem:
The attached patch to mkinitrd-4.2.15 adds a new function to nash and some added
code to the mkinitrd script. The new nash function (rescue) scans the kernel
command line for the word 'rescue' and execs a specified program if it exists
(usually this should be a shell).
The patch to mkinitrd adds a '--rescue' option. If this is specified, it copies
fsck, fsck.ext3 and busybox to the initrd, and creates symlinks to busybox for
all programs that are listed when busybox is run without arguments. It then adds
a function to the init script in the initrd image that calls 'rescue /bin/msh',
just before the root filesystem is mounted and the switchroot occurs.
The upshot of this is that if 'rescue' is specified on the kernel command line,
you'll get a shell toward the end of the initrd phase of the boot. Exiting the
shell will continue the boot process.
This patch is against the fedora version of mkinitrd. I've tested a backported
version of this patch against RHEL4 and it works, but have not yet tested it on
fedora, so it probably needs a little more work. I'm working on provisioning a
fedora box for testing it.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Actual Results: .
Expected Results: .
Created attachment 115029 [details]
patch to add rescue mode functionality to initrd images
Here is the patch described above. Still needs a little more work, but I wanted
to get it out here to begin consideration of it.
Created attachment 115043 [details]
patch to optionally add rescue mode to initrd images
Updated patch. Cleaned up the logic a bit and moved the 'Entering rescue mode'
message into nash instead of the script.
Created attachment 115145 [details]
updated patch, now cleans up initramfs a bit before switchroot
Here's a newer patch. In addition to the changes in the earlier patches, this
adds a simple "unlink" function to nash. The mkinitrd script now rm's
/bin/fsck* before the switchroot and then uses the unlink function to remove
This should mitigate the increase in initramfs memory profile that this patch
A better scheme would be to just wipe out the initramfs completely after the
switchroot, but I haven't figured out how to do that yet.
Created attachment 115146 [details]
another update, don't use wildcards when unlinking files
Wasn't sure how nash would handle wildcards with something like "rm
/bin/fsck*", so I changed patch to just unlink the files individually.
Jeffrey, looks like a very useful enhancement, which I would already like to see
in RHEL4 - if possible.
Peter, any comment on whether something like this might happen? I've always
thought this would be a useful addition.
changing to NEEDINFO
(In reply to comment #6)
> Peter, any comment on whether something like this might happen? I've always
> thought this would be a useful addition.
This is really the sort of thing <a href="https://fedoraproject.org/wiki/Features/FirstAidKit">FirstAidKit</a> should be doing.
I guess you could say that FirstAidKit will take care of this, but honestly it seems to be a significantly grander vision than just getting a simple way to get into an emergency shell in case things have gone awry with /.
atm FirstAidKit has no user documentation that I can see.
Right now I have an unbootable F10Alpha box where this might be really useful. There are no apparent error messages - see Bug 462475 - and I'd like to get in and poke around, see what I can see.
I interpret the existing FirstAidKit documentation to mean I would have to do significant setup to make it work, and I'm actually unlikely to do it as it seems to me a possible side effect is an automatically trashed system.
The problem I have right now is that applying updates has trashed the system - it removed the last known good kernel and left one dud kernel (despite more than one config change to the contrary).
This rescue mode might have helped me, it might not, but it was an easy thing to try.
Is there any good reason this should not be rolled out in F10? It can always be removed later if it's not used.
I've given it another 30 seconds' thought. Why not further enhance the installkernel script to (maybe optionally) make two initrd files and two stanzas in the bootloader configuration?
One can only choose this feature at boot time, and once booting's done it's no longer needed.
If I need rescue mode, I'd be quite happy to have a relatively large initrd with a full set of diagnosis/recovery tools. And not cut-down busybox versions either:-)
I imagine users might create a config file in /etc/sysconfig where the content of this recovery initrd is specified, and which RH/Fedora packagers would prime with some recommendations.
I see this as replacing the rescue CD for many, and it would be useful on systems that don't have CD drives (think zSeries).
I do not see it as a substitute for FirstAidKit, but a tool for technical folk who (think they) know what they're doing.
I'd prefer that you could generate a "rescue initrd" for a single known-working kernel (and have rpm add pinning support like apt so we can guarantee it's not removed ;o)) ... otherwise you end up generating lots of big images (and I tend to keep a lot of kernels around due to being bitten, repeatedly, by bugs that prove to have appeared "several revisions back" and not been noticed immediately).
Ideally (in my *ahem* humble *choke* opinion) "mkinitrd --rescue" or similar is the way to go ...
(apologies for the spam ... bugzilla shouldn't be sending everyone mail just 'cause I added my CC ...)
How about if we use busybox.petiteboot, that only adds 200k (uncompressed), and just *always* add it, that gives us ls, cat, mknod etc. So enough to do atleast some debugging and hopefully get the system booting. I really do not think of this as a rescue mode. but rather as giving people a shell so they can muck around of the initrd fails to find the root by itself.
I think this is the best we can do given that mkinitrd will be replaced in one or two Fedora releases.
So how does this sound?
Goodness...I opened this bug 3.5 years ago, and it seems to be getting some attention. :)
I don't know...
The arguments for keeping the initramfs small ring a little hollow when we're shoving porkers like plymouth and all of its images in. Frankly, given the typical size of RAM and disk space in modern computers, it seems like adding some useful tools during the boot process would be better use of resources than a bunch of graphical boot goop...
Honestly, I haven't looked at this in years. The patches I did when I originally opened this are pretty well bitrotted now and would need to be cleaned up anyway.
IMNSHO, the *best* thing here would be to dump nash and the other special purpose tools and simply build the initramfs around busybox. If the petiteboot version works for this, then that's fine too.
What exactly is going to be replacing mkinitrd? Perhaps the best solution is just to plan to live without this for now and plan to add some sort of rescue functionality in whatever is going to replace mkinitrd.
The mkinitrd replacement is dracut, and that will drop you in a shell when it cannot find the rootfs.
Closing this per comment #14.