Ralph Shumaker wrote:
Ralph Shumaker wrote:
James G. Sack (jim) wrote:
Ralph Shumaker wrote:
Carl L wrote: ...
At the shell prompt # lvm # this gets you an lvm prompt
This did nothing in the fc7 install dvd except give me a new command
prompt (dead end for that path)...
Did nothing?? Not even "..command not found"?
Weird!
Nope. The command is there. Actually, it is a link to something
else, lvm.scan or somesuch (presently no easy way to check). But
even directly launching the one the link points to does nothing
except give a new command line. It's almost as if the program exits
so fast that you miss it even if you *don't* blink.
Hmmm. In fc4, lvm is *not* a link. The other one is lvm.static (in
fc4 and fc7).
Now, there was probably something else overlooked in Carl's
instructions.
When I boot Knoppix in order to poke around with my hard drive, I have
to run not only
vgscan
but
vgchange -ay
to "activate" the VG, before lvm will create its subdirectories in
/dev.
This is an example of one of the commands given by "help" that are
*not* clearly the one you want. I tried a couple of others, but not
this one. Thanks.
Thus lvm knows which and where.., but the dev-dir-links-stuff doesn't
exist until VGs are activated.
Then you can do the e2fsck, etc
And I did, but then I hit another roadblock:
$ cat /log
(Please note, I had to type the following copy from the screen myself.)
(I don't know those tricks to copy the standard out to a file.)
(Please disregard minor errors.)
-/bin/sh-3.00# e2fsck -f /dev/VolGroup00/Slash
e2fsck 1.37 (21-Mar-2005)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/VolGroup00/Slash: 174849/33718272 files (2.4% non-contiguous),
2439188/33701888 blocks
-/bin/sh-3.00# resize2fs -p /dev/VolGroup00/Slash 8G
resize2fs 1.37 (21-Mar-2005)
Please run 'e2fsck -f /dev/VolGroup00/Slash' first.
-/bin/sh-3.00#
WTF?!
(Well, I just had quite the experience! I finally got fc4 (my current
distro) working again (about 8 hours after I broke it :-) ).)
Seeing as how I hit dead ends everywhere I turned trying to shrink an
existing Logical Volume in lvm, I decided to play a little more with the
fc7 install environment, hopefully to gather more info.
(Except for brief and cryptic shorthand type notes of important details,
everything below is from memory, as best I can recall. Please disregard
minor errors.)
On a whim, I decided to try:
# lvm /dev/VolGroup00
No such command. Try 'help'.
# lvm -v
No such command. Try 'help'.
# lvm -help
No such command. Try 'help'.
# lvm help
No such command. Try 'help'.
(Eureka!!! This must be similar to a perl one-liner type of thing!)
(Carl, this should be of interest for you and your notes.) (I'm
grateful, because I would not easily have figured this out on my own.)
# lvm vgchange -ay
3 logical volume(s) in volume group "VolGroup00" now active.
(Hooray!!!)
# e2fsck -f /dev/VolGroup00/Slash
Superblock last write time is in the future. Fix<y>? no
(fc7 must have assumed that the hwclock is on UTC.)
pass 1
.
.
.
pass 5
...
# resize2fs -p /dev/VolGroup00/Slash 8G
(This is where the fc4 install environment choked.)
.
.
.
The filesystem on /dev/VolGroup00/Slash now 2097152 blocks long.
(Success!)
# lvm lvresize --size 8G /dev/VolGroup00/Slash
(Success!)
# lvm lvcreate --size 104G /dev/VolGroup00/fc7slash
(Failed.)
# lvm help lvcreate
(Cryptic and useful info.)
(Carl, you may want this for your notes as well.)
# lvm lvcreate --size 104G --name fc7slash VolGroup00
(Success!)
# mkfs.ext3 /dev/VolGroup00/fc7slash
# lvm lvcreate --size 2G --name fc7swap VolGroup00
(Success!)
(Couldn't remember how to format swap so decided to come back to it.)
(Failed at several attempts to slurp up the remainder for --name
fc7home, then decided to let the fc7 installation do that.)
(I'll chop up / better later.)
Proceeded with the fc7 installation, specifying filesystem layout.
Discovered (rather *re* - discovered) that /boot can *not* be in a VG
(even though I was going to continue to use the existing grub setup of fc4).
(Dead end since fc7 *refused* to allow me to proceed.)
How does one have more than 3 boot environments if you are limited to 4
primary partitions? (Or can /boot be on an extended partition?)
(Possible solution realized after I was all done. That solution is
mentioned near the end.)
(It's all a learning process with some pretty steep curves. And if you
don't travel the road often, the curves can be almost as treacherous the
next time.)
(The experienced may whince at this next part (or may chuckle with a few
memories of their own).)
(Hmmm, me thinks. The grub loader points to hd0,1 and I'm only using
three partitions.)
(I would not even have attempted this next part except that I have three
good backups of my data.)
So I resize2fs /dev/hda2 down to just a little more than it's currently
using. I figure, why not, since I'm likely to be using fc4 less and
less, and the usage size of my /boot *rarely* changes. I figure "Just
shrinking it, the grub loader *should* still be able to find it.".
But "fdisk -l" jars me with the realization that although I shrank the
filesystem on hda2, the hda2 partition was still the same size (and I
could think of no way to shrink it).
(Hmmm, me thinks. The grub loader points to hd0,1. What if I blow away
/dev/hda2 and recreate it just barely the size I need? Seems logical
that the new hda2 would also be hd0,1 so, why not?)
I copy (tar | tar (thanks to "grep tar < /root/.bash_history" for the
switches needed since man is not available here)) the files from hda2
(/boot partition) to /boot directory (where /boot partition is normally
mounted).
(IIRC, cd to source directory (so that source files will be ./filename
and won't recreate nested directories), then
"tar -cvf - . | tar -xf - -C /destination/directory/")
I blow away hda2. I recreate it, as well as hda4 (for fc7 /boot) whilst
I'm at it. (error reloading partition table, reboot.)
mkfs.ext3 /dev/hda2 (and /dev/hda4 while I'm at it)
(hda2 is 35M (just a tad more than it's using) and hda4 is ~67M (just in
case it needs a lot more space))
I copy (tar | tar) the files back.
I proceed with the fc7 installation, specifying its new /boot partition,
ignoring the warning about wanting 75M (hey, fc4 wanted 100M and used
about 30M) and getting the install to pick up the remainder of
VolGroup00 for LV fc7home (~15G).
I told fc7 to leave the boot loader alone.
I selected my packages and then let it rip.
I rebooted and was presented with:
boot CD-ROM:
boot CD-ROM:
GRUB _
(The first two lines are normal. But the third line was new.)
I booted fc4 rescue, but had no grub command, so could not touch the
boot loader.
I booted fc7 rescue. Same.
Knoppix was happy to oblige, but nothing I did there worked. (User
error, I think.)
(Hmmm, me thinks. Maybe I can boot fc4 rescue, avail myself of the
option to load the filesystem on /mnt/sysimage, and then avail myself of
the chroot option, then startx (in my regular environment), and email
kplug for help.)
Failure.
But on the bright side, the grub command now works.
grub> help
I set root, then I set kernel. I rebooted but no go. (Then I vaguely
remember that those settings are dynamic.)
I tried to remember how to reset the grub boot loader in the MBR but
couldn't.
grub> makeactive
grub> _
That didn't seem to do anything.
grub> help makeactive
Aha! Maybe that was my problem. "grub> makeactive". Reboot!
(grumble) Nope!
grub> help setup
Aha! Maybe that was my problem. Run setup. Reboot!
(grumble) Nope!
(Tried several other things, none working.)
Maybe try getting the bootloader to boot hda4 (fc7 /boot). Could not
find /boot/grub/grub.conf for file names, grub.conf not there.
ls /boot
(Interesting, fc7 could be booted either on xen or straight. Cool.)
(Hmmm, me thinks. Maybe I should just go ahead and rerun the fc7
install and give it the boot loader. Aha! I can get things back to
normal by doing that with fc4 install/upgrade!)
I run fc4 install/upgrade, choosing to upgrade the current fc4
installation, allowing it to update grub (hoping it wouldn't mess up
grub.conf (despite having a good backup of /boot)), and, since I used to
use yum to keep things updated until yum stopped working for legacy fc4,
I was hoping that it will allow me to deselect installing/upgrading any
packages (which it does not). It upgraded my Firefox, and my rhn-applet
(sp?) (which I had turned off long ago anyway), then updated the
bootloader. Nothing else. (whew!) Reboot!
Success! Now I'm back up, running in my comfortable environment.
fc7 is installed. I just need to make a grub entry for it. Later, when
I have my environment in fc7 set up, I'll switch the bootloader over to
that.
(Here's the realization that I probably could have avoided the majority
of the problems above.)
Hmmm, it occurs to me that because of the difference in the names, I
probably could have combined fc4 and fc7 boot files in /dev/hda2 (before
I shrunk it). Although splash.xpm.gz (from fc4) in grub/ would get
replaced by a much bigger file of the same name (from fc7).
Hmmm, I just remembered that when I copied the files back from /boot
(directory) to /boot (partition) that I never wiped /boot (directory)
clean. Could that have been part of the problem? Can /boot (partition)
be mounted on /boot (directory) if /boot (directory) is not empty. If
it can, how does that work? If I modify /boot/grub/grub.conf, which one
gets modified? Can this cause headaches?
I will welcome the day when LVM resizing (and moving) is as easy as
resizing (and moving) a Stacker compressed volume in DOS.
(DOS flashback! Ewww!! Shudder!!!)
OK guys. Let me have it. What things did I do well and which onese
were braindead? What could I have done better? And how? Let 'er rip.
No need to hold any punches. I figure I have much to learn here.
(I'm surprised at how much of this I *do* know, *and* at how quickly I
was able to recover without access to kplug.)
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
