Red Hat Bugzilla – Bug 1008060
conflicting partition size information
Last modified: 2013-09-23 15:39:05 EDT
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.
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:
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
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1399, in _save_right_side
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2363, in _save_current_selector
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 2374, in on_selector_clicked
File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/lib/accordion.py", line 218, in _onSelectorClicked
ValueError: invalid target size request
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
other involved packages: python-blivet-0.17-1.fc19.noarch
release: Fedora release 19 (Schrödinger’s Cat)
Created attachment 797557 [details]
Created attachment 797558 [details]
Created attachment 797559 [details]
Created attachment 797560 [details]
Created attachment 797561 [details]
Created attachment 797562 [details]
Created attachment 797563 [details]
Created attachment 797564 [details]
Created attachment 797565 [details]
Created attachment 797566 [details]
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.
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.
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.
I don't know if there's much to be done here since the offending layout has been destroyed.
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
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.