Bug 473016

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.

Also, anaconda is version 11.4.1.62, not 11.4.0.83 as stated.

I just got hit by this bug on an x86_64 preupgrade as well.  And I am stumped as to how to fix it!

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).

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.)

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.

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.

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.

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.

$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.

(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.

(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.

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.

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.

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.

(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.

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

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

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

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

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

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.

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.

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.

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.

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.

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.

Created attachment 350755 [details]
Output of blkid

Created attachment 350756 [details]
/boot/upgrade/ks.cfg

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.