+++ This bug was initially created as a clone of Bug #821738 +++ Created attachment 584666 [details] Error message Description of problem: After running preupgrade in F16 and rebooting, anaconda starts, prompts for the LUKS password, and then error "Unable to read package metadata. This may be due missing repodata directory..." occurs. Version-Release number of selected component (if applicable): preupgrade-1.1.10-1 How reproducible: Always Steps to Reproduce: 1. in F16 run `yum update; yum install preupgrade` 2. run preupgrade 3. reboot to preupgrade Actual results: Error is shown Expected results: Upgrade is completed sucessfully --- Additional comment from briemers on 2012-06-06 17:32:05 EDT --- Same problem. I have full disk encryption, which means everything except /boot, and the windows junk that was shipped on the laptop. I tried repeating the procedure several times, and each time I get the same error. Incidently a second bug is when it prompts for the password it only accepts QWERTY input, even though my keyboard layout is normally DVORAK. I had to key in my passcode about twenty times to get it right... :( I'm going to try it again right now, so I can collect the logfiles. In the mean time here is some other information that may be useful: [briemers@briemersw tmp]$ more /etc/fstab # # /etc/fstab # Created by anaconda on Wed Aug 3 19:27:25 2011 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/vg_docbillthink-root / ext4 defaults 1 1 UUID=e3081b9b-52b7-4a7b-995b-925ecff83e85 /boot ext4 defaul ts 1 2 /dev/mapper/vg_docbillthink-home /home ext4 defaults 1 3 /dev/mapper/vg_docbillthink-swap swap swap defaults 0 0 /dev/vg_docbillthink/data /data ext4 defaults 1 4 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 [root@briemersw ~]# pvdisplay --- Physical volume --- PV Name /dev/mapper/luks-a6e5fa16-10c9-4ebb-bff6-75ec4f609ae1 VG Name vg_docbillthink PV Size 334.57 GiB / not usable 5.03 MiB Allocatable yes (but full) PE Size 32.00 MiB Total PE 10706 Free PE 0 Allocated PE 10706 PV UUID A2RZks-tv7V-6lQr-s3z1-oiAP-lMD5-hXSqWW [root@briemersw ~]# vgdisplay --- Volume group --- VG Name vg_docbillthink System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 18 VG Access read/write VG Status resizable MAX LV 0 Cur LV 5 Open LV 4 Max PV 0 Cur PV 1 Act PV 1 VG Size 334.56 GiB PE Size 32.00 MiB Total PE 10706 Alloc PE / Size 10706 / 334.56 GiB Free PE / Size 0 / 0 VG UUID S9am8D-H6wI-lMd5-gCbu-MkGi-euA9-juDIQ1 [root@briemersw ~]# fdisk /dev/sda Command (m for help): p Disk /dev/sda: 500.1 GB, 500107862016 bytes 255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x29018459 Device Boot Start End Blocks Id System /dev/sda1 * 2048 2459647 1228800 7 HPFS/NTFS/exFAT /dev/sda2 2459648 253620234 125580293+ 7 HPFS/NTFS/exFAT /dev/sda3 253620235 254644234 512000 83 Linux /dev/sda4 254644235 976773167 361064466+ 5 Extended /dev/sda5 254646283 275126283 10240000+ 7 HPFS/NTFS/exFAT /dev/sda6 275130368 976773119 350821376 83 Linux Command (m for help): q! --- Additional comment from briemers on 2012-06-06 17:33:24 EDT --- Oh I don't know if it is relevant, but I also have my router setup as an autoproxy. I guess that might effect things if pre-upgrade tries to collect data from the internet when booted from the upgrade image. --- Additional comment from briemers on 2012-06-06 17:54:10 EDT --- Created attachment 590026 [details] log files Here are the log files. I think though in the process of capturing them I spotted the bug: [root@briemersw /]# lvscan ACTIVE '/dev/vg_docbillthink/lv_root' [25.53 GiB] inherit ACTIVE '/dev/vg_docbillthink/home' [105.00 GiB] inherit ACTIVE '/dev/vg_docbillthink/swap' [8.00 GiB] inherit ACTIVE '/dev/vg_docbillthink/root' [51.06 GiB] inherit ACTIVE '/dev/vg_docbillthink/data' [144.97 GiB] inherit Here is the problem both lv_root and root are root partitions. lv_root is from Fedora 14, root is my current root partition. When I copied the log files to /mnt/sysimage/. and then rebooted them, the files where not in / upon reboot. So the problem is simply pre-upgrade is using the wrong root!!! Apparently, it is not setting an option to pass that information to itself on reboot, so it is just grabbing the first partition it think's looks like a root partition. I will write a leading block of 0's to lv_root to temporarily disable it, and see if preupgrade then picks up the correct root partition. Bill --- Additional comment from briemers on 2012-06-06 20:10:42 EDT --- Indeed that was the problem. It looks like this bug is actually caused by something completely different than in the subject. Would you like me to change the bug to reflect the actual problem, or clone this bug to create a new one with the appropriate subject? The fix would be to either create a unique file in the root filesystem than preupgrade could find later when scanning for root, or to pass an argument with grub to let preupgrade know what the root file system uuid is, or that information could just be written to the boot image.
CCing Brian for an anaconda perspective; I don't know if we'd want to fix this in anaconda or preupgrade.
This is a preupgrade problem, it isn't setting the upgrade root correctly in the ks.cfg so anaconda mounts the first root it finds.
oh, and related to the keyboard, preupgrade should be able to tell anaconda about that as well, by setting them in the ks.cfg
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is 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" 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
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.