Created attachment 803445 [details]
File: anaconda.log

Created attachment 803446 [details]
File: environ

Created attachment 803447 [details]
File: lsblk_output

Created attachment 803448 [details]
File: nmcli_dev_list

Created attachment 803449 [details]
File: os_info

Created attachment 803450 [details]
File: program.log

Created attachment 803451 [details]
File: ifcfg.log

Created attachment 803452 [details]
File: anaconda-tb

Created attachment 803453 [details]
File: storage.log

Really weird. Same layout and procedure I've been using for a week and I keep getting crashes now. I've even used wipefs -a on prior partitions, and removed them with gdisk so that I'm working in anaconda with only free space.

cmdline:        /usr/bin/python  /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8
cmdline_file:   BOOT_IMAGE=/isolinux/vmlinuz0 root=live:LABEL=Fedora-Live-Desktop-x86_64-20-Al ro rd.live.image quiet rhgb
hashmarkername: anaconda
kernel:         3.11.0-300.fc20.x86_64
other involved packages: python-libs-2.7.5-7.fc20.x86_64, python-blivet-0.20-1.fc20.noarch
package:        anaconda-20.18-1.fc20.x86_64
packaging.log:  
product:        Fedora
reason:         FSError: filesystem already exists
release:        Fedora release 20 (Heisenbug)
version:        20

Created attachment 803460 [details]
c10, anaconda-tb

Created attachment 803461 [details]
c10, program.log

Created attachment 803462 [details]
c10, anaconda.log

Created attachment 803464 [details]
c10, storage.log

c10 attachments are logs for the crash reported in comment 10, which might be simpler to follow because I created the layout I wanted in a single shot without backtracking.

The failure occurs while the GUI says it's creating ext4 on /dev/sda6, which seems wrong because /dev/sda6 is supposed to be btrfs.

Proposing as F20 beta blocker: "When using the custom partitioning flow, the installer must be able to create mount points backed by ext4 partitions, LVM volumes or btrfs volumes and reject or disallow invalid disk and volume configurations without crashing."

The one thing I can thing of I'm doing differently today, is setting a hostname in the installer. But I don't see how that'd be related.

I just tried doing (what I think is) exactly the same thing in c10, but with these updated versions applied, and did not get a crash. Install completes.

anaconda-20.20-1.fc20.x86_64.rpm
anaconda-widgets-20.20-1.fc20.x86_64.rpm
btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc20.x86_64.rpm
python-blivet-0.22-1.fc20.noarch.rpm

It'd be great to find that this has been accidentally fixed, but I need to add something to blivet to prevent scheduling of non-btrfs formatting on btrfs volumes. I just need to find the time to decide where and how to enforce it.

The root cause of this bug is in the anaconda custom storage spoke, so don't reassign this bug to python-blivet until/unless we're certain the anaconda part is resolved.

Discussed this in the 2013-10-02 Blocker Review Meeting [1]. This has been voted an AcceptedBlocker. This violates the following F20 beta release criterion for btrfs custom partitions: "When using the custom partitioning flow, the installer must be able to ... Create mount points backed by ext4 partitions, LVM volumes or btrfs volumes, or software RAID arrays at RAID levels 0, 1 and 5 containing ext4 partitions" [2].


[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-02/
[2] https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Custom_partitioning

I've been unable to reproduce this failure at all, nor can I see why it might have happened in the first place.

Neither can I now that source media has been replaced.

It might be related to other weird behavior I had in another bug, the result of which seems to be USB media face planting after it had been working for several days, and even though it was passing multiple badblock -w tests. It's since been fired.

Discussed this in 2013-10-09 Blocker Review Meeting [1]. This bug has been fixed. Closing.

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2013-10-09/

Created attachment 813870 [details]
ABRT Screenshot.

anaconda 20.25.1-1 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/blivet/formats/fs.py", line 779, in create
    raise FSError("filesystem already exists")
  File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 471, in execute
    options=self.device.formatArgs)
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions
    action.execute()
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 310, in doIt
    self.devicetree.processActions()
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 169, in turnOnFilesystems
    storage.doIt()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 142, in doInstall
    turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall)
  File "/usr/lib64/python2.7/threading.py", line 764, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run
    threading.Thread.run(self, *args, **kwargs)
FSError: filesystem already exists

ABRT pointed to this bug-report, but it CLOSED, it did no more...
I don't line current ABRT behaviour, at least put something on the bugreport.
Attaching ABRT screenshot.

I was able to rerproduce it, by deleting the guest and re-creating it and repeating the steps.

I basically tried to install F20-bTC5, with manual partitioning (btrfs) with:
/boot, 512mb EXT4 ; swap, 512mb ; and the rest for / on btrfs.


I do have the logs, i will attach them if someone wants them.

I cannot re-open it. 

Per comment #18, it was an accepted blocker for alpha. Maybe this should be checked again.

Please post the reproduce steps exactly and also post as separate attachments anaconda, program, storage logs; and also attach a "journalctl -b > journalctl.txt" file.

