[Leaplist] Fedora Live, not other Live CDs, for Fedora (and RHEL/CentOS) -- WAS: Various ...

Bryan J. Smith b.j.smith at ieee.org
Thu May 15 21:02:51 EDT 2008


PREFACE:  Tempting fate, here goes ...

I have warned and warned over the years, on and off-list, about this.
I'm sure some will complain about me being adamant about this as well.
But there have been enough posts that have skipped over this, I feel I
must post on-list.  Please do not start a meta-discussion on this, focus
on my explicit, technical details if you disagree.  Thanx in advance.

EXECUTIVE SUMMARY

If you are recovering a Fedora system, please use the Fedora Live CD,
not another Live CD.  For RHEL or CentOS, please create/usage their
respective Live CDs, or a Fedora Live CD (ideally of the same generation
-- e.g., Fedora Core 6 - Fedora 9 for RHEL/CentOS 5).  Also do not use
[G]parted on its own if you are certain LVM volumes exist.

TECHNICAL DISCUSSION

Red Hat is the maintainer for (former Sistina) Logical Volume Manager
(LVM) version 2, the standard in kernel 2.6.  Red Hat has also patched
many advanced DeviceMapper (DM) features into its kernels beyond what
upstream (kernel.org) does.  Furthermore, DM capabilities have varied
greatly during the kernel 2.6.  It definitely goes without question that
you should _never_ run a kernel 2.4 or early kernel 2.6 Live CD or other
recovery software on any Fedora or RHEL release of the last 3-4 years or
so (kernel 2.6.9+).

Recent Fedora Live CDs come with two graphical tools you should be aware
of:  
- Gparted
- system-config-lvm

First and foremost, if you have LVM (namely LVM2 for kernel 2.6) volumes
on your system, they should be deleted, or at least deactivated,
_before_ you run Parted.  That's because of LVM volume groups are
activated, using physical extents on the disk you are going to nuke,
there can be meta-data still written to the disk that may affect future
use of the disk (installers may still see the meta-data).  Most
kernels/init processes enable LVM volume groups on boot, and will
continue writing to the volume _regardless_ of changes to disk labels
and/or slices (aka partition tables and/or partitions).

The best and easiest way to do this is to run system-config-lvm, which
should be on most Fedora Live CDs.  It will handle all of the gory
details of modifying a volume group, including helping you find the
exact "physical volumes" on the disks you plan on nuking.

If you cannot locate system-config-lvm, if there is just one LVM command
to at least learn in Linux, it is "vgchange".  I liken this to the one
SELinux command to at least learn in Linux, "restorecon".  Even if you
have no interest in learning a capability, just knowing the one command
to "get yourself out of 90%+ of trouble" is always good to know.  The
two most common uses of the LVM "vgchange" command are:  
  vgchange -ay
  vgchange -an

The first actives all volume groups, which is typically what most kernel
2.6 distros do at boot.  The second does the opposite, deactivates all
volume groups, at least all it can (if they are not in use).  Although
it would still be better to actually use the proper LVM commands to
delete the physical extents on the drive you plan to nuke, at least
deactivating the volume group with "vgchange -an" prevents the kernel
from using the disk, and writing any more meta-data to it while you're
changing disk labels/slices.

Once you have deleted or deactivated any LVM volume groups, physical
groups, etc... that may be in use on the disk, you can use whatever
labeling/slicing utility you want, like [G]parted.  The #1 request for
Gparted is LVM support, so hopefully there will be a version that adds
it, or is at least "aware" of it so it doesn't start dorking with it
when LVM is in operation.  I'm sure that's their first objective if and
when they do start adding some support.

And, as always, if you run Red Hat distros like Fedora, stick with Red
Hat's Live CDs.  I've professionally seen Knoppix, even a more recent
2.6 kernel release, _toast_ both a Fedora and a RHEL system, because of
LVM being in use.  I've also seen extents left around that were
"detected" by installers.  It's always best to destroy the LVM physical
groups/extents whenever possible, when you don't want them coming
back.  ;)



-- 
Bryan J  Smith              Professional, Technical Annoyance
mailto:b.j.smith at ieee.org  http://www.linkedin.com/in/bjsmith
-------------------------------------------------------------
           Fission Power:  An Inconvenient Solution



More information about the Leaplist mailing list