Re: update from 17 to 18 failed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"T.C. Hollingsworth" <tchollingsworth@xxxxxxxxx> writes:

> On Sun, Jun 9, 2013 at 11:34 AM, lee <lee@xxxxxxxxxxxxxxx> wrote:
>> Same result, no packages marked for sync.  It doesn't do anything and
>> the packages from 17 remain installed along with the ones from 18.
>
> Hmm, maybe your repository configuration is still unhappy?  What does
> `yum repolist` say?


,----
| [~] yum repolist
| Loaded plugins: fastestmirror, langpacks, presto, refresh-packagekit, remove-
|               : with-leaves, show-leaves
| Loading mirror speeds from cached hostfile
|  * fedora: fedora.mirror.root.lu
|  * updates: ftp.uni-siegen.de
| repo id                        repo name                                 status
| fedora/18/x86_64               Fedora 18 - x86_64                        33,868
| updates/18/x86_64              Fedora 18 - x86_64 - Updates              15,538
| repolist: 49,406
| [~] 
`----


> Also, you could try a `yum clean all` and retry it; perhaps there's
> some stale data screwing up the works.

I tried 'yum clean all' a few times and it didn't make any difference.

> Are you using a F17 yum/rpm or an F18 yum/rpm?  (`rpm -q yum rpm` will
> tell you.)  A mixture of these could also be causing issues.

,----
| [~] rpm -q yum rpm
| yum-3.4.3-54.fc18.noarch
| rpm-4.10.3.1-1.fc18.x86_64
| [~] 
`----

>> Is there a way to get rid of the packages from 17 and to replace them
>> with those from 18 without breaking anything?
>
> This is exactly what `yum distro-sync` is supposed to do.  Figuring
> out why it's unhappy is the first step to getting your system back
> into working order.

Maybe there's nothing to sync because yum figures this is Fedora 18?

>> This is something the
>> package management is supposed to take care of in the first place so a
>> situation like this should never occur ...
>
> I'm not aware of any package manager that doesn't have issues like
> these from time to time.  dpkg/apt aren't any better;  I've seen
> Debian and Ubuntu upgrades go south and leave the system in an
> inconsistent state too.

I've been using Debian for 15 years or so and never had an update fail.
Then when they messed up so badly with their brokenarch, I switched to
Fedora.  However, I avoided dist upgrades by running testing after
finding out that it's easier to go in little steps than to make a more
or less big leap from one stable release to the next.  Over time,
another advantage showed: Too much of the software in stable was
ancient.

> Remember, Murphy's Law always applies.  ;-)

Well, look at pages like [1] and think about what kind of update
procedure they came up with:


+ contradictory information about how to update
+ using the recommended method fails miserably
+ alternative methods don't work at all
+ there is no information at all available what to do when the update fails
+ the user is required to fix a bug in the recommended update software
+ the recommended method can finally be tried again
+ the recommended method fails miserably again
+ the user is forced to spend hours trying to fix problems
+ what he's trying can very well leave him with an unusable system
+ even if the problems can be mostly solved, the next update is likely
    to fail miserably again
+ the user has classified Fedora as unreliable and will not recommend it
    to others anymore, at least not without a big warning
+ the user would have switched to another distribution if that wasn't so
    much work and if they didn't need a working system NOW and not after
    a week or so
+ if it doesn't work next time, the user is forced to switch
+ the user doesn't dare to reboot because the system might not start


What kind of update procedure is that?  Sure things can go wrong and not
everything can be foreseen when testing the update procedure, but a
total failure like that simply must not happen.  That it can means that
they need to rethink their update procedure and design it in such a way
that it can't happen, or it needs a way to roll back.


[1]: http://fedoraproject.org/wiki/User_base

-- 
Fedora 17.8
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org




[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux