With the inclusion of fedora extras support in anaconda, has there
been any work done to improve upgrading between major releases? Here
are my thoughts on the subject in any case... :)
Whenever someone asks "Is it possible to update my FC4 installation to
FC5?" or the like, the answers are usually one of:
1. You can do it through yum if you're careful to just follow this
lengthy guide <link to website>, but then again you probably
2. Yes, just use the Upgrade option in Anaconda (but you may run into
trouble because of stale packages, configs or whatnot)
3. The best option is to just reinstall from scratch (you did make a
separate partition for /home, yeah?)
The first option is clearly a mine field and would be very hard to
support, so I think it should just be disregarded for now. I'd be more
interested in improving on the second option.
The current installation document only mentions that "Software which
you have installed manually on your existing Fedora Core or Red Hat
Linux system may behave differently after an upgrade.", which is fine
but doesn't really help the user in any way. As far as I can see, the
potential problems with an upgrade include:
- Some of your packages have been removed (or moved to Extras), and
some new ones might have appeared.
My experience with a FC3 -> FC4 upgrade (of an everything-install) was
that I was left with a lot of stale packages from FC3 and I missed out
on the new stuff like Eclipse on my upgraded FC4 install. Would it be
viable to add a "Review package differences" screen to Anaconda? It
would be nice to be presented with a list of new software that you may
or may not choose to install, as well as a list of stale packages that
you probably want to get rid of or find alternatives for in Extras or
- Your configurations may become invalid (both systemwide in /etc and
per user dotfiles/directories).
Systemwide configurations that are unchanged should probably just be
replaced by newer ones _if they are unchanged_, but I think the
current procedure just installs them as .rpmnew? Would it be possible
to rename the old ones as .rpmold.fc3 if this is the case?
Configurations that are changed by the user should of course not be
replaced, but I think they should be logged to a separate file in the
root account so that it's possible to review these for the user and
check that they're still valid. All this would require sha1 sums of
configuration files from old rpm's so I guess it's hard to implement.
The per-user configuration stuff is harder to deal with. I've had
sufficient trouble with this in the past to generally just get rid of
most (if not all) of my user configuration stuff, and just keep my
documents from /home. No good ideas here really...
- 3rd party software (like Maple in my case), and software that you
have built and installed yourself (worst case: ./configure; make
install) is likely to run into trouble. Maple is mostly "self
sufficient" when it comes to library dependencies, other things are
probably built agains system libraries and is likely to fail. I don't
know of any other solution to this than to warn the user that this
might be the case. Is there such a warning in Anaconda? Or only in the
As for the 3rd option, reinstall from scratch but keep /home, would it
be possible to improve on the suggestion for automatic partitioning to
also include a separate /home partition? If this was combined with an
upgrade option that clearly stated that it will swipe the system, but
keep your /home partition, I guess this would be the most comfortable
upgrade path for many home users. (I agree you should still backup
your data before attempting an upgrade, but why not make it a bit less
likely that you'll have to restore that backup :)).
I'd be interested to hear if anyone else has opinions here and like I
said earlier, if there's any extra effort that has allready gone into
alleviating the pain of upgrades I'd be interested to learn about it.
So, I noticed while doing my first FC5t1 install the upgrades aren't
currently supported in the reworked anaconda. Fair enough; there's a lot of
changes under the hood. But that got me thinking: hey, maybe this is a great
time to get it so that "yum upgrade" can actually easily bring one from one
FC release to the next. (More realistically, maybe FC6 is a great time. But
now might be a time to start thinking about it.)
I know there's historically been a lot of wacky special-casing in Anaconda,
much of it legacy cruft, and much of it kinda important for, y'know,
actually working upgrades.
With switching to a yum-based backend, I imagine that much of this cruft
must be updated. Maybe Jeremy's doing it this way already, but what about
packaging that special-case knowledge into a "distroupgrade" yum plugin
instead of into Anaconda itself, wherever possible? (Some things are easier
done off-line, of course, but maybe those could be made to happen in
firstboot or so?)
As an experiment in support of this hallucinogen-addled fantasy, I installed
a fresh system FC4 system (Workstation install), used yum to apply all
current updates, and then changed the repo config to point at FC5t1. I first
ran yum upgrade yum and then a full "yum -y upgrade".
After some time, this failed, because iiimf-libs is gone, with no
replacement or nothing to obsolete it but with a chain of dependencies.
Quick fix was to just remove that package and try again.
Now, two things -- initscript and kudzu -- failed because of requirements on
kernel < 2.6.12 and 2.6.13, respectively. After some head-scratching, this
turned out to be caused by Conflicts statements and the previously-installed
2.6.11 kernel. (The newly installed-then-yum-upgraded system had the
original FC4 2.6.11 and the newest FC4 2.6.14 both installed, of course.)
Sort ironically, the installonlyn plugin would have actually corrected this
situation, because the result after the upgrade would be to have the FC4
2.6.14 plus the FC5 2.6.14. Anyway, I worked around this by simply removing
the old 2.6.11 kernel.
After that, the yum upgrade went basically fine, and after Some Time passed,
I have what appears to be a fully functional FC5 system. I haven't poked
around too much to find broken spots, and there were a lot of messages about
.rpmsave and .rpmnew, so looking at those is probably in order. But I can
log in to Gnome, browse the web, run OpenOffice, and so on.
But overall, seemed like a pretty successful experiment. And, given the
super-short lifespan of FC releases, something I'd really be interested in
having as an option.
-- smokin' the good stuff,
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
Tried using locate on rawhide machine...
[root@dhcp83-80 ~]# locate iso
locate: can not open `/var/lib/mlocate/mlocate.db': No such file or directory
[root@dhcp83-80 ~]# updatedb
updatedb:/etc/updatedb.conf:2: unknown variable `DAILY_UPDATE'
[root@dhcp83-80 ~]# rpm -qf /usr/bin/updatedb
Is this a known problem?
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
Is there any work being done for a modern update system that would only
download what is needed instead of an entirely new rpm? I'm sure everyone
has seen the updaet system that Firefox has. It's beautiful. How is that
going to work on Fedora Core 5? Is it disabled? Eitherway, such an update
system on Linux would be a watershed moment perhaps. A grand slam. It is a
bit ridiculous that FC4 updates have possibly mounted up to 10 GB for me..
maybe an exaggeration but you know what I'm getting at.
So any such project out there?
Here in swiss we are using fr_CH keyboards. Each time we are installing a
FC4, firstboot runs in FR keyboard layout. So it's difficult to add user at
Here is a little patch to allow rhgb to run in fr_CH keyboard layout when
/etc/sysconfig/keyboard KEYTABLE key is set to fr_CH or fr_CH-latin1.
Why is the "check_for_language" function in main.c splitting by the key "_"?
POSEIDON Project Manager
EPFL - DIT - DIT-SB
Ecole Polytechnique Fédérale de Lausanne - EPFL
Tel: (+41) 021 693 2266
Please see bug
It seems that with Everything install option gone in FC5 test1, one
cannot install all packages from CD. I'm still downloading it so I
cannot test by myself yet, but Jeremy's reply suggests it won't be added
back (how are the package groups handled with multiple repositories?).
In previous Fedora versions, there was also the Details button for a
package group, is this gone too? There one could have manually selected
additional packages, and this is a solution.
If both these options are gone, then should the packages which aren't
installed by default if all groups are selected be moved to Fedora