Description of problem: the guest has two disks, i selected the first one with xp an a previos /boot. i went to manual partitioning setting the type to btrfs· i delete the /boot i created a /boot of 100mb (since on a previous test on another guest i saw that all brtfs subvolumes have the same size, i speculated that 100mb was the same to 512mb). at that point, the free space went to 0 i create a 4 gb / but anaconda crashed. The following was filed automatically by anaconda: anaconda 18.37.8 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 4006, in path return self.parents[0].path File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 905, in _setFormat format = getFormat(None, device=self.path, exists=self.exists) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 4041, in _setFormat super(BTRFSVolumeDevice, self)._setFormat(format) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 919, in <lambda> lambda d,f: d._setFormat(f), File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 489, in __init__ self.format = format File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 3945, in __init__ super(BTRFSDevice, self).__init__(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 4016, in __init__ super(BTRFSVolumeDevice, self).__init__(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1169, in newBTRFS device = dev_class(name, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 3426, in new_container return getattr(self.storage, self.new_container_attr)(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2201, in newDevice container = factory.new_container(parents=parents, **kwa) File "/usr/lib64/python2.7/site-packages/pyanaconda/ui/gui/spokes/custom.py", line 1824, in on_add_clicked disks=disks) IndexError: list index out of range Additional info: cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2018-TC4\x20x86_64 quiet BOOT_IMAGE=vmlinuz executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.6.10-4.fc18.x86_64 other involved packages: package: anaconda-18.37.8 product: Fedora release: Cannot get release name. type: libreport version: 18-TC4
Created attachment 672617 [details] File: anaconda-tb
Created attachment 672618 [details] File: anaconda.log
Created attachment 672619 [details] File: environ
Created attachment 672620 [details] File: ifcfg.log
Created attachment 672621 [details] File: packaging.log
Created attachment 672622 [details] File: program.log
Created attachment 672623 [details] File: storage.log
Created attachment 672624 [details] File: syslog
i created a 1mb / filesystem (in manual partitioning with type btrfs) previously, i tried to use (no reformat previous /home) a previous f18 (done with automatic partitioning) i reformat /boot, swap i added /home (no reformat) but i could not touch /, not even reformat it (All grayed out) so i deleted it and noticed it was a subvol, so the only thing to try was to create it within the 900kb space left and then set it to btrfs so it will become a subvol and bypass the size issue but it crashed. Package: anaconda-18.37.8 OS Release: Fedora release 18-TC4
Created Root subvolume. Crash. Package: anaconda-18.37.10 OS Release: Fedora release 18
Proposing as blocker, F18 beta release criterion #10 "installer's custom partitioning mode must be capable of creating and assigning mount points ... and rejecting obviously invalid operations without crashing." Unable to reproduce this with 18.37.8; seems new with. .9 or .10. Seems to be hit or miss on reproducibility.
Created attachment 673022 [details] anaconda-tb-
OK so far I can 100% reproduce this in 18.37.10 but can't in 18.37.8, so it's a regression, but I'm not sure it's the same bug even though libreport says it is, because I don't have XP and I can reproduce even without trying to delete /boot. So I'm going to file a new bug. But still seems like Reartes original submission is a blocker.
I believe this crash happens when you try to create a very small btrfs volume. One case of this is the bug cmurf filed separately - https://bugzilla.redhat.com/show_bug.cgi?id=892196 - but I cannot understand why Reartes is doing stuff like "i created a 1mb / filesystem (in manual partitioning with type btrfs)". Why are you doing that?
If I try and create a 1MB '/' mount point, type btrfs, on an emptied disk in RC1, it gets automatically sized up to 256MB and there is no crash.
@Adam Williamson > [...] Why are you doing that? >If I try and create a 1MB '/' mount point, type btrfs, on an emptied >disk in RC1, it gets automatically sized up to 256MB and there is no crash. I was trying workarounds, but that certainly was a bad one. My bad. I should not have forgotten minimal size limit for btrfs. Comment #9 is related to Bug 892188
OK I have a new set of steps to reproduce. 1. Existing single disk Btrfs volume. With or without existing subvols. No free space on the disk. 2. Installation Destination > Installation Options > Partition Scheme Configuration must be changed from LVM to BTRFS, and "let me customize" checked. Click on Reclaim space. 3. Manual Partitioning > Click on +. Enter any mount point, such as /, and also enter a capacity value. Doesn't matter what capacity value, I used /home and 5000MB. Crash. If I do not enter a capacity value, I don't get a crash. Capacities for BTRFS subvols don't make sense (quotas do but that's a different conversation), so that field ought to be grayed out, technically. But at least don't crash. A separate UI question, to punt on for today, is whether and if so how to specify creation of a new Btrfs volume, vs creating a subvol in an existing volume, and how to choose which volume to create the subvol in if there's more than one.
(In reply to comment #17) > If I do not enter a capacity value, I don't get a crash. Capacities for > BTRFS subvols don't make sense (quotas do but that's a different > conversation), so that field ought to be grayed out, technically. But at > least don't crash. Crash is not a good sign of healthy installation, but it could be documented not to put any capacity value, so -1 blocker, maybe NTH to grey out (if I understand the description correctly). But again - could be documented for btrfs and it means no touching Anaconda code for it now, so I'm weak -1 NTH.
Try: updates=http://dlehman.fedorapeople.org/updates/updates-892196.0.img
Discussed at 2013-01-07 QA meeting acting as a blocker review meeting: http://meetbot.fedoraproject.org/fedora-meeting/2013-01-07/fedora-qa.2013-01-07-16.01.log.txt . As discussed at the meeting, we felt this crash specifically should only happen when the user does something stupid, or the installer forces something stupid to happen (see 892188), so it's rejected as a blocker but accepted as NTH. In practice the bug may be effectively identical to 892196, according to dlehman - it may only be possible to hit this traceback under the conditions described in 892196. Either way, the upshot is that the problem is RejectedBlocker / AcceptedNTH.
Patch fixes this bug. More info in https://bugzilla.redhat.com/show_bug.cgi?id=892196#c21
The 892196 updates.img definitely fixes 892196. Whether we consider it to fix this bug or not, I guess, depends on whether it'd be somehow possible to hit this codepath and hence this crash outside of the circumstances described in 892196 (and hence hit it even after that patch is applied). David, if you're confident the patch prevents anyone hitting this path, then by all means, we can consider that fix as fixing this bug too.
anaconda-18.37.11-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/anaconda-18.37.11-1.fc18
Fixed in anaconda-18.37.11-1.fc18.
anaconda-18.37.11-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.