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@xxxxxxxxxxxxxxxx> wrote:
On 11/09/2012 10:19 AM, drago01 wrote:Serious question: why usrmove is not doable?
> On Fri, Nov 9, 2012 at 10:16 AM, Miroslav Suchý <msuchy@xxxxxxxxxx> 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).
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?
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Ing. Juan M. Rodriguez Moreno
Desarrollador de Sistemas Abiertos
Sitio: http://proyectofedora.org/mexico
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
