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
Setting as F17 blocker
When Anaconda fails Please switch to tty2 (ctrl-alt-f2) and attach the logs from /tmp/*log to this bug as individual plain/text files.
it rather sounds like the reproduction scenario should also include 'have a LUKS-encrypted partition on the system to be updated'... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
At a first try, I can't reproduce this with current F16 preupgrade and dl.fedoraproject.org as the server, no LUKS partition on the system to be upgraded. I'll try again with a LUKS partition.
Can't reproduce with a LUKS partition on the system to be upgraded, either. Neither can tflink. What partitions were encrypted, exactly? Is it possible you entered the passphrase incorrectly? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Sadly, I upgraded by other means since, and an unable to reproduce the issue. So I guess the only thing here is to close it as notabug?
If two others can't reproduce and neither can you and you don't have the logs, then yeah, we'll have to close it. :/ -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
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!
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.
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
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.
Please create a new bug.
I experienced this myself and this is what I found (for the benefit of those who end up here). Aa a precaution I always create an LV called "rootcopy" and copy the root LV to it before upgrading. I did this and then ran "preupgrade" and rebooted and was met with the issue mentioned in the OP. I then looked at what was mounted and found that my "rootcopy" LV had been mounted as / instead of my actual root LV. I modified /boot/preupgrade/ks.cfg from this... # ks.cfg generated by preupgrade lang en_US.UTF-8 keyboard us bootloader --upgrade --location=none clearpart --none upgrade --root-device=UUID=None reboot %post grubby --remove-kernel=/boot/upgrade/vmlinuz rm -rf /boot/upgrade /var/cache/yum/preupgrade* %end to this... # ks.cfg generated by preupgrade lang en_US.UTF-8 keyboard us bootloader --upgrade --location=none clearpart --none upgrade --root-device=UUID=da9d723f-4de1-4267-b189-4ad1d9c72606 reboot %post grubby --remove-kernel=/boot/upgrade/vmlinuz rm -rf /boot/upgrade /var/cache/yum/preupgrade* %end ... and all was good (that UUID is of course the UUID of my actual root (/) partition (in my case an LV). So that explains what happened and how to fix it but not why.