Migrating from RH9 Legacy to CentOS 3

[David Eisner]

With the end of Legacy support for RH9, I'd like to migrate my Fedora
Legacified RH9 box to Centos 3.

I've used these directions in the past to successfully migrate from
non-legacy RH9 to Centos 3.1 using yum:

http://www.owlriver.com/tips/centos-31-ex-rhl-9/

Any thoughts on whether this should also work with the .legacy packages?

Thanks in advance.

-David

[Eric Rostetter]

Post by David Eisner
With the end of Legacy support for RH9, I'd like to migrate my Fedora
Legacified RH9 box to Centos 3.

Sounds reasonable.

Post by David Eisner
I've used these directions in the past to successfully migrate from
http://www.owlriver.com/tips/centos-31-ex-rhl-9/
Any thoughts on whether this should also work with the .legacy packages?

Should work fine. Sometimes you will find a dependency issue to work
around. Often that means removing the old package. Sometimes it might
mean changing yum's "exactarch=1" to "exactarch=0" to get around a
dependency issue caused by architecture changes (from i386 to noarch
or vise-versa, or from 32 bit to 64 bit, etc).

Generally it runs smoothly, but occassionally some thought must be put
into resolving some dependency issue...

One thing I don't see mentioned much. First, do a "yum update" or
"yum upgrade" on the RHL 9 repo. Then do a "yum clean" to free
up disk space. Then do your yum upgrade to Centos. Otherwise, you
will have your old RHL yum cache taking up a lot of space...

Post by David Eisner
Thanks in advance.
-David

[Ralph E. Kenyon, Jr.]

On Tue, 24 Oct 2006 11:33:18 -0400, Eric Rostetter

Post by Eric Rostetter

Post by David Eisner
With the end of Legacy support for RH9, I'd like to migrate my Fedora
Legacified RH9 box to Centos 3.

Sounds reasonable.

Post by David Eisner
I've used these directions in the past to successfully migrate from
http://www.owlriver.com/tips/centos-31-ex-rhl-9/
Any thoughts on whether this should also work with the .legacy packages?

Should work fine. Sometimes you will find a dependency issue to work
around. Often that means removing the old package. Sometimes it might
mean changing yum's "exactarch=1" to "exactarch=0" to get around a
dependency issue caused by architecture changes (from i386 to noarch
or vise-versa, or from 32 bit to 64 bit, etc).
Generally it runs smoothly, but occassionally some thought must be put
into resolving some dependency issue...
One thing I don't see mentioned much. First, do a "yum update" or
"yum upgrade" on the RHL 9 repo. Then do a "yum clean" to free
up disk space. Then do your yum upgrade to Centos. Otherwise, you
will have your old RHL yum cache taking up a lot of space...

Post by David Eisner
Thanks in advance.
-David

I'm still using RedHat 9 and up2date.
What would I have to do to upgrade to a fedora version?
--
Ralph E. Kenyon, Jr.
http://www.xenodochy.org/ralph.html
191 White Oaks Road
Williamstown, MA 01267-2259
Phone: [phone]

Home pages:
http://www.xenodochy.org
http://www.ballroomdances.org
-------------------------------------------------------
FIGHT SPAM http://www.xenodochy.org/diogenes/antispam.html
(If you are thinking about collecting my email address, read the above
page first!)
------------------------------------------------------
Plain text markup: *bold*, /italic/, _underline_, LOUD
--------------------------------------------------------
Keep our semantic environments and cyberspace clean.
Always report errors discovered while surfing the web.
------------------------------------------------------
My favorite saying (from general semantics):
It's not that seeing is believing, believing is seeing,
and we're much better at believing than we are at seeing.
http://www.xenodochy.org/ex/quotes/santayana.html

[Eric Rostetter]

Post by Ralph E. Kenyon, Jr.
I'm still using RedHat 9 and up2date.
What would I have to do to upgrade to a fedora version?

You can either:

1) Install "yum" and upgrade that way
2) Download and burn a Fedora Core (or whatever RHEL/FedoraCore based distro
you want) ISO to a cdrom, boot from the cdrom, and upgrade that way.

