Bug 645860

Summary: preupgrade error F13->F14 - Unable to read package metadata
Product: [Fedora] Fedora Reporter: Zach Carter <os>
Component: preupgradeAssignee: Richard Hughes <rhughes>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: felix, garrett.mitchener, jhhaynes, rhughes, stephent98
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 15:56:14 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
1st error message
none
2nd error message none

Description Zach Carter 2010-10-22 13:08:08 EDT
Description of problem:

On a F13 system, after successfully running preupgrade, and booting into the upgrade, I get an error "Unable to read package metadata".

Farther down, it says:

Cannot retrieve repository metadata (repomd.xml) for repository: anaconda-InstallationRepo-201010211522.x86_64.  Please verify it's path and try again.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Zach Carter 2010-10-22 13:10:53 EDT
The files are all here:


/var/cache/yum/preupgrade/repomd.xml
/var/cache/yum/preupgrade/repodata/repomd.xml
/var/cache/yum/preupgrade-main/repomd.xml
/var/cache/yum/preupgrade-rpmfusion-free-rawhide/repomd.xml
/var/cache/yum/preupgrade-rpmfusion-nonfree-rawhide/repomd.xml
Comment 2 Zach Carter 2010-10-22 13:14:55 EDT
Note: the root filesystem containing the preupgrade repositories has a couple of layers, in particular:

Two lvm devices:

  LV Name                /dev/fastvg/slash_mirror_1
  LV Name                /dev/fastvg/slash_mirror_2

Are mirrored together into an md array:

md1 : active raid1 dm-9[0] dm-10[1]
      46706624 blocks [2/2] [UU]
      
As I recall, this configuration worked just fine preupgrading from F12 to F13.
Comment 3 Jeffrey C. Ollie 2010-10-28 10:40:47 EDT
I'm seeing the same problem.  I've got a fairly basic system with two VG groups, one for the root/swap partitions and one for /srv.

http://www.smolts.org/client/show/pub_af2459be-3ce1-47ce-92db-20444bb4fe60
Comment 4 Jeffrey C. Ollie 2010-10-28 11:43:30 EDT
Created attachment 456277 [details]
1st error message
Comment 5 Jeffrey C. Ollie 2010-10-28 11:44:01 EDT
Created attachment 456278 [details]
2nd error message
Comment 6 Jeffrey C. Ollie 2010-10-28 11:47:18 EDT
I've added a couple of screenshots of the error messages that I get. The 2nd error message is what you get when you click "continue" in the 1st diaglog box.
Comment 7 Zach Carter 2010-10-28 12:25:58 EDT
Another data point:  Regular upgrade with the Fedora 14 RC DVD does not have this problem.
Comment 8 Richard Hughes 2010-11-01 06:00:32 EDT
These are anaconda messages, no?
Comment 9 Jeffrey C. Ollie 2010-11-01 08:43:57 EDT
(In reply to comment #8)
> These are anaconda messages, no?

Yes, but is the bug in Anaconda that can't read a valid repository or is the bug with preupgrade that is creating an invalid repository?
Comment 10 Zach Carter 2010-11-01 13:04:32 EDT
I have a question.   Does preupgrade use the existing repositories defined in /etc/yum.repos.d, or does it download new mirror/repo information from the internet somewhere?

To rephrase:  If I have customized my /etc/yum.repos.d directory, will it affect the preupgrade process?
Comment 11 Jim Haynes 2010-11-03 19:32:58 EDT
I had the same problem with an i386 system, get the same error messages.
Comment 12 Garrett Mitchener 2010-11-04 12:08:39 EDT
I have the same problem upgrading a 64 bit installation of F13.  I installed and ran preupgrade.  But there are no repomd files in /mnt/sysimage/var/cache/preupgrade.  Instead, there's a mirros.txt and an empty packages/ directory.
Comment 13 Garrett Mitchener 2010-11-04 12:22:17 EDT
Is there supposed to be a difference between running preupgrade as a regular user and typing the root password, vs. doing su and running preupgrade?  After rebooting, I ran su, then preupgrade, and it downloaded a bunch more stuff...  Now there is most definitely a repomd.xml file.  I'm also trying to determine if it somehow got confused: I have a backup file system with an old installation of fedora and it might be trying to upgrade that when I reboot?
Comment 14 Garrett Mitchener 2010-11-04 14:24:28 EDT
I have the same problem upgrading a 64 bit installation of F13.  I installed and ran preupgrade.  But there are no repomd files in /mnt/sysimage/var/cache/preupgrade.  Instead, there's a mirros.txt and an empty packages/ directory.
Comment 15 Garrett Mitchener 2010-11-04 14:36:42 EDT
(Sorry for the duplicate comment...)

I figured out that when I reboot, anaconda is stubbornly insisting on trying to upgrade my backup disk which has an old installation of Fedora on it, and of course, there's nothing useful in /var/cache/yum there.

I got the upgrade to work by changing /boot/upgrade/ks.cfg.  I had to google for the documentation for this file,

http://fedoraproject.org/wiki/Anaconda/Kickstart

and after a lot of trial and error, I came up with changing some lines in this file to:

upgrade --root-device=/dev/mapper/Grograman00-root
ignoredisk --only-use=/dev/sdh

where my useful fedora installation has its root at /dev/mapper/Grograman00-root, and the device for that particular whole hard disk is /dev/sdh.  With that fix, the upgrade seems to be working now, fingers crossed.

I tried upgrade --root-device=LABEL=ROOT, because my root file system has the label "ROOT" and I boot with the option root=LABEL=BOOT, and that didn't work.  It still tried to install to my backup disk.  I also tried ignoredisk --drives=/dev/sdg which I think should have told anaconda to ignore my backup disk sdg, and that didn't work either.

Anyway, the problem seems to be that something goes wrong when anaconda tries to figure out which of multiple installations to upgrade, and it's not clear to me exactly how to specify it in the kickstart file /boot/upgrade/ks.cfg.
Comment 16 Felix Bellaby 2010-12-07 13:16:06 EST
I got around this particular problem by removing the --root-device= option to kickstart upgrade command in /boot/upgard/ks.cfg. I.E. by changing

upgrade --root-device=UUID=...

to

upgrade

preupgrade had correctly set the UUID for the root filesystem containing the  /var/cache/yum/ repositories, but it appears that anaconda found it easier to locate these repositories when it was left to guess where they were rather than being given the UUID as a hint. Therefore, this would appear to be a bug in the way that anaconda handles of the --root-device=UUID= option to the upgrade command in the kickstart file.

BTW - the root filesystem in question was a LV in a VG on a RAID 10 PV.
Comment 17 Fedora End Of Life 2012-08-16 15:56:16 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping