Red Hat Bugzilla – Bug 829936
Preupgrade (F16 -> F17) - Unable to read package metadata due to mounting the wrong root partition
Last modified: 2013-02-13 09:46:14 EST
+++ This bug was initially created as a clone of Bug #821738 +++
Created attachment 584666 [details]
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):
Steps to Reproduce:
1. in F16 run `yum update; yum install preupgrade`
2. run preupgrade
3. reboot to preupgrade
Error is shown
Upgrade is completed sucessfully
--- Additional comment from firstname.lastname@example.org 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
# 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
UUID=e3081b9b-52b7-4a7b-995b-925ecff83e85 /boot ext4 defaul
ts 1 2
/dev/mapper/vg_docbillthink-home /home ext4 defaults
/dev/mapper/vg_docbillthink-swap swap swap defaults
/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
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 email@example.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 firstname.lastname@example.org on 2012-06-06 17:54:10 EDT ---
Created attachment 590026 [details]
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.
--- Additional comment from email@example.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.
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:
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.