Bug 829936 - Preupgrade (F16 -> F17) - Unable to read package metadata due to mounting the wrong root partition
Preupgrade (F16 -> F17) - Unable to read package metadata due to mounting the...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: preupgrade (Show other bugs)
16
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-07 16:18 EDT by Bill C. Riemers
Modified: 2013-02-13 09:46 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 821738
Environment:
Last Closed: 2013-02-13 09:46:12 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bill C. Riemers 2012-06-07 16:18:57 EDT
+++ 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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.
Comment 1 Adam Williamson 2012-06-07 17:34:41 EDT
CCing Brian for an anaconda perspective; I don't know if we'd want to fix this in anaconda or preupgrade.
Comment 2 Brian Lane 2012-06-07 18:14:44 EDT
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.
Comment 3 Brian Lane 2012-06-07 18:15:29 EDT
oh, and related to the keyboard, preupgrade should be able to tell anaconda about that as well, by setting them in the ks.cfg
Comment 4 Fedora End Of Life 2013-01-16 08:51:46 EST
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
Comment 5 Fedora End Of Life 2013-02-13 09:46:14 EST
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.

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