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
Created attachment 1122972 [details] File: anaconda-tb
Created attachment 1122973 [details] File: anaconda.log
Created attachment 1122974 [details] File: environ
Created attachment 1122975 [details] File: journalctl
Created attachment 1122976 [details] File: lsblk_output
Created attachment 1122977 [details] File: nmcli_dev_list
Created attachment 1122978 [details] File: os_info
Created attachment 1122979 [details] File: program.log
Created attachment 1122980 [details] File: storage.log
Created attachment 1122981 [details] File: ifcfg.log
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: [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
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: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
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.
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.