This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours

Bug 473016

Summary: Preupgrade to F10 (with multiple Fedora partitions) gives "Unable to read package metadata" error on reboot
Product: [Fedora] Fedora Reporter: Noel <inkybutton>
Component: preupgradeAssignee: Seth Vidal <skvidal>
Status: CLOSED NEXTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 10CC: fortran, jbev, jochen, k2patel, oliver, wwoods, zing
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.1.0-1.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-28 04:13:20 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On: 471232    
Bug Blocks:    
Attachments:
Description Flags
Output of blkid
none
/boot/upgrade/ks.cfg none

Description Noel 2008-11-25 22:58:54 EST
Description of problem:

I used preupgrade today to upgrade from F9 to F10. After downloading all the packages, it asked me to reboot. After it did so, anaconda was started, and there were several message that came up.

1. "Unable to mount hda6 to /mnt/hda6" - I thought it isn't important, so I clicked on Continue.
2. "Downloading repository information from repository"
3. "Retrying downloading"
4. "Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated.
Cannot retrieve repository metadata (repomd.xml) for repository anaconda-InstallationRepo-200811191949.i386. Please verify its path and try again." The options were Exit Installer, Retry, Edit, and Continue.

When I clicked on Edit I was prompted to enter a path to the repository. However, there was a popup that said "Unable to display /Nothing/var/cache/yum/" - which may be a hint.
When I tried "Retry" it said "unable to generate install tree".

What should I do so I can install F10?

Version-Release number of selected component (if applicable):
anaconda 11.4.0.83
preupgrade 1.0.0-1.fc9

How reproducible:
Not easily. Haven't heard reports of the same problem.

Steps to Reproduce:
1.Use preupgrade and choose to upgrade from F9 to F10.
2.Reboot when prompt
3.Wait for "Upgrade to Fedora 10" to boot.
  
Actual results:
See problem description.

Expected results:
Fedora 9 to be upgraded to Fedora 10.

Additional info:
Preupgrade is a koji build.
Comment 1 Noel 2008-11-26 00:42:30 EST
In the problem description:
Unable to display
/Nothing/var/cache/yum/

should read:
cannot state the folder /None/var/cache/yum/preupgrade/ - no such file or directory exists.

I made a symlink of /None -> / - still say the same thing.
Comment 2 Noel 2008-11-26 00:45:27 EST
Also, anaconda is version 11.4.1.62, not 11.4.0.83 as stated.
Comment 3 Matt Thompson 2008-11-26 13:51:51 EST
I just got hit by this bug on an x86_64 preupgrade as well.  And I am stumped as to how to fix it!
Comment 4 Matt Thompson 2008-11-26 13:56:26 EST
Oh and, in my case, I am using the preupgrade that was supplied by updates-newkey, not the koji build (although they could be the same).
Comment 5 Matt Thompson 2008-11-26 14:27:44 EST
I also get an odd /None/cache/yum/preupgrade problem on mine.  It looks like one difference between my and Noel's setup is that I have /var as a separate partition.  Thus, when I look at grub.conf, repo is pointing to the UUID of /var while stage2 and ks contain the UUID of my /boot partition.  

Unfortunately, I really don't know grub/preupgrade/whatever UUID syntax, so I have no idea on how to fix that.  Is there a way to use more standard grub drive calls instead of UUIDs?  That is:

repo=/var/cache/yum/preupgrade OR
repo=(hd0,4)/cache/yum/preupgrade (my var is in /dev/sdc5)

instead of:

repo=hd:UUID=2234abe...304a:/cache/yum/preupgrade

with similar ones for stage2 and ks using (hd0,0) since /boot = /dev/sdc1?

(Note, even though it is /dev/sdc, it is hd0.  I have to do some odd BIOS remapping with my dual-boot.  So, oddly, sdc = hd0 and grub agrees.)
Comment 6 Noel 2008-11-26 17:44:00 EST
Hey Matt,
I finished installing Fedora 10 successfully by omitting the ks file location specification. (i.e. remove ks=... from /boot/grub/menu.lst) You may want to try doing that - though I have a feeling that it won't work on your machine because we have different problems. Still, give it a try :)

The bug still exists however - this is just a little hack to get around it.
Comment 7 Will Woods 2008-12-01 11:15:55 EST
The UUID=xxxx stuff is *not* used by GRUB - it's passed along to anaconda. So GRUB syntax won't do anything there. But 'repo=hd:sdc4:/cache/yum/preupgrade' would probably work fine.

You can also use the 'blkid' command to list the UUIDs and labels for your available disk volumes, or look in /dev/disk/by-uuid etc.
Comment 8 Will Woods 2008-12-01 11:19:34 EST
How are your disks set up? Is /var on a separate partition? Any RAID devices set up? The output of 'blkid' would be helpful here.
Comment 9 Jochen Schmitt 2008-12-01 11:31:46 EST
I have find out, that preupgrade doesn't work properly, if you have a separate /var partition. In this scenario repo will point to /mnt/sysimage//cache/yum/...

