From what you are writing, it seems as if the only sane thing to do is to put in a fresh, unformatted harddrive (unfortunately, my department will not buy me a spare and none of my existing grants will cover this unless I play some games), install RHEL N+1 for the migration from RHEL N (where N is a major release, not just N.m) , and then copy all of the important things from the RHEL N to the RHEL N+1 partitions/directories as root, doing chown, chgrp as required.

A colleague who uses the SUSE equivalent of RHEL (not the SUSE equivalent of Fedora) tells me that this is not necessary when going from SUSE N to SUSE N+1. For example, he had SUSE N 32 bit and moved to SUSE N+1 X86-64 and installed the SUSE N+1 32 bit compatibility libraries (so 32 bit applications would execute), and had none of these problems.

As far as I can tell, there is no licensed-for-free binary clone distribution of the SUSE equivalent of RHEL (unlike CentOS and SL for RHEL), although as with RH, under the Linux, GNU, and similar licenses, SUSE (that is, Novell) is required to make the full source package required to build the binaries available without cost (unless one wants the source distributed on physical media). Am I correct concerning SUSE?

Also, thank you for touch /.autorelabel; reboot as I install SELinux but make it fully non-enforcing (notifying me of issues, not stopping them). This is necessary at my institution because the institution issues certificates from a non-valid CA, not wishing to pay the fees for a valid CA.

Regards,

Yasha

On 06/16/2011 01:53 PM, Stephan Wiesand wrote:
On Jun 16, 2011, at 22:03 , Yasha Karant wrote:

 From the reply below:

I figure it's possible to choose "advanced" partitioning and simply uncheck "format" for all 
existing partitions while choosing the old mountpoints. Technically, that's an unsupported upgrade, while you don't 
have to boot with an "upgradeany" kernel parameter or choose "update existing linux installation" 
in the anaconda GUI. And I figure it's what happened here.

End quote.

That is correct.  It also is correct that RHEL and any faithful clones (such as 
CentOS and SL) does not allow a major release upgrade, only a minor release.  
Assuming one has a decent data rate network connection, up to and including 
RHEL 5.6 (in my case, via CentOS 5.6) minor upgrades (e.g., RHEL 5.5 to RHEL 
5.6) could be done by internal update mechanism without requiring a DVD 
(installation media) or a reformatting of any partition (unless, of course, the 
size of the partition was too small -- almost unheard of with the current price 
of a 1 TByte SATA drive).

For a major release, one must use the media or other specialized means and 
requires a full upgrade.  However, when I went from RHEL 4 to RHEL 5 (via 
CentOS), I did not have to reformat and the installation was successful -- 
overwriting files that had the same function but newer versions.

You were lucky, or so it seemed. But you have files from the CentOS4 
installation still sitting in your filesystems. You probably even have CentOS4 
packages recorded in your rpmdb created during the CentOS4 installation. The 
actual failure stopping the SL6 installation is that this rpmdb cannot be 
opened by the SL6 installer...

This is not working with SL6 from Centos 5 (RHEL 6 from RHEL 5) and presumably 
will not work with CentOS 6 when it is available nor with RHEL 6 were we to 
license the media for fee.

It would be useful if this were made clear -- if it is stated that these 
entities:  / ,  /var , /usr must be reformatted, I apologize for missing this 
statement in the release notes.

At this point, I must copy a whole number of directories to partitions/drives 
that do not need to be reformatted (e.g.,  /usr/local, /opt , /home that I keep 
in separate ext2 partitions) to preserve a number of utilities that I will then 
cp -pr (or tar) back to whatever SL 6 does.

Before I begin, are there any things other than these (/, /var, /usr) that must 
be reformatted?

This list was gathered by skimming through the logs you provided. It's not necessarily 
complete. Connie mentioned /boot already. Keeping /tmp may or may not work. Keeping /home 
will probably work for installation but may cause problems later. If you keep any 
partitions without reformatting, "touch /.autorelabel; reboot" is probably the 
first thing you should do after successful installation, unless you disable SELinux.

Regards,
        Stephan

Yasha Karant

On 06/16/2011 11:51 AM, Stephan Wiesand wrote:
On Jun 16, 2011, at 20:39 , Connie Sieh wrote:

On Thu, 16 Jun 2011, Urs Beyerle wrote:

On 06/16/2011 06:58 PM, Yasha Karant wrote:
This one is from a SL6 install. SL and CentOS are both RHEL.  I keep the system 
utilities stock (the same as TUV, RHEL in this case), except for the use of
the graphics card driver from the graphics card vendor, not generic X (e.g., on 
this machine, the Nvidia driver for linux X).
I am switching to SL over CentOS because (1) we do not have funding luxury to 
license the binaries from RH and (2) CentOS 6 is not yet available despite RHEL
6.1 already having been released.  Other than re-branding, SL and CentOS both 
claim to be RHEL clones -- I know that the RPMs that work on RHEL release X work
just as well on both CentOS and SL of the same release.

(Why not SL over CentOS?  A matter of history, not a specific choice. With the 
upcoming demise of Fermilab as a direct experimental facility, hopefully the EU
will continue to fund CERN and not be shortsighted as USA neoliberal Republican 
Tea Partists force upon the USA, and thus maintain support for SL.)

I did not reformat / , /var, /usr .  Must these be reformatted?

Yes, otherwise you will have a mixture of the old system (CentOS5?) and the new 
SL6 system on /, /var, /usr. This will definitely not work.

If you want to keep old data you have to do an update instead of an install. 
But I don't know if CentOS5 can be update to SL60 with SL60 install DVD. My 
guess
is that this will not work.

An update from "5" to "6" is NOT supported by either RedHat or SL.  RedHat has 
code to specifically not allow it.
Others have tried to "force" an upgrade and were not successful.

I figure it's possible to choose "advanced" partitioning and simply uncheck "format" for all 
existing partitions while choosing the old mountpoints. Technically, that's an unsupported upgrade, while you don't 
have to boot with an "upgradeany" kernel parameter or choose "update existing linux installation" 
in the anaconda GUI. And I figure it's what happened here.

- Stephan



To be save make a backup before you format the partitions.


Will X86-64 SL6 allow me to keep these as ext2 (no journal)?

I think if you choose custom partitioning you can format your partitions with ext2. Just 
curious, what's the reason to use "old" ext2?

Cheers,

    Urs




-Connie Sieh


Reply via email to