[CentOS] Lost path to root directory!

Fri Sep 22 12:40:04 UTC 2006
William L. Maltby <CentOS4Bill at triad.rr.com>

On Thu, 2006-09-21 at 23:17 -0400, Ted Miller wrote:
> William L. Maltby wrote:
> > On Sun, 2006-09-17 at 22:22 -0400, Ted Miller wrote: 
> >>William L. Maltby wrote:
> >>>On Sun, 2006-09-17 at 09:27 -0400, Ted Miller wrote:
> >>>
> >>>>I'll admit I am new to LVM2, but I have got myself in a bad spot.
> >>>>
> >>>>I renamed the LVM volume and volume group so that I can keep track of what
> >>>>is in them.  I have changed grub's menu.lst, /etc/fstab, and /etc/mtab, but
> >>>>somewhere else there is still something telling lvm that my root drive is
> >>>>on VolGroup00.  Where is it, and how do I convince it that
> >>>>VolGroup00/Volume00 (or whatever the defaults are) is now DriveC/Centos?  I
> >>>>suspect it may be hiding in initrd (compressed).
> > 
> >                                         ^^^^^^^^^^
> > I didn't repeat this since you spotted it already.
> > 
> > 
> >>>Yep. Fortunately, thats a cpio file. So uncompress, go to tmp make a
> > 
> >                                             ^^^^^^^^^^
> >
> > Did you remember to do the above? Based on your file name I suspect not.
> 
> No, I read too fast, <snip>

> >>>Then cpio it back up by using the -c param and compress it.
> 
> I tried to do this:
> find . -print -depth | cpio -oc | gzip >
> /media/centos/boot/initrd-2.6.9-34.EL.img
> 
> I got a file that looks the same as the original initrd (size, permissions,
> etc) but when I go to reboot, I get a message saying it can't find the init
> file >> kernel panic

This probably means you were not in the right directory level after you
did "cd xxxx". Maybe too "high" or "low" in the tree. To see where you
should have been, do the uncompress thing on one of the original CentOS
installed archives and pipe output to cpio using -itc (add a v if more
info is desired).

BTW, the "cpio -oc" can also have a "v" so you can see what it
processes. I think you might want to do some of this again for the
"entertainment value"!  ';-)

> 
> I also get this:
> file ini*
> initrd-2.6.9-EL.img:          gzip compressed data, from Unix
> initrd-2.6.9-EL.img.orig.TCM: gzip compressed data, from Unix, max compression
> 
> obviously mine isn't quite the same as the original.  I assume that it is
> probably some command line switch on the gzip command that makes the
> difference,

It used to be "--best". I *think* I recall seeing that a "-9" also did
that (bzip2 for sure, not sure about gzip - my man pages for it have
grown yellowed by age and disuse). Hmm... maybe it was "--best" added to
bzip2. Regardless...


>  but the info page is not at all clear about what I have to do
> to match the original.  One web page showed using gzip without any
> parameters, so I tried that, using this command line:
> find . -print -depth | cpio -ov > tree.cpio|gzip>initrd-2.6.9-EL.img
> 
> After several more tries, without success, trying to get the boot process 
> to recognize and use my altered rdinit file, I finally gave up and did an 
> "upgrade" from CD.  It trashed some things, but it did restore the install 
> so that it would boot.  I should have unchecked all packages when it asked 
> what I wanted installed.  That would have trashed less stuff.

Sorry it didn't work out. I have an LVM-based backup routine in the
final throes of completion (will actually get completed if the fallback
to the -34 kernel solves my 36 carefully tracked OOPS/panic that came
with the -42 kernel. I'll bugzilla it and be done with it and have time
to work on other things again). Naturally I had to ensure a decent
recovery process before developing the backup process. This exact
technique has saved my buns several times and is, in fact, an integral
part of being able to "instantly recover" by booting another HD when
primary HD has died or boot got lost or whatnot.

> 
> Ted Miller
> <snip sig stuff>

--
Bill