On 11/08/2011 08:50 AM, Lamar Owen wrote:
> On Monday, November 07, 2011 07:00:08 PM you wrote:
>> On Mon, Nov 7, 2011 at 2:02 PM, Connie Sieh<[log in to unmask]>
>> wrote:
>>> Yes that is our support stance.  It is NOT supported by either
>>> TUV or SL .
>
>> I remember that thread and Connie's response. I'm sorry that I
>> suggested in this thread that it was OK; I was confusing RHEL/SL
>> with Fedora, where it is OK and one of the Anaconda pre-release QA
>> tests.
>
> Not supported != doesn't work. Which means, if you get it to work,
> that's great, but if it fails to work, you get to keep the pieces,
> and you won't be 'entitled' to any sympathy or help.
>
> There has been an 'upgradeany' command line option in CentOS at least
> for several cycles, but it is also not supported.  It might work, but
> it likely will leave your system in a 'self-supported' state.
> Meaning, again, that when it breaks you won't get any sympathy, and
> you'll likely get the 'unsympathy' which seems to be typical for
> techie lists.... sorry, but facts are facts, and whether it's right
> and fair or not, it just *is* the case.
>
> Likewise, preupgrade tends to work fairly well for Fedora; but when
> it works it typically doesn't work for an upgrade increment of more
> than two Fedora versions.  The Fedora version skew between EL5, based
> somewhat on FC6, and EL6, based somewhat on a melange of F12, F13,
> and other things, is 6 full Fedora versions.  Even if preupgrade were
> available for FC6, it likely would not upgrade to F12 even in one
> step.  It's not likely to be ever be *supported* on EL of any
> version, even if it does become available.
>
> This is where the one of the major differences between the RPM
> packaging and the DEB packaging shows itself.  Debian (and
> Debian-derivatives) take advantage of the possibility of interactive
> response in a DEB to deal with real upgrade issues; RPMs are not
> supposed to do any interaction with the user in any of the package's
> scriptlets.  The DEB scripts have wide latitude in what they can do,
> and have several powerful tools available for use in the script.  It
> does make complete unattended upgrading somewhat difficult, as it
> prompts the user for lots and lots of things and seemingly random
> times; IOW, it's not a 'start it and let it run overnight' thing
> without effort.
>
> I've attempted preupgrade upgrades, and have not had one go 100%
> successfully yet.  Nor, for that matter, have I ever had a DVD or CD
> upgrade of any Fedora version go 100% successfully, either.
>
> So I typically 'upgrade' by keeping a separate /home and backing up
> everything in /etc and /var that will be needed in the new version (I
> of course back up /home as a matter of course), and getting a
> 'versionless' RPM listing ( rpm -qa --queryformat="%{NAME}\n"|sort ).
> If anything is in /usr/local or /opt those get backed up, too, and
> separately evaluated.  For workstations it's not too hard; servers
> are another matter.  I then do a fresh installation, making sure to
> neither format nor mount the old /home.
>
> I'll retrieve the package listing and the repository info (being in
> /etc/yum.repos.d, it gets backed up with /etc) and check those to
> make sure the repos and options are the same, and then I'll enable
> those repos, do an initial yum update, and then use the yum-utils
> program repoquery to get a full listing of all packages that are
> available, use diff in a creative manner, and do other manual things
> to get a valid list of packages to install, and pass that list to
> yum.
>
> Once I'm satisfied all the packages my /home are going to need are
> installed properly, I'll read the release notes both of the
> distribution and of the major upstream packages I use (things like,
> GNOME and KDE, Ardour, JACK, and those other things I use on a daily
> basis) and make sure there's not going to be major reshuffling or
> data corruption or improper operation in those programs'
> configuration directories in my /home.
>
> I'll test with a normal user named the same as my main user ID before
> remounting my /home, and make sure things look reasonable with copies
> of what that program needs from my /home (mounted somewhere else, of
> course), and once that looks good I'll reboot in single user mode,
> rename /home to /new-home, recreate the /home mount point, and set
> /etc/fstab to mount /home again.  I'll also set up an selinux relabel
> for the entire filesystem (I do, unlike most, run my workstation with
> SELinux ON and ENFORCING).
>
> And those release notes things and checking should be done even if
> you do a preupgrade-sort of thing, or a string of yum updates with
> repo files pointing to various places.
>
> It is more of a pain for a user to do the upgrade the way I do
> upgrades, but the fact of the matter is that the current RPM system
> simply is not built to do robust upgrades when many upstream packages
> have major differences between versions, in terms of data files and
> configuration; the scriptlets just don't have enough power at their
> disposal, really, and especially in the anaconda chroot used during
> media-based upgrades as well as preupgrades (which are still
> media-based, to a degree).  And without being able to query the user
> and use those answers in the upgrade environment, it's probably a
> good thing the scriptlets are limited in how much they can do, since
> the default action chosen by the packager is guaranteed to be the
> wrong thing to do for some user somewhere.
>
> Upgrades are hard (even in Debian, been there, done that).  They're
> hard primarily because the upstream packages in many cases don't
> consider easy user upgrades a priority, or they don't have the
> resources to do everything a seamless upgrade requires.  But
> secondarily packaging systems in the typical RPM-based Linux
> distribution don't give packagers the tools to make it easy for the
> user doing the upgrade.  And the scripts in a DEB often don't have
> the exact option you want, and they are annoying when you're taking
> the default on all but one specific package.....
>
> At least the upgrade paths do get tested and maintained in Debian;
> it's my opinion that's one reason for their long release cycles.  The
> upgrade paths available with a yum-based upgrade aren't well tested
> (and may not be maintained, even), and even those who have done them
> (and I've done them with older RPM distributions, in particular
> Aurora SPARC Linux going between versions where installing the old
> version with media and yum upgrading to the latest *was the normal
> way of getting the latest version* ) haven't tested your specific
> upgrade path!
>
> So caveat upgrador, to use bad Latin.  And forget ala carte upgrades
> (kernel only, or KDE only) unless you want to roll your own.

