Bug 1306462 - _ped.PartitionException: Unable to satisfy all constraints on the partition.
_ped.PartitionException: Unable to satisfy all constraints on the partition.
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
24
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
RejectedBlocker abrt_hash:08466c6ac6a...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-10 17:32 EST by Chris Murphy
Modified: 2017-08-08 08:45 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 08:45:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: anaconda-tb (1.02 MB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: anaconda.log (89.81 KB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: environ (494 bytes, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: journalctl (369.45 KB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: lsblk_output (6.14 KB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: nmcli_dev_list (2.22 KB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: os_info (528 bytes, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: program.log (75.81 KB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: storage.log (446.99 KB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
File: ifcfg.log (4.23 KB, text/plain)
2016-02-10 17:32 EST, Chris Murphy
no flags Details
screenshot free space (153.26 KB, image/png)
2016-02-15 16:13 EST, Chris Murphy
no flags Details

  None (edit)
Description Chris Murphy 2016-02-10 17:32:00 EST
Description of problem:
Crashes after accepting reclaim space, but before begin installation.

Version-Release number of selected component:
anaconda-core-24.11-1.fc24.x86_64

The following was filed automatically by anaconda:
anaconda 24.11-1 exception report
Traceback (most recent call first):
  File "/usr/lib64/python3.5/site-packages/parted/disk.py", line 245, in addPartition
    constraint.getPedConstraint())
  File "/usr/lib64/python3.5/site-packages/parted/decorators.py", line 42, in new
    ret = fn(*args, **kwds)
  File "/usr/lib/python3.5/site-packages/blivet/partitioning.py", line 439, in addPartition
    constraint=constraint)
  File "/usr/lib/python3.5/site-packages/blivet/partitioning.py", line 927, in allocatePartitions
    _part.req_start_sector, _part.req_end_sector)
  File "/usr/lib/python3.5/site-packages/blivet/partitioning.py", line 572, in doPartitioning
    allocatePartitions(storage, disks, partitions, free)
  File "/usr/lib/python3.5/site-packages/blivet/autopart.py", line 501, in doAutoPartition
    doPartitioning(storage)
  File "/usr/lib64/python3.5/site-packages/pyanaconda/kickstart.py", line 341, in execute
    doAutoPartition(storage, ksdata, min_luks_entropy=MIN_CREATE_ENTROPY)
  File "/usr/lib64/python3.5/site-packages/pyanaconda/kickstart.py", line 2201, in doKickstartStorage
    ksdata.autopart.execute(storage, ksdata, instClass)
  File "/usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/spokes/storage.py", line 353, in _doExecute
    doKickstartStorage(self.storage, self.data, self.instclass)
  File "/usr/lib64/python3.5/threading.py", line 862, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib64/python3.5/site-packages/pyanaconda/threads.py", line 253, in run
    threading.Thread.run(self, *args, **kwargs)
_ped.PartitionException: Unable to satisfy all constraints on the partition.

Additional info:
cmdline:        /usr/bin/python3  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base
cmdline_file:   BOOT_IMAGE=vmlinuz0 initrd=initrd0.img root=live:CDLABEL=Fedora-Live-WS-x86_64-rawhide-20 rootfstype=auto ro rd.live.image quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0 
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         4.5.0-0.rc2.git3.1.fc24.x86_64
other involved packages: python3-blivet-1.18-1.fc24.noarch, anaconda-gui-24.11-1.fc24.x86_64, python3-pyparted-3.10.7-2.fc24.x86_64, python3-libs-3.5.1-3.fc24.x86_64
product:        Fedora
release:        Fedora release 24 (Rawhide)
type:           anaconda
version:        rawhide

Potential duplicate: bug 1267923
Comment 1 Chris Murphy 2016-02-10 17:32:06 EST
Created attachment 1122972 [details]
File: anaconda-tb
Comment 2 Chris Murphy 2016-02-10 17:32:08 EST
Created attachment 1122973 [details]
File: anaconda.log
Comment 3 Chris Murphy 2016-02-10 17:32:08 EST
Created attachment 1122974 [details]
File: environ
Comment 4 Chris Murphy 2016-02-10 17:32:10 EST
Created attachment 1122975 [details]
File: journalctl
Comment 5 Chris Murphy 2016-02-10 17:32:11 EST
Created attachment 1122976 [details]
File: lsblk_output
Comment 6 Chris Murphy 2016-02-10 17:32:12 EST
Created attachment 1122977 [details]
File: nmcli_dev_list
Comment 7 Chris Murphy 2016-02-10 17:32:13 EST
Created attachment 1122978 [details]
File: os_info
Comment 8 Chris Murphy 2016-02-10 17:32:14 EST
Created attachment 1122979 [details]
File: program.log
Comment 9 Chris Murphy 2016-02-10 17:32:16 EST
Created attachment 1122980 [details]
File: storage.log
Comment 10 Chris Murphy 2016-02-10 17:32:17 EST
Created attachment 1122981 [details]
File: ifcfg.log
Comment 11 Fedora Blocker Bugs Application 2016-02-15 02:53:35 EST
Proposed as a Blocker for 24-beta by Fedora user chrismurphy using the blocker tracking app because:

 "When using the guided partitioning flow, the installer must be able to:
Cleanly install to a disk with a valid ms-dos or gpt disk label and partition table which contains existing data and sufficient unpartitioned space for a Fedora installation; OR
Reject or disallow invalid disk and volume configurations without crashing."

Chromium OS restore image dd'd to a disk, and then the disk is handed over to Anaconda's guided partitioning. About 80% of the disk is free space. At least it shouldn't crash, but probably shouldn't by default try to set this system up as dual-boot Chromium + Fedora either, since that's unsupported.
Comment 12 Adam Williamson 2016-02-15 12:28:12 EST
You say it crashes "after accepting reclaim space". The first criterion bit you cite does not apply to "reclaim space" operations - it applies to the scenario where there is literally empty unpartitioned space on the disk (and thus no "reclamation" is necessary).

This might still be a blocker per the second criterion bit you mention, but can we please have a bit more detail about exactly what you did in the installer?
Comment 13 Chris Murphy 2016-02-15 14:28:07 EST
"after accepting reclaim space" in the original description should have been "after entering Destination Installation and clicking Done". Nothing was changed that spoke, Device Selection and Other Storage Options were left at their defaults.

This chromium OS image uses GPT partitioning. dd cannot put the backup gpt at the end of the actual physical disk used where it should be. But the primary GPT probably references the backup gpt with the correct LBA, if it didn't, we'd have a complaint from parted in the logs. I'm going to guess, but I think parted, gdisk, and fdisk, will not report any free space because in between the primary and backup GPTs, there won't be any. All of it is on the other wise of the backup GPT. Only if the backup GPT were relocated to the end of the disk, and the primary GPT pointer to the backup GPT is rewritten, would those tools then "see" the free space. So what might be going on is there are two different "free space" logics that are in conflict, confusion results, and then crash. Just a guess.
Comment 14 Chris Murphy 2016-02-15 16:12:52 EST
# dd if=chromiumos.bin of=/dev/sda
# parted /dev/sda
/* no complaints

# parted -l
Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 157048830 blocks) or continue with the current setting?

# gdisk /dev/sda


gdisk points out there is a hybrid MBR in place; and reports "Total free space is 167852 sectors (82.0 MiB)" despite (see screenshot, Anaconda reporting 74.97 GiB free in two locations); and also its verify option finds 1 problem:

"Problem: The secondary header's self-pointer indicates that it doesn't reside at the end of the disk. If you've added a disk to a RAID array, use the 'e' option on the experts' menu to adjust the secondary header's and partition table's locations." 

I'd say this bug is strictly a "installer should not crash" case; and it's a separate bug/rfe to ID chromium OS disks, and a policy whether to preserve all, delete all, or support dual boot. The one thing in common for imaged and installed chromium OS disks is there's a pile of chromium os only partition type GUIDS, many of which contain only binary blobs, not file systems.
Comment 15 Chris Murphy 2016-02-15 16:13 EST
Created attachment 1127453 [details]
screenshot free space
Comment 16 Chris Murphy 2016-02-15 16:22:39 EST
This bug is obscure, and the target disk isn't modified. It fits the description of a conditional blocker.
Comment 17 Petr Schindler 2016-02-22 14:23:43 EST
Discussed at 2016-02-22 blocker review meeting: [1]. 

This bug was rejected as Beta blocker: this is a somewhat complex case and hard to reduce to a summary, but at a very high level, we don't see any way in which making this bug a blocker would produce a significantly improved outcome.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2016-02-22/f24-blocker-review.2016-02-22-17.00.html
Comment 18 Adam Williamson 2016-02-22 15:12:32 EST
To elaborate on the above a bit: if we're considering the Chromium case specifically, it seems like the best thing anaconda could do here is not crash on this particular disk layout and manage to install to the free space. But that is actually *not* a desirable outcome, as Chris pointed out, because it would likely render the Chromium install more or less unbootable. So this bug is ironically acting as a sort of safety mechanism. If we were to accept it as a blocker, we would run the risk of winding up in the situation where we fix the crasher but don't fix the issue of parallel install with Chromium, which if anything, makes things practically *worse*.

We can't accept the bug "Fedora can't install alongside Chromium" as a blocker, because that's not in the requirements.

We can consider the more-or-less generic case, which if I'm understanding right, is this disk layout:

<PRIMARY GPT>-<PARTITIONS>-<BACKUP GPT>-<UNPARTITIONED SPACE>

which was in this case produced, I believe, by imaging a GPT-labelled disk and restoring it to a *larger* disk (thus the unpartitioned space following the GPT), and we could argue that a crash on attempting to do a guided install to this layout is a release blocker, but I believe our consensus was it's too much of a corner case to constitute a blocker. This could be re-considered if there's a more likely way to end up in such a scenario (and one where we would actually achieve something good by installing to the unpartitioned space).
Comment 19 Jan Kurik 2016-02-24 09:29:10 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 20 Fedora End Of Life 2017-07-25 15:55:21 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. 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 EOL if it remains open with a Fedora  'version'
of '24'.

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.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 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  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

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.
Comment 21 Fedora End Of Life 2017-08-08 08:45:57 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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