Bug 244505 - [INFORMATION] Upgrading from FC6 to F7 via yum
Summary: [INFORMATION] Upgrading from FC6 to F7 via yum
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora Documentation
Classification: Fedora
Component: docs-requests
Version: devel
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ---
Assignee: Karsten Wade
QA Contact: Paul W. Frields
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-16 10:21 UTC by Răzvan Sandu
Modified: 2013-01-10 04:21 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-11 03:37:58 UTC
Embargoed:


Attachments (Terms of Use)

Description Răzvan Sandu 2007-06-16 10:21:03 UTC
Description of problem:


Hello,

I've experimented about upgrading an x86_64 machine running FC6 to F7 via yum,
not via CD. 


Here are the result of the experiment. ;-)
I don't know if the steps I've followed are correct, nor I specifically
recommend this procedure to anyone. I am posting this here only hoping to be of
help to the Fedora community, by drawing attention on the packages that seem to
have problems during upgrade.



The steps are:

1. I've took an x86_64 machine and performed a clean install of FC6 from DVD,
marking all packages that are available during install.

2. I did FC6 online updates, as of June 16, 2007.

3. From an official Fedora 7 repository, I've downloaded and installed
fedora-release-notes, via rpm.

4. I've forced the erasure of fedora-release package on the box
rpm -e --nodeps fedora-release

5. I've changed directory to /etc/yum.repos.d and erased all file inside it

6. From the same Fedora 7 repository, I've installed the new fedora-release package
rpm -Uvh fedora-release

7. I've customised the new .repo files in /etc/yum.repos.d in order to use
geographically close F7 mirrors (actually, a local private mirror).

8. Did the following:
yum clean all
yum -y --obsoletes upgrade

9. The following packages interrupted upgrade during the "resolve dependencies"
phase (probably broken dependencies):

mkinitrd
nash
pidgin


10. I've completely removed pidgin and installed the new nash and mkinitrd (and
their automatic dependencies). Then I've resumed upgrade:
yum -y --obsoletes install mkinitrd nash
yum -y --obsoletes upgrade

11. The dependencies were aparently OK, but I've got errors (conflicting files)
immediately before the install packages phase, from the following packages:

device-mapper
mysql
totem
esound
esound-libs
mysql-libs

12. I've manually installed device-mapper-libs

13. Manually removed mysql.i386 and then installed mysql and mysql-libs
rpm -e --nodeps mysql.i386
yum -y --obsoletes install mysql mysql-libs

14. I've manually removed totem.i386 and esound.i386, then resumed the upgrade
rpm -e --nodeps esound.i386
rpm -e --nodeps totem.i386
yum -y --obsoletes upgrade

15. From that point, the rest of the upgraded perdormed smoothly, in automatic.
db4.i386 and db4.x86_64 were automatically included as "updating for
dependencies", while other 111 packages were marked as "installing for
dependencies".

16. Checked that /boot/grub/grub.conf will boot the latest kernel

17.Did a:
touch /.autorelabel; reboot

18. Reinstalled pidgin
yum -y --obsoletes install pidgin

19. Installed a few pieces of software that I noted that are present and started
by default in F7: setroubleshoot, setroubleshoot-server, smolt.


What I apparently obtained is a fully functional installation of F7. No flaws
detected until now.


Regards,
Răzvan

Comment 1 Bill Nottingham 2007-06-18 03:54:41 UTC
This is probably best redirected to the docs product somehow.


Note You need to log in before you can comment on or make changes to this bug.