I can't comment on UsrMove because I'm quite unfamiliar with it, but I did manage to upgrade from f17 to f18 using the totally unsupported yum update --releasever --enablerepo="*testing" --nogpgcheck method.

Computer booted and everything's exactly as it used to (Though I did have to remove some packages like Calibre because of file conflicts, no big deal).

I did it on a live system, too. The only thing that failed during that time was postgres (Which managed to stay borked after it was done and f18 booted, the pg_upgrade method didn't work properly) but other than that and a much more responsive KDE, I can't see any side effects to this method.

YMMV,
-Nushio

On Fri, Nov 9, 2012 at 1:16 PM, Roberto Ragusa <mail@robertoragusa.it> wrote:
On 11/09/2012 10:19 AM, drago01 wrote:
> On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý <msuchy@redhat.com> wrote:
>> On 11/08/2012 03:10 PM, Roberto Ragusa wrote:
>>>
>>> Hmm, I now see there is a "set -e" at the beginning.
>>> Still a little scary.:-)
>>
>>
>> Scary is only the idea. And only because we are not used to do rolling
>> upgrades. Ask somebody from Debian experiance if this is scary ;)
>
> There are some upgrade tasks that you simply cannot do from within a
> running system (ex: usermove).

Serious question: why usrmove is not doable?
If you have all the dirs in your path, and move executable files from one
place to another, why should this fail?

I managed to do a 32 bit -> 64 bit transition (you know, the "absolutely
unsupported" upgrade) on a system which was running an entire KDE session.
My upgrade commands (rpm, yum, bash, everything else) started 32 bit,
then were mixed, then ended to be 64 bit.
Usrmove appears simpler. Am I missing something?

--
   Roberto Ragusa    mail at robertoragusa.it



--
Ing. Juan M. Rodriguez Moreno
Desarrollador de Sistemas Abiertos
Sitio: http://proyectofedora.org/mexico