Your approach reminds me of what I used to do with relatively simpler 
systems (less bloat).

My situation is that my existing HP 8530p laptop is running IA-32 EL 5.7 
on a 320 Gbyte internal drive.  Unlike a workstation enclosure, there is 
no room for two internal hard drives.  From all signs, to support 
"current" end-user applications, I will need to move to EL 6 as on my 
office workstation, as on our current cluster compute engines, and as on 
the Lenovo SandyBridge laptop that I configured for my wife that has a 
500 Gbyte harddrive.

What I have decided to do is:

1.  order a fresh "bare" 500 Gbyte laptop drive (of the correct 
specifications) for my HP 8530p.

2.  using dd and an external USB drive enclosure that mounts an external 
drive as /dev/sdX for some X, clone the drive from my wife's machine to 
this drive.  As I only have a USB 2 interface on the enclosure, and 
neither her nor my laptop has USB 3 ports, this dd will take 
approximately 24 hours.

3.  I will then move the cloned drive to my laptop, copy /home, passwd, 
shadow, as well as xorg.conf (no network configuration is needed as both 
laptops use DHCP through Network Manager -- a terrible system but one 
that is convenient and generally operational for IEEE 802.11 WLANs 
anywhere we roam),  exchange the drive in my machine for the clone, and 
reboot.  Assuming all goes well, I will then copy any additional 
directories/files from the previous harddrive in the USB external 
enclosure to the internal harddrive as needed.

Based on past experience with EL 5 and EL 6, because there are no 
non-distro drivers needed by either hardware platform, the system should 
boot -- and be done with basic systems work.

Once MS forces UEFI. as it plans UEFI, to become the default, the above 
will not work -- but probably no licensed for free system will be 
bootable on any UEFI locked down and our only choices will be MS on 
arbitrary vendor hardware or Mac OS X on Apple hardware.