Red Hat Bugzilla – Bug 1306462
_ped.PartitionException: Unable to satisfy all constraints on the partition.
Last modified: 2017-08-08 08:45:57 EDT
Description of problem:
Crashes after accepting reclaim space, but before begin installation.
Version-Release number of selected component:
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
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
File "/usr/lib/python3.5/site-packages/blivet/partitioning.py", line 927, in allocatePartitions
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
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
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.
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
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
release: Fedora release 24 (Rawhide)
Potential duplicate: bug 1267923
Created attachment 1122972 [details]
Created attachment 1122973 [details]
Created attachment 1122974 [details]
Created attachment 1122975 [details]
Created attachment 1122976 [details]
Created attachment 1122977 [details]
Created attachment 1122978 [details]
Created attachment 1122979 [details]
Created attachment 1122980 [details]
Created attachment 1122981 [details]
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.
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?
"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.
# 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.
Created attachment 1127453 [details]
screenshot free space
This bug is obscure, and the target disk isn't modified. It fits the description of a conditional blocker.
Discussed at 2016-02-22 blocker review meeting: .
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.
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).
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:
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'
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.
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
Thank you for reporting this bug and we are sorry it could not be fixed.