Bug 565393

Created attachment 394265 [details]
Attached traceback automatically from anaconda.

Bug occurs just after window where I chose basic storage. This is a dual boot dell d620 with the following partition layout:
1) 49 MB FAT
2) 28 GB NTFS
3) 27 GB NTFS
4) 24 GB Extended
    5) 313 MB Ext4 (/boot) boot flag
    6) 7.3 GB Ext4 (/home)
    7) 1.0 GB Swap
    8) 16 GB Ext4 (/)

shmuel,

Thanks for the report. Can you please start the installer in this system again, and then when at the graphical welcome screen, switch to tty2 (ctrl + alt + f2) and do:
cat /proc/partitions
parted /dev/sda unit s print

And then collect the output and enter it in bugzilla ? (note you can use for example scp to copy files from under the installer to somewhere else).

Thanks,

Hans

p.s.

Note to self / other anaconda team members:
This happens during the initial device tree populate when adding the extended
partition to the devicetree:
1) PartitionDevice.__init__ gets called
2) Since this is an existing partition PartitionDevice.probe gets called
3) probe() sets self._size to self.partedPartition.getSize()
4) probe() sets self.targetSize to self.partedPartition.getSize()
5) _setTargetSize() compares newSize with self.currentSize, and finds
   they are not the same! And from there on things start falling apart,
   as _setTargetSize() aligns the end sector of the extended partition down,
   and then the setgeom to update the geom fails, most likely because
   the last logical partition now no longer fits inside the new extended
   partition.

Note that self.currentSize will not return self._size, as self.exists is true
and there is a self.partedDevice, so it will use self.partedDevice.getSize()

IOW it seems that on this system for /dev/sda4
self.partedDevice.getSize() != self.partedPartition.getSize()

Model: ATA FUJITSU MHV2080B (scsi)
Disk /dev/sda: 156301488s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start       End         Size       Type      File system     Flags
 1      63s         96389s      96327s     primary   fat16
 2      96390s      55392119s   55295730s  primary   ntfs
 3      55392120s   108647594s  53255475s  primary   ntfs
 4      108647595s  156296384s  47648790s  extended
 5      108647658s  109258064s  610407s    logical   ext4            boot
 6      109258128s  123604109s  14345982s  logical   ext4
 7      123604173s  125644364s  2040192s   logical   linux-swap(v1)
 8      125644428s  156296384s  30651957s  logical   ext4

major minor  #blocks  name

   7        0     131340 loop0
   8        0   78150744 sda
   8        1      48163 sda1
   8        2   27647865 sda2
   8        3   26627737 sda3
   8        4          1 sda4
   8        5     305203 sda5
   8        6    7172991 sda6
   8        7    1020096 sda7
   8        8   15325978 sda8

BTW, the same commands from f12 finds the same partitioning information for sda

Adding to F13Final blocker bug as this meets the Final blocker criteria [1] points:

 * The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above
 * The installer must be able to install alongside into free space alongside an existing clean single-partition Windows installation and either install a bootloader which can boot into the Windows installation, or leave the Windows bootloader untouched and working 

[1] https://fedoraproject.org/wiki/Fedora_13_Final_Release_Criteria

*** Bug 565500 has been marked as a duplicate of this bug. ***

I've managed to reproduce this on a system partitioned for multiple operating systems.  

# parted /dev/sda -s p
Model: ATA HTS541060G9AT00 (scsi)
Disk /dev/sda: 60.0GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type      File system  Flags
 1      32.3kB  10.7GB  10.7GB  primary   ntfs
 3      10.7GB  10.8GB  107MB   primary   ext4         boot
 4      10.8GB  55.8GB  44.9GB  extended
 5      10.8GB  55.6GB  44.7GB  logical                lvm
 6      55.6GB  55.7GB  107MB   logical   ext4
 7      55.7GB  55.8GB  107MB   logical   ext3
 2      55.8GB  60.0GB  4242MB  primary   fat32        lba

For what it is worth, the original partitioning on this system was made by anaconda of FC6. All later partition manipulations were handled by gparted.

Here is a patch fixing this, see the changelog entry inside the patch for
what exactly was going on causing this problem:

https://www.redhat.com/archives/anaconda-devel-list/2010-February/msg00214.html

Created attachment 394554 [details]
Screenshot (anaconda-13.26 + patch)

Thanks Hans.  I tested the patch in my consistent reproducer (live image install using anaconda-13.26 + your patch).  The reported problem no longer occurs.

I don't know if it's related, by my previous logical group and volumes don't appear to be recognized at the custom partition screen.

Thanks for testing, and no I don't think your VG and LV's not showing is related.

The patch is in master now:
http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=ad5b2571c63f0c66219146e4740d5f200b048bb2

And thus will end up in anaconda-13.27-1, closing.

Created attachment 395814 [details]
Attached traceback automatically from anaconda.