Converting from EVMS on Debian

With the help of some previous advice on this list, I've converted 2
systems from EVMS to vanilla LVM(2) under Debian GNU/Linux testing aka
lenny.  Neither went particularly smoothly.  I'm posting this for the
benefit of those who follow, and also in hopes that someone might
clarify some of my confusions.

One general observation is that many rescue/live CD's don't support lvm,
and so are pretty useless if things go wrong.  I ultimately succeeded
using a recent Knoppix in one case and the Debian Etch installer in
another.  For the installer, it is crucial to proceed through the early
steps to load and uncompress the lvm tools from the installation media.

I decided to switch off EVMS for three reasons.  First, I had a snapshot
I could not get rid of, a known problem.  The inability to use snapshots
was a real problem for backups.  Second, EVMS and the 2.6.22 kernels
under Debian don't seem to work; I recall that disks couldn't be
detected in the early initrd phase of the boot.  Third, active
development of EVMS has reportedly stopped.  

My notes and recollection are better for my recent experience, so I'll
focus on that.

I began with a Debian stock 2.6.18 kernel and /root under volume
management.  Debian stock kernels have everyting necessary to support
device-mapper, lvm and evms.  I installed packages for lvm2, dmsetup,
and evms-bootdebug.  evms-bootdebug is a Debian specific package that
lets you stop the boot process while still in the initrd by adding
boot_evms to the kernel startup parameters.  This is handy, because the
first phase is to convert all EVMS volumes to compatibility, and you
can't be using them while you do that.

I restarted the system with boot_debug (I edited the grub parameters at
boot time).  This started me into an evmsn session.  I converted all the
volumes to compatabiity volumes.  I should have noted which physical
partitions corresponded to some of the volumes in the few cases it
wasn't obvious; I had to work that out later for a couple of them
(e.g., /dev/evms/Boot was /dev/sda8; I had /dev/evms/Var and several
volume groups with a logical volume names var).  I also was finally able
to delete the snapshot in this environment.  Note that the LVM docs say
you can't convert to LVM2 from LVM1 if a snapshot is open.

During the conversion there are the following environments:
* original EVMS
* EVMS with compatibility volumes
* system without EVMS
* system with  LVM
While in one of the early ones, one must generate an initrd that is
compatible with one of the later ones.  I'm still not sure the extent to
which that is possible.

I also thought that the conversion to compatibility volumes would change
the device names (e.g., /dev/evms/... because /dev/...), but I'm not
exactly sure how that works.

After I saved the changes in evmsn and exited I was left in a "busybox"
shell with messed up lines.  There were no line breaks, and the prompt
could appear in the horizontal middle of the screen.  This was very
difficult to work with.

Because I was unsure if the system would be bootable, I kept working.  I
mounted the real root and usr partitions.  Unfortunately, while running
a find on the latter the system hung up and I had to ctl-alt-del.

On reboot I got a "can't find file" error--not sure if it was the initrd
or the root fs it couldn't find.  After many false starts (Ubuntu 7.10
and knoppix, which had worked on my other system, seemed not to work on
this one--maybe a graphics card issue) I booted the etch installer, went
through the first few steps  up to and including loading the installer
and its components, and went into a shell.  I might have done vgscan and
vgchange -ay here, but I think I was still using evms.  I mounted some
of my volumes and edited fstab and grub/menu.lst to remove the evms
specific device names.

I think I then did mount --bind /sys /target/sys and mount
--bind /proc /target/proc (and maybe same treatment for /dev?).  /target
was where I had mounted my real root paritition (as opposed to the
installer's root).  I am not sure how important this is.  At various
times I tried operating in a chroot without proc or sys and creating
proc and sys after I switched to the chroot; these both seemed to cause
problems that prevented creation of an initrd, or at least of an initrd
that worked.

chroot into /target.  Started aptitude to remove all evms packages.
This initially failed because /usr/sbin wasn't in my path.  I had
already mounted the directory and just needed to add it to my path.  The
second try worked.  I ran update-initramfs (which updated my 2.6.22-3
initrd--I was still running 2.6.18) and update-grub.

I rebooted but got "waiting for root fs".  I finally traced this to a
peculiarity of the Debian lvm2 scripts for initrd: they require a root
device of the form /dev/mapper/daisy-root, not /dev/daisy/root (see
Debian bug 453890); I used the latter.  I edited the kernel boot line
parameters to reflect the former useage, and finally got past the root
device detection.

Unfortunately, the Debianized proprietary nvidia drivers are not
available for 2.6.22 and neither the old ones nor the open source ones
work (Debian bug 342817).  So I couldn't get a graphical system going.
I edited grub/menu.lst to use /dev/mapper/daisy-root, ran
update-initramfs for the 2.6.18 kernel, and rebooted into that.
Finally, I had a working lvm2 system.

A few notes about my earlier attempt on a different system.  I tried to
go from the evmsn initrd environment to lvm without rebooting.  I think
it almost worked.  It may have had problems because I did not
mount /sys, /proc, and /dev appropriately in the chroot.  It definitely
had a problem becaue the new initrd was not written properly to disk.  I
think I failed to sync, and maybe did not do a proper shutdown (the
shutdown command was not available in the initrd environment).  I used a
recent knoppix as a rescue CD (after trying many older CDs that weren't
lvm2 aware) and eventually got it working.

Despite prolonged periods in which the system was unbootable, and looked
unrecoverable, my data were never really in danger.

Ross Boylan

-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell.  From the desktop to the data center, Linux is going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Evms-devel mailing list
[email protected]
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel