Bug 821738 - Preupgrade (F16 -> F17) - Unable to read package metadata
Preupgrade (F16 -> F17) - Unable to read package metadata
Product: Fedora
Classification: Fedora
Component: preupgrade (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F17Blocker/F17FinalBlocker
  Show dependency treegraph
Reported: 2012-05-15 09:23 EDT by Josef Skladanka
Modified: 2012-07-02 01:10 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 829936 (view as bug list)
Last Closed: 2012-06-07 14:47:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
Error message (1.89 MB, image/jpeg)
2012-05-15 09:23 EDT, Josef Skladanka
no flags Details
log files (330.00 KB, application/x-tar)
2012-06-06 17:54 EDT, Bill C. Riemers
no flags Details

  None (edit)
Description Josef Skladanka 2012-05-15 09:23:56 EDT
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):


How reproducible:


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
Comment 1 Josef Skladanka 2012-05-15 09:25:59 EDT
Setting as F17 blocker
Comment 2 Brian Lane 2012-05-15 11:06:45 EDT
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.
Comment 3 Adam Williamson 2012-05-15 12:26:56 EDT
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
Comment 4 Adam Williamson 2012-05-15 14:09:53 EDT
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.
Comment 5 Adam Williamson 2012-05-16 02:02:23 EDT
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
Comment 6 Josef Skladanka 2012-05-16 05:27:07 EDT
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?
Comment 7 Adam Williamson 2012-05-16 12:59:54 EDT
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
Comment 8 Bill C. Riemers 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!
Comment 9 Bill C. Riemers 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.
Comment 10 Bill C. Riemers 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.

Comment 11 Bill C. Riemers 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.
Comment 12 Adam Williamson 2012-06-07 14:47:41 EDT
Please create a new bug.
Comment 13 Brad Hubbard 2012-07-02 01:10:10 EDT
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

grubby --remove-kernel=/boot/upgrade/vmlinuz
rm -rf /boot/upgrade /var/cache/yum/preupgrade*

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

grubby --remove-kernel=/boot/upgrade/vmlinuz
rm -rf /boot/upgrade /var/cache/yum/preupgrade*

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

Note You need to log in before you can comment on or make changes to this bug.