If you want to go from RHL 9 to some similar version (Centos 3.x, Fedora Core
1, etc) then you can upgrade fairly painlessly either way. If you want to
skip generations (upgrade to Centos 4.x, Fedora Core 5, etc) then you will
probably have lots of problems/issues, and I don't recommend skipping over
versions like that. In those cases, I do multiple consecutive upgrades
(e.g. RHL 9 -> Fedora Core 1 -> Fedora Core 2 -> Fedora Core 5, or
RHL 9 -> Centos 3.x -> Centos 4.x). There is just too much different
between RHL 9 and current OS versions to rely on the upgrade between them
without going through some inbetween releases.

[R P Herrold]

Post by David Eisner
With the end of Legacy support for RH9, I'd like to migrate my Fedora
Legacified RH9 box to Centos 3.
http://www.owlriver.com/tips/centos-31-ex-rhl-9/
Any thoughts on whether this should also work with the .legacy packages?

As author of the migration instructions in question, let me
give an unqualified "Yes, probably" .... ;)

I would feel safer 'stretching' into CentOS-4, just to get the
later kernel, and buying the longer lifespan, but a move with
a set of CentOS 3.8 spins ISO images will work, if you are
a dead plain install wholly mediated by RPM, with minimal or
no transition issues. But please:
1. level 0 backup
2. strip out unused packages -- a good idea
anyway
3. possibly reboot and force a full fsck on all
partitions
4. remove /home if at a separate mountpoint, from
the fstab -- no reason to risk the data

good luck -- please let us know how it turns out.

- Russ Herrold

[Paul Lee]

Post by David Eisner
With the end of Legacy support for RH9, I'd like to migrate my Fedora
Legacified RH9 box to Centos 3.
http://www.owlriver.com/tips/centos-31-ex-rhl-9/
Any thoughts on whether this should also work with the .legacy packages?

As author of the migration instructions in question, let me give an
unqualified "Yes, probably" .... ;)
I would feel safer 'stretching' into CentOS-4, just to get the later
kernel, and buying the longer lifespan, but a move with a set of CentOS
3.8 spins ISO images will work, if you are a dead plain install wholly
1. level 0 backup
2. strip out unused packages -- a good idea
anyway
3. possibly reboot and force a full fsck on all
partitions
4. remove /home if at a separate mountpoint, from
the fstab -- no reason to risk the data

I may be introducing another layer of complication here but I have found
various OS Virtualization tools such OpenVZ extremely handy for for
migrating / updating servers with legacy RH operating systems.

Basically we have had a spare server where we have loaded the latest
Centos OS and installed the openvz kernel and utilities (all in RPM
format) and reboot.

All we have to do then is copy/backup the legacy RH9 server into a the
new openvz node (typically into /vz/private/<veid)). Basically rsync /
/home /var /usr etc (you don't need /boot or /lib/modules as you won't
be running the RH9 kernel) . Then create a ve conf file for the RH9 VPS
and then boot the RH9 VPS (easier if your VPS hardware node is on the
same IP subnet).

With your virtualised RH9 "server" running in VPS you are free to
reformat or re-install the original server. If when you have
re-installed the server and copied over the data, you find something is
broken, just fall back to your VPS "copy."

You could even test an OS upgrade using yum from within a VE before you
carrying out an upgrade on a real server.

On this particular server we are running 5 OS's including RH9 under an
openvz test kernel (there is now a new version of this kernel ;o)) :

[***@vm5 config]# cat /etc/redhat-release
CentOS release 4.3 (Final)

[***@vm5 ~]# uname -a
Linux vm5.xxxxxx.com 2.6.16-026test014.4-smp #1 SMP Wed Jun 7 17:01:29
MSD 2006 i686 i686 i386 GNU/Linux

[***@vm5 ~]# vzlist
VPSID NPROC STATUS IP_ADDR HOSTNAME
6001 35 running 83.xxxxxxxxxx secure1.xxxxx <--RH9
6002 58 running 83.xxxxxxxxxx server1.xxxxx <--Centos3
6003 1 running 83.xxxxxxxxxx test-gentoo.xxxx<--Gentoo
6004 49 running 83.xxxxxxxxxx server1.xxxx <--RH9
6006 26 running 83.xxxxxxxxxx status.xxxx <--FC6

