Bug 1008060

Summary: conflicting partition size information
Product: [Fedora] Fedora Reporter: wills4000
Component: partedAssignee: Brian Lane <bcl>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: anaconda-maint-list, bcl, dlehman, dshea, g.kaviyarasu, jonathan, mkolman, sbueno, vanmeeuwen+fedora, vpodzime
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:3fa2164c1c1dcc057b06d94d247bb4f8619e7664d5c42ee64149b7fc48836e8d
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-23 19:39:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: anaconda-tb
none
File: anaconda.log
none
File: environ
none
File: lsblk_output
none
File: messages
none
File: nmcli_dev_list
none
File: os_info
none
File: program.log
none
File: storage.log
none
File: ifcfg.log none

Description wills4000 2013-09-14 07:41:43 UTC
Description of problem:

Steps that seem to happen every time I run through the installer (three times so far)
Run through installer to disk selection. Select all four hard disks.
Open custom partition editor
Selected other partitions from the list on the left.
Clicked on second entry ( /dev/sda2 ) or try and remove all the partitions in the section.
Error thrown.

In case this is relevent:
I have four hard disks. 
/dev/sda contains an old windows partition which is toast
/dev/sdb software raided in windows with /dev/sdd (part of an old experement)
/dev/sdc an existing set of kubuntu partitions
/dev/sdd software raided with the /dev/sdb

I am trying to errase the entire lot and start from a completely clean system.

Version-Release number of selected component:
anaconda-19.30.13-1.fc19.x86_64

The following was filed automatically by anaconda:
anaconda 19.30.13-1 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/blivet/formats/fs.py", line 207, in _setTargetSize
    raise ValueError("invalid target size request")
  File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 589, in __init__
    self.device.format.targetSize = newsize
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1211, in resizeDevice
    self.devicetree.registerAction(action_class(device, new_size))
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1399, in _save_right_side
    self.__storage.resizeDevice(device, size)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2363, in _save_current_selector
    self._save_right_side(self._current_selector)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2374, in on_selector_clicked
    self._save_current_selector()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/accordion.py", line 218, in _onSelectorClicked
    cb(selector)
ValueError: invalid target size request

Additional info:
cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   initrd=initrd0.img root=live:CDLABEL=Fedora-Live-Desktop-x86_64-19-1 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 rd.live.check BOOT_IMAGE=vmlinuz0 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.9.5-301.fc19.x86_64
other involved packages: python-blivet-0.17-1.fc19.noarch
product:        Fedora
release:        Fedora release 19 (Schrödinger’s Cat)
type:           anaconda
version:        19

Comment 1 wills4000 2013-09-14 07:41:55 UTC
Created attachment 797557 [details]
File: anaconda-tb

Comment 2 wills4000 2013-09-14 07:41:59 UTC
Created attachment 797558 [details]
File: anaconda.log

Comment 3 wills4000 2013-09-14 07:42:03 UTC
Created attachment 797559 [details]
File: environ

Comment 4 wills4000 2013-09-14 07:42:07 UTC
Created attachment 797560 [details]
File: lsblk_output

Comment 5 wills4000 2013-09-14 07:42:13 UTC
Created attachment 797561 [details]
File: messages

Comment 6 wills4000 2013-09-14 07:42:17 UTC
Created attachment 797562 [details]
File: nmcli_dev_list

Comment 7 wills4000 2013-09-14 07:42:21 UTC
Created attachment 797563 [details]
File: os_info

Comment 8 wills4000 2013-09-14 07:42:25 UTC
Created attachment 797564 [details]
File: program.log

Comment 9 wills4000 2013-09-14 07:42:31 UTC
Created attachment 797565 [details]
File: storage.log

Comment 10 wills4000 2013-09-14 07:42:35 UTC
Created attachment 797566 [details]
File: ifcfg.log

Comment 11 wills4000 2013-09-14 08:01:55 UTC
The back trace here looks like the one in Bug 986575.

I've managed to work around this problem by using the disk tool included on the live CD to remove all the partitions then start the installer again.

Given existing bug and work around, please feel free to close this.

Comment 12 Vratislav Podzimek 2013-09-23 14:06:32 UTC
This seems to be a blivet issue, however (from the anaconda-tb file):

existing 0MB partition sda1 (2) with existing ntfs filesystem

03:29:50,891 INFO program: Running... ntfsresize -m /dev/sda2
....
03:29:59,216 INFO program: Filesystem check failed! Totally 256 cluster accounting mismatches.
03:29:59,217 INFO program: ERROR: NTFS is inconsistent. Run chkdsk /f on Windows then reboot it TWICE!
03:29:59,217 INFO program: The usage of the /f parameter is very IMPORTANT! No modification was
03:29:59,217 INFO program: and will be made to NTFS by this software until it gets repaired.