As a workaround you can do

รค cd /mnt/sysimage
# ln -sf var/cache cache

After this workaround a could upgrade to F-10 well.
Comment 10 Noel 2008-12-01 15:16:17 EST
$blkid
/dev/sda6: LABEL="/mnt/data" UUID="479A-ED7C" TYPE="vfat" 
/dev/sda7: LABEL="/" UUID="4701d910-532b-4f6e-92a5-8c6f9a33e7e8" SEC_TYPE="ext2" TYPE="ext3" 
...
/dev/sda11: LABEL="/123" UUID="eabcc434-08c2-4a79-a64e-c623539989b0" TYPE="ext3" SEC_TYPE="ext2" 
...
/dev/sda12: LABEL="/home1" UUID="f96f8041-0ef4-4797-862e-839b16ee916e" TYPE="ext3" SEC_TYPE="ext2"
...
/dev/sda14: UUID="48ED-BAC3" TYPE="vfat" 

Note that /dev/sda11 is my Fedora 9 root partition, and /dev/sda12 my /home partition. I also have a separate Fedora Core 6 installation, with /dev/sda7 as the root.

/var is not on a separate partition and AFAIK there are no RAID devices.
Comment 11 Matt Thompson 2008-12-03 09:11:06 EST
(In reply to comment #7)
> The UUID=xxxx stuff is *not* used by GRUB - it's passed along to anaconda. So
> GRUB syntax won't do anything there. But 'repo=hd:sdc4:/cache/yum/preupgrade'
> would probably work fine.
> 
> You can also use the 'blkid' command to list the UUIDs and labels for your
> available disk volumes, or look in /dev/disk/by-uuid etc.

I think I got this to work by using this:

repo=hd::/var/cache/yum/preupgrade

By looking over the other ttys (I think F3...) I saw that it was trying to find:

///mnt/sysimage//cache/yum/preupgrade

when I tried, repo=hd:sdc5:/cache/yum/preupgrade.  So, it seemed like it just didn't translate sdc5 as /var.  So, well, I did the next logical thing.

Oddly, I had to keep the ks and stage2 as hd:sdc1: or at least I couldn't figure out the right translation out of that (and it worked, so I didn't touch much).

I'm currently in the anaconda package installation, so I'm guessing it found the repo.
Comment 12 Will Woods 2008-12-05 13:15:08 EST
(In reply to comment #11)

> I think I got this to work by using this:
> 
> repo=hd::/var/cache/yum/preupgrade

This makes sense - repo=XXX isn't used until *after* anaconda finds your filesystem and mounts it for upgrading. At that point, /var has already been mounted (from your /etc/fstab), so we don't actually need to tell anaconda to mount that device.

If we tell anaconda to get the packages from ':sdc5:/cache/yum/preupgrade', it notices that sdc5 is already mounted, and skips mounting the device. It doesn't bother checking *where* it's been mounted, though - it just looks for /cache/yum/preupgrade on the mounted system. 

So that's why telling it to just look at hd::/var/cache/yum/preupgrade works. Whether that's a bug or a feature is debatable.

"repo=hd:root:/var/cache/yum/preupgrade" should also work.
Comment 13 Will Woods 2008-12-05 13:25:08 EST
We've got two separate problems listed in this bug.

1) preupgrade fails if you have a separate /var partition. (bug 473782)

That's what Matt and Jochen saw. I have a workaround for this that will be in the next preupgrade build. As noted in the previous comments, you can work around that by changing the repo=XXX argument to read:
  repo=hd::/var/cache/yum/preupgrade

2) The original problem - "Unable to read package metadata..."

Noel, did you use preupgrade-cli? There was a bug in the repodata creation in preupgrade-cli that caused some errors like this.
Comment 14 Noel 2008-12-11 01:06:19 EST
Hi Will,
no I didn't. I used the normal preupgrade - I didn't even know preupgrade-cli existed!

BTW just a reminder, I am now able to run Fedora 10 after doing what I described in comment #6.
Comment 15 James C. Bevier 2008-12-17 18:31:06 EST
I am getting the error "Unable to read package metadata....." when trying to upgrade from F9 -> f10.  Anaconda insists that my /root partition is on /dev/sda6 and /boot is on /dev/sda1.  This is true for an already upgraded F9 X86_64 system on this drive.  I am trying to upgrade a F9 i686 system that has /root on /dev/sda7.  The UUIDs are correct and the grub entry is pointing to the proper partition for an i386 update. All the yum entries are OK.  GRUB is installed on /dev/sda7 for the i686 partition and on /dev/sda for the F10 system on /dev/sda6 (/dev/sda1).  I was able to finish the upgrade by following the method described in #6 above.  It seems anaconda is using the GRUB information from /dev/sda, not /dev/sda7.  Another thing that anaconda does is rewrite the /etc/fstab file in the partition for the X86_64 system (/dev/sda6).  This seems like a straight forward configuration that a user who wants 64 & 32 bit systems installed on the same drive would use.
Comment 16 Will Woods 2008-12-17 23:50:04 EST
(In reply to comment #15)
> I am getting the error "Unable to read package metadata....." when trying to
> upgrade from F9 -> f10.  Anaconda insists that my /root partition is on
> /dev/sda6 and /boot is on /dev/sda1.  This is true for an already upgraded F9
> X86_64 system on this drive.

You have multiple Fedora installs on your system. Preupgrade knows which system to upgrade, but there's no way to tell the F10 installer.

Either remove the 'upgrade' line from ks.cfg, or remove the 'ks=...' parameter from the boot line entirely. This will cause anaconda to ask which partition to upgrade, and then you should be fine.
Comment 17 Fedora Update System 2009-04-28 18:07:22 EDT
preupgrade-1.1.0-0.pre2.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/preupgrade-1.1.0-0.pre2.fc10
Comment 18 Fedora Update System 2009-05-02 12:41:39 EDT
preupgrade-1.1.0-0.pre2.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update preupgrade'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4211
Comment 19 Fedora Update System 2009-05-13 18:46:46 EDT
preupgrade-1.1.0-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/preupgrade-1.1.0-1.fc9
Comment 20 Fedora Update System 2009-05-13 18:47:42 EDT
preupgrade-1.1.0-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/preupgrade-1.1.0-1.fc11
Comment 21 Fedora Update System 2009-05-15 19:33:44 EDT
preupgrade-1.1.0-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update preupgrade'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-4211
Comment 22 Fedora Update System 2009-05-28 03:57:57 EDT
preupgrade-1.1.0-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 23 Fedora Update System 2009-05-28 04:10:43 EDT
preupgrade-1.1.0-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Fedora Update System 2009-05-28 04:12:42 EDT
preupgrade-1.1.0-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 25 oliver 2009-07-06 08:32:53 EDT
But is not resolved for me: Upgrading from Fedora 10 to Fedora 11 on a system with one Ubuntu and two Fedora partitions, everything else vanilla.

Latest package preupgrade-1.1.0-1.fc10 installed.

Noticed that the grub.conf entry read:

title Upgrade to Fedora 11 (Leonidas)
	kernel /boot/upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade stage2=hd:UUID=88980f78-8c84-4c7c-9ec5-d84b8523ade8:/boot/upgrade/install.img ks=hd:UUID=88980f78-8c84-4c7c-9ec5-d84b8523ade8:/boot/upgrade/ks.cfg

i.e. repo did not have a hard disk UUID.  However, adding one did not help.  In both cases, after reboot, I get error message from installer "Unable to read repository data" as described above.

Following comment #16 and deleting the ks=... entry from the boot line above, however, did help.
Comment 26 Will Woods 2009-07-06 12:00:48 EDT
Having no UUID on the hd:: line is *intended*. In preupgrade mode, Anaconda assumes that the repo is located on the device/filesystem chosen for upgrade. That device is specified in the kickstart 'upgrade' line, so it's not necessary (or useful) to list it in the boot commandline.

The problem is that the device listed for upgrade in the kickstart file is incorrect (or misunderstood by anaconda). If you compare the root device listed on the 'upgrade' line of the kickstart to the output of 'blkid', that might give some clue about why anaconda can't find your root device (and therefore the install repo).

Unfortunately you seem to have worked around the problem and probably don't have the kickstart anymore, so we can't really examine this any further.
Comment 27 oliver 2009-07-07 05:24:26 EDT
I can give you some more information, in case this helps:

The machine is a Dell XPS M1330 laptop which came preinstalled with Ubuntu.  I installed Fedora by shrinking the original Ubuntu partition without deleting it.  Since I did not have similar problems on a second laptop with had the same Fedora layout, but without the original Ubuntu around, I suspect that the bug is somewhat related to this specific partitioning scheme.

I attach the output of my blkid.

As far as I can see, the kickstart file is correct (also attached).  It does not appear to have been modified through the upgrade process.

Let me know if you need further info.
Comment 28 oliver 2009-07-07 05:25:45 EDT
Created attachment 350755 [details]
Output of blkid
Comment 29 oliver 2009-07-07 05:27:01 EDT
Created attachment 350756 [details]
/boot/upgrade/ks.cfg
Comment 30 Ketan Patel 2011-11-09 10:15:32 EST
Hello,

This is still an issue with release of Fedora 16 not sure why it is keep closed As of next release there is one which was close because EOL.

Another EOL - Closed 
https://bugzilla.redhat.com/show_bug.cgi?id=504991

I am replying to this because it is not yet resolved and this need to stay open OR it need to recreated with new release ID.

Thank you.