Also has the advantage that we were able to run 10 or more (legacy) VPS
on the same physical hardware freeing up lots of real boxes (depends on
how busy the servers are and the power of the hardware node).

The only thing is I have not been able to create pristine RH9 template
using yum (but then again I don't need to as I just copy legacy boxes).
When FC6 came out this week it was a doddle to create an FC6 template
and boot an FC6 VPS.

There are other virtualisation technologies such as xen and vserver and
openvps etc which would help ease migration paths - all you need have is
one spare server, but I have jut found openvz the easiest to configure
and setup.

www.openvz.org

Regards


Paul Lee
Weycrest.Net

[Michal Jaegermann]

Post by Paul Lee
All we have to do then is copy/backup the legacy RH9 server into a the
new openvz node (typically into /vz/private/<veid)). Basically rsync /
/home /var /usr etc

A word of warning here. When you are doing operations like the
above, for whatever reasons, skip /var/log/lastlog file. Not only
an information in it will not be useful later but this is a sparse
file and it is "very sparse". :-) On x86_64 installation its
length will be in order of 1.2 TB while its size, in disk blocks,
somewhere between 60 and 70 K. For i386 differences are not so
dramatic. Typically around 20 MB versus 20-30 K (it varies with a
number of accounts on an installation). Still you do not need it.
Even if you did not forget about option -S to rsync, and similar if
you are using some other utility, reading through 1.2 TB takes a
long while. With 32-bits this is far from beeing that bad but better
get into habit. :-)

There are other sparse files laying around, typically those in
/var/lib/rpm/, but gaps between lengths and sizes are not likely
be so significant.

Michal

[Paul Lee]

Post by Michal Jaegermann

Post by Paul Lee
All we have to do then is copy/backup the legacy RH9 server into a the
new openvz node (typically into /vz/private/<veid)). Basically rsync /
/home /var /usr etc

A word of warning here. When you are doing operations like the
above, for whatever reasons, skip /var/log/lastlog file. Not only
an information in it will not be useful later but this is a sparse
file and it is "very sparse". :-)

Thats a good point. But another reason I like Openvz. The "file system"
is entirely quota based so scales dynamically and "on the fly" to the
full extent of the space available on the disc.

With Xen/UML etc its alo neccessary it create an image file with dd,
then format it for ext3, them would have to mount the "image" as
loopback device and the start copying your legacy system into the "file"
etc..

These steps are entirely eliminated with openvz. You just copy to
/vz/private/<vzid> (obviously with some refinements to avoid copying too
much "junk," to save time and speed - you just need a big enough /var
partition ;o)). You can cd straight into these directories. Create you
vz.conf file then "boot" the VE instance.

I know you can create "sparse" disc images for xen, uml etc which grow
dynamically but there tends to be a performance issue.

Anyway I'm perhaps wandering a bit "off topic" here ;o)

Regards


Paul Lee
Weycrest.Net

[David Eisner]

Post by David Eisner
With the end of Legacy support for RH9, I'd like to migrate my Fedora
Legacified RH9 box to Centos 3.
http://www.owlriver.com/tips/centos-31-ex-rhl-9/
Any thoughts on whether this should also work with the .legacy packages?

As author of the migration instructions in question, let me give an
unqualified "Yes, probably" .... ;)

[...]

good luck -- please let us know how it turns out.
- Russ Herrold

[Better late than never ...]

Summary: The upgrade worked, with a few minor snags. I am now running
Centos-3.8 on that box.

A few notes:

Full disclosure: I screwed up and wound up using Centos 3.8 isos, but
used the Centos *3.1* updates in step 3. of the Owl River instructions.
I don't think this caused any major problems, though.

First I pared down the number of packages (removing -devel, etc.) to a
little under 400. And, yes, the box is backed-up nightly (with the most
recent full backup tapes at hand).

Here are the issues I ran into.

