[PATCH] mkinitrd rescue mode

[Jeremy Katz]

On Thu, 2005-06-02 at 13:06 -0400, Jeffrey Layton wrote:
> On Thu, 2005-06-02 at 11:23 -0400, Jeremy Katz wrote:
> > This will have a relatively significant impact on the size of the
> > initramfs and thus on the memory profile.  Although I see it's not
> > enabled by default, which is at least a plus  It also won't handle
> > filesystems other than ext3.
> > 
> 
> This is just a proof-of-concept sort of thing at this stage. A better
> patch would detect the filesystem type of / and copy the fsck for that
> partition here. Then if you had other filesystems you could mount / and
> use those.

Note that only fsck.ext[23] are statically linked right now, which adds
some complications.

> This does increase the memory profile of the initramfs by about 1.5M.
> Isn't that memory freed after the switchroot occurs, though?

The impression I've gotten is that the memory isn't freed with initramfs
since you can't actually unmount the original rootfs.

> It's not enabled by default in this incarnation, but my preference would
> be that it is in a later one.

1.5 M additional overhead on all installs is less than ideal.

> > > This gives you some ability to troubleshoot booting problems, and gives
> > > the ability to do some rescue-type work without having to boot to the
> > > CD. This is a big plus for people that run boxes remotely and don't have
> > > easy physical access to them.
> > 
> > PXE, copying the pxeboot vmlinuz/initrd into your grub.conf and a few
> > other things can give you a way to boot rescue mode without having to
> > put in a CD.  If you're having to run mkinitrd with different command
> > line arguments, then you've already lost if you've really hosed your
> > system badly.
> > 
> > Honestly, I'd really rather see improvements to rescue mode than
> > something like this.
> 
> Both of those methods mean you'll be booting to a different kernel than
> the one that is giving you problems. The main reason I rolled this patch
> is to allow you to inspect (and possibly repair) the state of the system
> when you're having problems booting. If you update to a new kernel, and
> that kernel isn't detecting your drives correctly, then that is very
> difficult to troubleshoot once you boot to a rescue kernel.

If the kernel doesn't detect your drives correctly, then how exactly
does this let you "repair" things?  Most problems I've had are long
before the driver is going to screw things up.

Jeremy