Bug 708810 - anaconda does not find existing partitions (luks-encrypted root)
Summary: anaconda does not find existing partitions (luks-encrypted root)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 15
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-05-29 17:42 UTC by Peter Brommer
Modified: 2012-08-07 19:45 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-07 19:45:32 UTC
Type: ---


Attachments (Terms of Use)
anaconda log (4.97 KB, text/plain)
2011-05-29 17:42 UTC, Peter Brommer
no flags Details
The preupgrade kickstart file (?) (293 bytes, text/plain)
2011-05-29 17:43 UTC, Peter Brommer
no flags Details
The storage log (54.87 KB, text/plain)
2011-05-29 17:44 UTC, Peter Brommer
no flags Details
The program log (1.87 KB, text/plain)
2011-05-29 17:46 UTC, Peter Brommer
no flags Details

Description Peter Brommer 2011-05-29 17:42:12 UTC
Created attachment 501631 [details]
anaconda log

Description of problem: The anaconda installer does not find any partitions on the hard disk. That's why both upgrade after preupgrade F14->F15 and upgrade from Fedora 15 DVD fail. In this bug report I describe the situation after preupgrade, but can provide the information from a DVD upgrade if needed.


Steps to Reproduce:
1. preupgrade F14 -> F15
2. reboot into preupgrade
2a. installer does not prompt for luks passphrase.
3. Installer can not find partitons, displays window "The storage device below may contain data..."
  
Actual results:
Preupgrade fails, installer exits, system reboots to F14.

Expected results:
Anaconda recognises partitions, prompts for luks passphrase, finds root, installs upgrades.

Additional info:

On the shell when anaconda runs, I can activate the encrypted partitions by running
cryptsetup luksOpen /dev/sda6 crypthd
pvscan then finds the physical volumes
vgscan finds the logical volumes
vgchange -a y activates the logical volumes.

fdisk output:
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: 0x76692ca8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048    30716279    15357116   1c  Hidden W95 FAT32 (LBA)
/dev/sda2        30716280   274904279   122094000    7  HPFS/NTFS
/dev/sda3   *   274904343   275434424      265041   83  Linux
/dev/sda4       275434425   976784129   350674852+   f  W95 Ext'd (LBA)
/dev/sda5       275438872   589888790   157224959+   c  W95 FAT32 (LBA)
/dev/sda6       589888792   976766230   193438719+  83  Linux

sda6 is a luks-encrypted file system, containing a volume group with 3 logical volumes:lvscan
  ACTIVE            '/dev/vg_peekaboo/lv_home' [97.66 GiB] inherit
  ACTIVE            '/dev/vg_peekaboo/lv_root' [48.83 GiB] inherit
  ACTIVE            '/dev/vg_peekaboo/lv_swap' [5.84 GiB] inherit

This is the /etc/fstab of the running F14
# /etc/fstab
# Created by anaconda on Mon Feb  8 23:41:36 2010
#
# 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_peekaboo-lv_root /                       ext4    defaults        1 1
UUID=c65bc767-60f4-4fb6-8be4-8170e64ab1aa /boot                   ext4    defaults        1 2
/dev/mapper/vg_peekaboo-lv_home /home                   ext4    defaults        1 2
/dev/mapper/vg_peekaboo-lv_swap swap                    swap    defaults        0 0
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

attached are the relevant logs from anaconda. If you need anything more, let me know.

Comment 1 Peter Brommer 2011-05-29 17:43:28 UTC
Created attachment 501632 [details]
The preupgrade kickstart file (?)

Comment 2 Peter Brommer 2011-05-29 17:44:11 UTC
Created attachment 501633 [details]
The storage log

Comment 3 Peter Brommer 2011-05-29 17:46:00 UTC
Created attachment 501634 [details]
The program log

Comment 4 Peter Brommer 2011-05-30 11:40:24 UTC
Hi,

I found the problem: The hard disk partition table was corrupted

Disk /dev/sda: [..] total ***976773168*** sectors
[..]
/dev/sda4       275434425 **976784129** 350674852+   f  W95 Ext'd (LBA)
/dev/sda5       275438872   589888790   157224959+   c  W95 FAT32 (LBA)
/dev/sda6       589888792   976766230   193438719+  83  Linux

Somehow my extended partition got allocated beyond the last sector of the HD, which caused parted to hiccup. Note that the logical partition does not extend beyond the last cylinder. I fixed that, parted could then read the partition table again, and the next time I booted into the installer, everything went smoothly.

So my problem is resolved, but I don't know if you want anaconda or parted to communicate its problems more clearly.

Comment 5 tz 2011-07-18 03:54:40 UTC
Someone should reopen it as "Non-critical partition errors prevent upgrades (to encrypted partitions)".  The same thing just happened to me.

Instead of saying it can't find any partitions, it should indicate that there is something invalid in the partition table that needs to be fixed (I imaged the disk to a slightly smaller one so an unused partition was out of bounds).  It took me three times to find it.  It should specifically say that the partition table has some kind of problem.

Comment 6 Fedora End Of Life 2012-08-07 19:45:34 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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" (top right of this page) 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


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