1. The Centos-3.8 isos for CD 1 and 3 both had a
comps-3.8centos.0-0.20060803.i386.rpm package, which were not identical.
I used the CD 3 version.


2. In step 8. of the Owl River instructions, when I executed

"yum -y -t -c /etc/yum-upgrade.conf upgrade rpm kernel",

I got a Segmentation Fault at this point:

Gathering header information file(s) from server(s)

Server: CentOS-9 - Updates

Server: Centos upgrade

Finding updated packages

Downloading needed headers

Finding obsoleted packages

Resolving dependencies

[Segmentation fault happened here]

To solve this, I first tried upgrading python from python-2.2.2-26 to
python-2.2.3-26, using an RPM downloaded from www.python.org. This
didn't help. So I tried running "/usr/bin/python /usr/bin/yum -y -t -c
..." in gdb to see where it was crashing, but it Heisenbergily refused
to segfault this time. In any case I wasn't complaining.


3. Step 8. has one run the same two commands twice. The second time I
ran "rpm -vv --rebuilddb", it was not happy:


# rpm -vv --rebuilddb

D: rebuilding database /var/lib/rpm into /var/lib/rpmrebuilddb.10450

D: creating directory /var/lib/rpmrebuilddb.10450

D: opening old database with dbapi 3

D: opening db environment /var/lib/rpm/Packages joinenv

rpmdb: Program version 4.2 doesn't match environment version

error: db4 error(22) from dbenv->open: Invalid argument

D: opening db index

/var/lib/rpm/Packages rdonly mode=0x0

error: cannot open Packages index

D: removing directory /var/lib/rpmrebuilddb.10450


I rebooted, and then the rebuilddb worked. The second
"yum -y -t -c /etc/yum-upgrade.conf upgrade rpm kernel" ran and, not
surprisingly, told me there were no upgrades available.

4. Step 9. worked fine, it just took awhile. However, a few .legacy
packages remained:



$ rpm -qa |grep legacy

sendmail-cf-8.12.11-4.24.1.legacy

fetchmail-6.2.0-3.4.legacy

libpng10-1.0.15-0.9.1.legacy

gettext-0.11.4-7.2.legacy

kernel-2.4.20-46.9.legacy

tcpdump-3.7.2-7.9.4.legacy

libpcap-0.7.2-7.9.4.legacy

kernel-2.4.20-43.9.legacy

zip-2.3-26.1.0.9.legacy

sendmail-8.12.11-4.24.1.legacy


I removed the legacy kernel packages, and "upgraded" the rest manually
with rpm -Uvh --force. That seems to have worked. Then I rebooted.

Finally I replaced /etc/yum.conf with the sample given in the Owl River
instructions, and it appears to be working (there were two packages
available for updating (GConf and oaf) which I was able to do with no
problems).

If I run into any problems in the future, I'll let you know.

-David

[Michal Jaegermann]

Post by David Eisner
Summary: The upgrade worked, with a few minor snags. I am now running
Centos-3.8 on that box.

....

Post by David Eisner
# rpm -vv --rebuilddb

....

Post by David Eisner
error: db4 error(22) from dbenv->open: Invalid argument

....

Post by David Eisner
I rebooted, and then the rebuilddb worked.

Chances are that running 'rpm -vv --rebuilddb' the second time,
without rebooting, would work too. I have seen that in the past.
No harm in rebooting. :-)

Post by David Eisner
4. Step 9. worked fine, it just took awhile. However, a few .legacy

....

Post by David Eisner
I removed the legacy kernel packages, and "upgraded" the rest manually
with rpm -Uvh --force.

You may want to run at this stage 'rpm -qa --last >packlist' and
check results to see what "old" packages still linger on your system
and if you want to keep them. Also if 'yum-utils' package is
available in 'extras' for your OS version then it has a utility called
'package-cleanup'. Options '--problems' and '--orphans' would be of
a particular interest.

Michal

[R P Herrold]

Post by David Eisner

Post by David Eisner
With the end of Legacy support for RH9, I'd like to migrate my Fedora
Legacified RH9 box to Centos 3.
http://www.owlriver.com/tips/centos-31-ex-rhl-9/
Any thoughts on whether this should also work with the .legacy packages?

