Description of problem: 1. Selected a single disk with 2 partitions. 2. Selected custom partitioning. 3. Selected Automatically partition disk. 4. Noted the error message that the disk was too full for automatic partitioning. 5. Clicked on the root partition (btrfs), clicked on the minus button to remove. 6. Clicked on the boot partitiong (ext4), clicked on the minus button to remove. CRASH. Version-Release number of selected component: anaconda-18.14 Additional info: libreport version: 2.0.14 cmdline: /usr/bin/python /sbin/anaconda kernel: 3.6.1-1.fc18.x86_64 description: :The following was filed automatically by anaconda: :anaconda 18.14 exception report :Traceback (most recent call first): : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/partitioning.py", line 1638, in manageSizeSets : request = requests_by_device[device] : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/partitioning.py", line 1757, in growPartitions : manageSizeSets(size_sets, chunks) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/partitioning.py", line 762, in doPartitioning : growPartitions(disks, partitions, free, size_sets=storage.size_sets) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/partitioning.py", line 302, in doAutoPartition : doPartitioning(storage) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1696, in _do_autopart : doAutoPartition(self.__storage, self.data) : File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1728, in on_create_clicked : self._do_autopart() :KeyError: PartitionDevice instance (0x7f0f28b016d0) -- : name = sda1 status = False kids = 0 id = 24 : parents = ['existing 819200MB disk sda (1) with existing msdos disklabel'] : uuid = None size = 814667.0 : format = non-existent btrfs filesystem : major = 0 minor = 0 exists = False protected = False : sysfs path = partedDevice = None : target size = 1 path = /dev/sda1 : format args = [] originalFormat = btrfs grow = False max size = 814667.0 bootable = False : part type = 0 primary = False : partedPartition = parted.Partition instance -- : disk: <parted.disk.Disk object at 0x7f0f28b6d290> fileSystem: None : number: 1 path: /dev/sda1 type: 0 : name: None active: True busy: False : geometry: <parted.geometry.Geometry object at 0x7f0f28aa9a10> PedPartition: <_ped.Partition object at 0x7f0f28a80350> : disk = existing 819200MB disk sda (1) with existing msdos disklabel : start = 2048 end = 1668440063 length = 1668438016 : flags =
Created attachment 624578 [details] File: anaconda-tb
Created attachment 624579 [details] File: product
Created attachment 624580 [details] File: type
Created attachment 624581 [details] File: ifcfg.log
Created attachment 624582 [details] File: storage.log
Created attachment 624583 [details] File: version
Created attachment 624584 [details] File: environ
Created attachment 624585 [details] File: anaconda.log
Created attachment 624586 [details] File: syslog
Created attachment 624587 [details] File: hashmarkername
Created attachment 624588 [details] File: packaging.log
Created attachment 624589 [details] File: cmdline_file
Created attachment 624590 [details] File: release
Created attachment 624591 [details] File: program.log
Bug 864765 appears to result in a corrupt ext4 /boot partition. I can still mount /dev/sda2 (btrfs), but get a wrong/unrecognized file system error when trying to mount /dev/sda1 (should be ext4). Propose as beta blocker "10. Installer's custom partitioning mode must be capable of destroying; Rejecting obviously invalid operations without crashing." Counter argument: file system is invalid, perhaps it can't be destroyed as a result, but installer probably still shouldn't crash.
Selected four VM disks and tried to create /, /home, /boot as btrfs devices. Each mount point contunually disappeared from the left side when the next mount point was created. Gave up, went back to spokes and asked for auto paritioning, but was informed that space needed to be reclaimed. Ok, do so, then the failure. Package: anaconda-18.14 OS Release: Fedora release 18-Beta-TC3
trying to create btrfs paritions for /, /home and /boot by asking for auto paritioning and then modifing each to btrfs. Saw an Unknown section in the left hand paritioning screen which contained another swap parition. Deleted it and then the sizes of the modified parititions jumped to what looked like the size of the virtual device. Deleted all of them to start over, asked for auto paritioning again and then this error occurred. I think I am pressing the installer too much at this stage and need to wait for further development. All of the testing is being done in a F17 VM. Will not touch bare iron until further along. Package: anaconda-18.14 OS Release: Fedora release 18-Beta-TC3
Discussed at 2012-10-10 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-10/f18beta-blocker-review-3.2012-10-10-16.05.log.txt . Accepted as a blocker on the basis of the total impact of: The installer's custom partitioning mode must be capable of the following: Creating, destroying and assigning mount points to partitions of any specified size using most commonly-used filesystem types Creating encrypted partitions Rejecting obviously invalid operations without crashing If you argue that the fact the filesystem is corrupt is the problem and anaconda shouldn't have to be able to delete it, then you hit "Rejecting obviously invalid operations without crashing". Either it should cope with deleting this badly-formatted partition or it should refuse to do so gracefully.
(In reply to comment #16) (In reply to comment #17) I think these are out of scope for this bug: this bug is about a single disk system with a (likely) corrupt ext4 /boot partition, with no attempt to make /boot btrfs; and no additional log files have been attached to see how the two incidence are related.
Attempting to reproduce revealed the following: 1. /dev/sda1 is not a corrupt ext4 volume, sda1 is all zeros, as shown with hexdump -C. 2. /dev/sda2 is btrfs, latent raid1 member from bug 864765, dmesg dmesg reports "failed to read the system array on sda2; open_ctree failed" 3. However this bug is reproducible even after using 'mkfs.btrfs /dev/sda2' and dmesg reported no mount errors. 4. It takes multiple clicks in the GUI to stimulate the bug, more so than previously indicated. ===== New detail step by step for reproducing: 1. Starting with disk1 (was /dev/sda) from this Bug 864765; single VDI only, not a fresh VDI but from a previously failed install. Naughty but that's what I did. 2. Boot from Fedora-18-Beta-TC3-x86_64-netinst.iso 3. Choose Installation Destination > choose the single disk > choose custom partitioning 4. Click on "Click here to create them automatically" > Noted for automatic partition failure, and cause lack of free space. 5. Click on +UNKNOWN, two options: btrfs 77.38GB and Unknown 500MB > clicked on Unknown 500MB > Clicked minus (-) button to delete it > Agreed to confirmation "Delete It" 6. Click on btrfs 77.38 > clicked minus (-) button to delete > Agree to confirmation "Are you sure you want to delete all of the data on 00?" Delete It. 7. Click on Click here to create them automatically CRASH Reproduced this 4 times in a row with this sequence. Attaching new/additional logs with the same clean (zero) sda1 pre-existing partition, and a freshly formated btrfs (no longer latent raid1 from prior bug) pre-existing partition.
Created attachment 625339 [details] comment 20 new logs Change from original logs, reformat latent btrfs raid1 with 'mkfs.btrfs /dev/sda2'. Crash details appear the same.
anaconda-18.17-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.17-1.fc18
Package anaconda-18.17-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.17-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16295/anaconda-18.17-1.fc18 then log in and leave karma (feedback).
anaconda-18.18-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.18-1.fc18
Bug 864765 fixed, can no longer reproduce this bug with a (known clean) btrfs volume.
Package anaconda-18.18-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-18.18-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-16402/anaconda-18.18-1.fc18 then log in and leave karma (feedback).
anaconda-18.19-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.19-1.fc18
Anaconda is stable. Chris says he no longer sees this bug. Closing. Please reopen if you hit it again, thanks.