This all seems really weird.

Comment 13 David Lehman 2013-09-23 14:57:04 UTC
This is indeed very strange. Below you can see that parted is returning 

03:29:43,297 INFO blivet: got device: PartitionDevice instance (0x25acf50) --
  name = sda1  status = True  kids = 0 id = 2
  parents = ['existing 152626MB disk sda (1) with existing msdos disklabel']
  uuid = None  size = 0.96923828125
  format = existing ntfs filesystem
  major = 8  minor = 1  exists = True  protected = False
  sysfs path = /devices/pci0000:00/0000:00:1f.2/ata3/host2/target2:0:0/2:0:0:0/block/sda/sda1  partedDevice = parted.Device instance --
  model: Unknown  path: /dev/sda1  type: 0
  sectorSize: 512  physicalSectorSize:  512
  length: 204800  openCount: 0  readOnly: False

^^^ parted.Device: 204800sectors * 512bytes ==> 100MiB

  externalMode: False  dirty: False  bootDirty: False
  host: 25705  did: 13103  busy: False
  hardwareGeometry: (12, 255, 63)  biosGeometry: (12, 255, 63)
  PedDevice: <_ped.Device object at 0x251c830>
  target size = 0  path = /dev/sda1
  format args = []  originalFormat = None  grow = None  max size = 0  bootable = None
  part type = 0  primary = None
  partedPartition = parted.Partition instance --
  disk: <parted.disk.Disk object at 0x25ac650>  fileSystem: <parted.filesystem.FileSystem object at 0x25a1590>
  number: 1  path: /dev/sda1  type: 0
  name: None  active: True  busy: False
  geometry: <parted.geometry.Geometry object at 0x25a1650>  PedPartition: <_ped.Partition object at 0x25ad3b0>
  disk = existing 152626MB disk sda (1) with existing msdos disklabel
  start = 63  end = 2047  length = 1985

^^^ parted.Partition: 1985sectors * 512bytes ==> 0.9692MiB

So parted is giving conflicting data for the same partition (sda1). The ntfs errors are actually for sda2, so that is a separate problem.

Comment 14 David Lehman 2013-09-23 15:21:23 UTC
I don't know if there's much to be done here since the offending layout has been destroyed.

Comment 15 Brian Lane 2013-09-23 19:24:03 UTC
What is this system? I see this in the syslog -

Sep 14 04:21:59 localhost kernel: [    0.954813] ldm_parse_tocblock(): Cannot find TOCBLOCK, database may be corrupt.
Sep 14 04:21:59 localhost kernel: [    0.954888] ldm_parse_tocblock(): Cannot find TOCBLOCK, database may be corrupt.
Sep 14 04:21:59 localhost kernel: [    0.955601] ldm_parse_tocblock(): Cannot find TOCBLOCK, database may be corrupt.
Sep 14 04:21:59 localhost kernel: [    0.955673] ldm_parse_tocblock(): Cannot find TOCBLOCK, database may be corrupt.
Sep 14 04:21:59 localhost kernel: [    0.963981] ldm_parse_tocblock(): Cannot find TOCBLOCK, database may be corrupt.
Sep 14 04:21:59 localhost kernel: [    0.964060] ldm_parse_tocblock(): Cannot find TOCBLOCK, database may be corrupt.
Sep 14 04:21:59 localhost kernel: [    0.975372]  sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 >
Sep 14 04:21:59 localhost kernel: [    0.976669] sd 3:0:0:0: [sdc] Attached SCSI disk
Sep 14 04:21:59 localhost kernel: [    0.999255]  sdd: [LDM] sdd1
Sep 14 04:21:59 localhost kernel: [    0.999787] sd 3:0:1:0: [sdd] Attached SCSI disk
Sep 14 04:21:59 localhost kernel: [    1.004645]  sdb: [LDM] sdb1
Sep 14 04:21:59 localhost kernel: [    1.005664] sd 2:0:1:0: [sdb] Attached SCSI disk
Sep 14 04:21:59 localhost kernel: [    1.104844]  sda: [LDM] sda1 sda2
Sep 14 04:21:59 localhost kernel: [    1.105310] sd 2:0:0:0: [sda] Attached SCSI disk

Comment 16 Brian Lane 2013-09-23 19:39:05 UTC
Ok, I see what a LDM is now -- Windows Logical Disk Manager. parted doesn't understand these, it treats them as msdos partitions. So my guess is either that LDM does something different with the partition sizes or the LDM data is corrupt enough that the kernel returns a different size than reading the partitions directly.