As author of the migration instructions in question, let me give an
unqualified "Yes, probably" .... ;)

1. The Centos-3.8 isos for CD 1 and 3 both had a
comps-3.8centos.0-0.20060803.i386.rpm package, which were
not identical. I used the CD 3 version.

noted, wearing my 'CentOS' hat - thanks for the report -- U9
whould be along in reasonably soon which will get a respin,
but we'll look for that in the CentOS build process

Post by David Eisner
"yum -y -t -c /etc/yum-upgrade.conf upgrade rpm kernel",
[Segmentation fault happened here]

hmmm --- wish I had more information here -- probably the
instructions need to be updated to suggest removing all
but the kernel in use; a pre-conversion 'yum -y clean all'
would probably be prophylactic as well.

Post by David Eisner
To solve this, I first tried upgrading python from python-2.2.2-26 to
python-2.2.3-26, using an RPM downloaded from www.python.org. This

ouch -- python version dependent matters are _so_ integral to
a Red Hat derived system, that I consider that pretty 'daring'

Post by David Eisner
3. Step 8. has one run the same two commands twice. The
I rebooted, and then the rebuilddb worked. The second "yum
-y -t -c /etc/yum-upgrade.conf upgrade rpm kernel" ran and,
not surprisingly, told me there were no upgrades available.

We are in terra incognita here with the python version
possibly in play; I think my instructions whould suggest the
reboot before the first and second rebuilddb's again, not for
a known issue, but to make sure we are under the new kernel

Post by David Eisner
4. Step 9. worked fine, it just took awhile. However, a few
$ rpm -qa |grep legacy
sendmail-cf-8.12.11-4.24.1.legacy
fetchmail-6.2.0-3.4.legacy
libpng10-1.0.15-0.9.1.legacy
gettext-0.11.4-7.2.legacy
kernel-2.4.20-46.9.legacy
tcpdump-3.7.2-7.9.4.legacy
libpcap-0.7.2-7.9.4.legacy
kernel-2.4.20-43.9.legacy
zip-2.3-26.1.0.9.legacy
sendmail-8.12.11-4.24.1.legacy

I had not considered this later versioned material (when the
outline was written, it was in the future, and unknowable as
to how this would play out), as the path I outlined from RHL 9
would not encounter it; I will approach other members of the
CentOS team in the topic of how we are to offer a path to
'care' for the people orphaned by the EOL of FL.

btw, Kudos to Jesse and the folks who kept FL running for the
two years or so it ran -- I know how difficult starting and
running a distribution is, and a great effort and success were
the result.

Post by David Eisner
I removed the legacy kernel packages, and "upgraded" the
rest manually with rpm -Uvh --force. That seems to have
worked. Then I rebooted.

I will consider adding a section about 'housekeeping' to
identify and get back onto the CentOS main line path for the
FL transitioners. seems like a good idea. Thanks for noting
this.

Post by David Eisner
Finally I replaced /etc/yum.conf with the sample given in
the Owl River instructions, and it appears to be working
(there were two packages available for updating (GConf and
oaf) which I was able to do with no problems).

Great -- Thank You, David.

-- Russ Herrold

[Lance Davis]

Post by David Eisner
1. The Centos-3.8 isos for CD 1 and 3 both had a
comps-3.8centos.0-0.20060803.i386.rpm package, which were not identical. I
used the CD 3 version.

noted, wearing my 'CentOS' hat - thanks for the report -- U9 whould be along
in reasonably soon which will get a respin, but we'll look for that in the
CentOS build process

Errm I think U8 was the last respin for rhel3 ... and likewise CentOS 3
???

Regards
Lance

--
uklinux.net -
The ISP of choice for the discerning Linux user.

[David Eisner]

Post by David Eisner
"yum -y -t -c /etc/yum-upgrade.conf upgrade rpm kernel",
[Segmentation fault happened here]

hmmm --- wish I had more information here -- probably the instructions
need to be updated to suggest removing all but the kernel in use; a
pre-conversion 'yum -y clean all' would probably be prophylactic as well.