It's an accepted blocker for beta IF reproducible but for now it's closed because it's not reproducible.

Created attachment 813877 [details]
anaconda-tb-*

Created attachment 813878 [details]
anaconda.log

Created attachment 813879 [details]
storage.log

Created attachment 813880 [details]
program.log

Created attachment 813882 [details]
syslog

Ok, the workaround is to enter Manual/Custom partitioning setting the scheme to 'standard' and switching the / to btrfs manually.

I think this should be re-opened.

From 'anaconda.log' (both with partition scheme set to 'btrfs'):

Guest #1: 

17:47:06,495 INFO anaconda: fs space: 6.91 GB  needed: 2.56 GB
17:47:06,499 INFO anaconda: spoke is ready: <pyanaconda.ui.gui.spokes.storage.StorageSpoke object at 0x7f22a33bf1d0>
17:47:08,223 INFO anaconda: Running Thread: AnaInstallThread (139786704557824)
17:47:09,505 INFO anaconda: Ajustando el entorno de instalación
17:47:09,791 INFO anaconda: Creando disklabel en /dev/vda
17:47:10,607 INFO anaconda: Creando ext4 en /dev/vda1
17:47:12,568 INFO anaconda: Creando swap en /dev/vda3
17:47:13,025 INFO anaconda: Creando btrfs en /dev/vda2
17:47:13,807 INFO anaconda: Creando btrfs en /dev/vda2
17:47:14,582 INFO anaconda: Creando ext4 en /dev/vda2  <<<<<

Guest #2:

18:20:52,120 INFO anaconda: fs space: 34.81 GB  needed: 2.56 GB
18:20:52,124 INFO anaconda: spoke is ready: <pyanaconda.ui.gui.spokes.storage.StorageSpoke object at 0x7f2cce5ae090>
18:20:54,493 INFO anaconda: Running Thread: AnaInstallThread (139830396888832)
18:20:55,503 INFO anaconda: Ajustando el entorno de instalación
18:20:55,750 INFO anaconda: Creando disklabel en /dev/vda
18:20:56,465 INFO anaconda: Creando ext4 en /dev/vda1
18:20:57,487 INFO anaconda: Creando swap en /dev/vda2
18:20:58,307 INFO anaconda: Creando btrfs en /dev/vda3
18:20:58,851 INFO anaconda: Creando btrfs en /dev/vda3
18:20:59,349 INFO anaconda: Creando ext4 en /dev/vda3   <<<<<
18:20:59,351 DEBUG anaconda: running handleException

But *what* steps are you referring to? Do you have discrete steps for reproducing this bug?

I don't understand how this can have been closed, it is practically impossible to get around this bug. I have just tried several times. Unfortunately my long explantion of hos to reproduce is now lost, as my bugreport was rejected as a duplicate of this one. Is it kept somewhere on disk? There is no back button in the anaconda bug reporter!

If you'd read the comments, you'd understand that it's closed because no one has posted steps so that anyone else can reproduce it.

Here are the most simple steps to reproduce it. 

0. Boot Fedora 20b TC5 (no kernel parameter, either on a new guest or on an unpartitioned disk)

1. Reach the Welcome Hub (either use the default -English- or select your language -mine is Spanish-)

2. Leave defaults for Date & Time, Language Support, Keyboard, Installation Source, Software Selection, Network Configuration.

3. Enter Installation Destination Spoke.

4. The single disk is already selected. Press 'done'

5. On Installation Options Dialog, choose to do custom/manual partitioning ("I want to review...") and select 'btrfs' for the Partition Scheme, then 'Continue'.

6. Click '+' add '/boot' of '512'

7. Click '+' add 'swap' of '512'

9. Click '+' add '/' of <null>, anaconda will select the maximum size (as intended).

10. Press 'done' to return to the Main Hub.

11. Press 'Accept Changes' in 'Summary Of Changes' dialog. 
    There it can be seen (among other entries):
    * Create Format btrfs           vda3
    * Create Device btrfs volume    fedora
    * Create Format btrfs           fedora
    * Create Device btrfs subvolume root   <<< HERE
    * Create Format ext4            root   <<< HERE

12. In the Main Hub, Start Installing, an 'unknown error' will popup.

Perfect, comment 35 is it. There's something about NOT doing it via guided partitioning, or using the "automatically partitiong" link in Manual Partitioning. When manually creating each of the partitions as described, I always trigger this crash.

Reopening.

Created attachment 814368 [details]
screencast reproducing the conditions of crash

In the Summary of Changes you can clearly see item 20 is to create format ext4 on device root mountpoint / even though steps 16-19 just created a btrfs volume and root subvolume.

I put the wrong bug id in the commit message. This should be fixed in python-blivet-0.23.2-1.

Squishing confirmed, does not occur with beta TC6: python-blivet-0.23.2-1, anaconda-20.25.4-1.

python-blivet-0.23.2-1.fc20 went stable as part of FEDORA-2013-20033 and the fix was verified, so this can be closed.