what has 'yum update' done?

[D. Hugh Redelmeier]

I've been using Fedora and before that Red Hat Linux for over 15 years.  
I've never trusted any update process.  I've always done a 
re-installation.

This time, I thought I'd give fedup a chance.  I've done it on three
systems.  Each mostly worked.  The problems were minor and could
essentially be ignored.

Having said that, any problem in an upgrade process creates nervousness 
and uncertainty.  Will the user have nagging doubts his system's integrity 
from then on?

I actually still think re-installation is a good route.  So I'll write 
this up:

I partition my disk with two /root-size partitions and one /home 
partition.  I install into the other /root each time.  That leaves me able 
to boot the old system until I'm happy with the new one.  It also means 
that if I've forgotten to migrate some configuration, it's always 
possible to look at the former system's version.

There was one Fedora (multi-release) upgrade where this approach failed.  
The new fedora relabeled the /home filesystem with some capability that 
made it impossible for the old Fedora to mount it.  This was scary since 
the new Fedora didn't actually work initially (some video driver problem).  
That happened once, on one system, almost a decade ago.

The problem with re-installation is that you lose all the customization 
and configuring you have done.  The cure is a discipline where you record 
all this customization.  This discipline is worthwhile for all the other 
payoffs:

- you are more aware of customization

- there is an incentive to reduce customization

- you no longer have to back up most of /root

- version upgrades are no longer scary irreversible leaps

I don't trust /home on an SSD.  My experience of SSD failure is worse
than my experience of spinning-disk failure.

Since I can re-install /root easily, I have no fear of installing it
on an SSD.

[Since I'm prepared to re-install, the risks of fedup are actually
low.]

I used to like to install from a CD because I did multiple installs
and I didn't want to waste network bandwidth downloading the same
packages for each installation.  Now the DVD installation saves very
little because so many packages are immediately updated after
installation.  Sigh.

I like to do my customization with CLI tools and keep logs of the commands 
I used.  I have tools to replay these logs, a step at a time.  I also have 
a lab book to write notes about what I've done.  Sadly, CLI tools are
not the primary ones for some tasks.

script(1) is your friend.  I actually have a better tool, but that's
another story.  Think how many times error messages have scrolled off
your screen.  script + yum update is better than "Software" or "Software
Update".

BTW, I have some Ubuntu LTS installations too.  They are meant for users
who just want something friendly (a clearer explanation would take too
long).  For those systems, I've used Ubuntu version upgrade processes.
They seem to mostly work too.

| From: lee <lee at yun.yagibdah.de>

| Reindl Harald <h.reindl at thelounge.net> writes:
| 
| > Am 07.07.2013 17:53, schrieb lee:
| >> If Fedora cannot be updated without major problems, it's
| >> not useable.

Until you do it, you cannot know if you will have major problems.  In
my modest experience, I've not hit major problems.  Once you do, you
might wish you'd done a backup.  Taking a backup and restoring it may
well be more work that a fresh install.

| > if you follow this guides *strictly* and willing to learn to deal
| > wtih "package-cleanup --leaves | --problems | --orphans and
| > to understand how your OS basically works you are fine
| > http://fedoraproject.org/wiki/Upgrading_Fedora_using_yum

This may well work.  But the effort of learning this technique and
gaining confidence in it is pretty expensive if you are only
maintaining one or two systems.  If you can amortize that effort over
a bunch of systems, why would you not instead use kickstart and
centrally designed configurations?

| When you look at the wiki, they are recommending to use fedup for
| upgrades, and they are saying "Upgrading directly from one release to
| the next using yum is not explicitly tested by Fedora QA"[1] and it
| might work only by chance because of "packaging guidelines providing
| detailed information on maintaining upgradability"[1].

That's pretty convincing to me.  Why blaze a new path?  You can tell
the pioneers by the arrows in their back.

I do think that it is unfortunate that yum isn't a supported method.
I'm all for reducing magic and making mechanisms understandable.
Fedup is packaged magic (how much, I don't know: I haven't looked
inside).

| Considering that Fedora does not have a working (and tested and
| supported) upgrade method at all

I don't understand that claim.  fedup (mostly) works, is tested, and
is supported.  And it is being used by a lot of other people, so they
can help you.  The scary part is that recovering from a failure isn't
guaranteed to be easy and it isn't (as far as I remember) documented.

| So we have three options to upgrade:
| 
| 1.) the recommended fedup which probably doesn't work

It mostly does.

| 2.) the untested and unsupported way using yum which might work or not

Right

| 3.) move away from Fedora and install a different distribution

Surely that's harder than simpler re-installation.

| > if you want simple fire&forget upgrades and not invest time
| > and energy to learn how the system basically works and what
| > major changes are meaning for you in case of upgrades use
| > CentOS or whatever LTS distribution

I don't that that that is reasonable.  I don't think that the Fedora
project supports that conclusion.

I want to pick my battles.  Making heavy weather of an upgrade is a
waste of my time.  I am willing to read release notes, but that's
about enough.

| Only by examining the configuration of the boot manager I was able to
| boot again.  That was just luck and I could have been left stranded with
| a non-bootable system.
| 
| Such behaviour is unacceptable.  My question is:  What went wrong?  Or
| was that even intended?

I agree that having to understand the boot manager is cruel and
unusual punishment.  It is unreasonable to ask users to do that.

(I've not tried to figure out your actual problem was, so I don't know
if you actually had to understand the boot manager.)