Actually, I did do a yum clean all before the conversion (should have
mentioned that in the notes). My hunch was that, because the "Resolving
dependencies" stage took awhile, some data structure was growing too
large and exposing a flaw in python or one of the libraries.

Post by David Eisner
To solve this, I first tried upgrading python from python-2.2.2-26 to
python-2.2.3-26, using an RPM downloaded from www.python.org. This

ouch -- python version dependent matters are _so_ integral to a Red
Hat derived system, that I consider that pretty 'daring'

I should mention that it was an RPM designed for RH9. From
http://www.python.org/download/releases/2.2.3/rpms/ : "These RPMs are
built from Red Hat's SRPM, not the python.org tar-file. These RPMs are
meant to more closely match the standard Python provided by Red Hat."

[...]
Great -- Thank You, David.

And thanks, Russ, for the excellent instructions and your work on
CentOS. I echo your thanks to Jesse et. al. for all their hard work
over the years. I know it was a mostly thankless job.

-David

[David Eisner]

Post by David Eisner
If I run into any problems in the future, I'll let you know.

Update: I am running into this bug: http://bugs.centos.org/view.php?id=1598

In short, NFS mounts fail when mounting from multiple hosts. Only mounts
from the first host succeed, with the remaining producing the error

mount: mount: RPC: Unable to receive; errno = Connection refused

-David

[Josep L. Guallar-Esteve]

Post by David Eisner

Post by David Eisner
If I run into any problems in the future, I'll let you know.

Update: I am running into this bug: http://bugs.centos.org/view.php?id=1598
In short, NFS mounts fail when mounting from multiple hosts. Only mounts
from the first host succeed, with the remaining producing the error
mount: mount: RPC: Unable to receive; errno = Connection refused
-David

Is RPC really running? Or is it dead?

Has the update changed your firewall rules?


Regards,
Josep
- --
Josep L. Guallar-Esteve - IT Department - Eastern Radiologists, Inc.
Systems and PACS Administration http://www.easternrad.com

[David Eisner]

Post by Josep L. Guallar-Esteve

Post by David Eisner
mount: mount: RPC: Unable to receive; errno = Connection refused

Is RPC really running? Or is it dead?
Has the update changed your firewall rules?

I fixed the problem. In addition to upgrading util-linux, as suggested
on the bug page, it is also necessary to upgrade the mount package. Now
I have mount-2.11y-31.19 and util-linux-2.11y-31.19, installed from the
fasttrack repository, and everything works.

-David

[R P Herrold]

Post by R P Herrold
noted, wearing my 'CentOS' hat - thanks for the report --
U9 whould be along in reasonably soon which will get a
respin, but we'll look for that in the CentOS build
process

I think he said said ("would be along in reasonably soon") or at least
meant to say that :)
Ralph

Thanks, Ralph -- looks like at least _someone_ understands how
I type ;)

[Ralph Angenendt]

Post by Lance Davis

noted, wearing my 'CentOS' hat - thanks for the report -- U9 whould be
along in reasonably soon which will get a respin, but we'll look for that
in the CentOS build process

Errm I think U8 was the last respin for rhel3 ... and likewise CentOS 3
???

I think he said said ("would be along in reasonably soon") or at least
meant to say that :)

Cheers,

Ralph

[Ralph Angenendt]

Post by Lance Davis

noted, wearing my 'CentOS' hat - thanks for the report -- U9 whould be
along in reasonably soon which will get a respin, but we'll look for that
in the CentOS build process

Errm I think U8 was the last respin for rhel3 ... and likewise CentOS 3
???

I think he said said ("would be along in reasonably soon") or at least
meant to say that :)

Yay for incomplete sentences:

... to say that 3.9 will be available in the not so distant future and
will get a respin of the ISOs.

Ralph

[Ralph Angenendt]

Post by Ralph Angenendt
... to say that 3.9 will be available in the not so distant future and
will get a respin of the ISOs.

But ... I think Lance means that RHEL-3 is in Maintenance Mode
upstream ... and that 3.8 MAY have been the latest respin.

Okay. It *is* monday after all and I'm still trying to wake up :)

Ralph