Created attachment 626714 [details]
anaconda-tb log

Created attachment 626715 [details]
anaconda-tb log

Created attachment 626716 [details]
program log

Propose as blocker: Fedora 18 Beta Release Criterion #11. The installer must be able to create and install to software RAID-1.

Contra-argument is that md raid1 works, and the release criteria don't explicitly state that btrfs raid1 is a requirement. The resulting filesystem, while data raid0 not raid1, would be workable for the purposes of beta testing, despite this bug. For F18beta, I'm -1 blocker, +1 NTH; For F18Blocker, I'm +1 blocker.

Please try again with anaconda-18.17-1. BTRFS raid options in the UI were very messed up in 18.16 and earlier.

Discussed at 2012-10-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-17/f18beta-blocker-review-4.2012-10-17-16.00.log.txt . We agreed that this is yet another area that needs clarification in the criteria: when it was written, "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" clearly meant 'mdraid' when it talked about 'software RAID', but Chris argues strongly that in fact, the term covers btrfs-with-redundancy just as well as it covers mdraid.

Still, for F18 purposes we agreed to take the original intent of the criterion rather than a strict interpretation as it applies to currently available technologies, so since btrfs-with-redundancy is not what we meant by 'software RAID' at the time, this is rejected as a blocker. It's accepted as NTH as changes should only affect btrfs devices and this would be a useful fix to have for Beta.

For F19, we should clarify the criteria.

Not fixed in anaconda-18.18-1. Checkboxes aren't sticking, resulting file system for two disks is still data raid0, not raid1.

Created attachment 629153 [details]
program.log, smoke11 includes anaconda-18.18

Command still is missing -d raid1: 00:59:04,007 INFO program: Running... mkfs.btrfs --label=fedora_f18v /dev/sda2 /dev/sdb1

Confirming this is still valid in 18.19.

I set up a VM with two disks, a 15GB and a 10GB, blank. I went to custom partitioning and created the partitions 'automatically', which gave me a 500MB /boot, a 14GB / , and 4GB of swap. I picked the / partition and set it to Device Type BTRFS and checked the checkbox for 'redundancy'; even though this should cause it to reduce to a max size of 10GB or so it didn't reduce the displayed size of the partition or pop up a warning or anything, it let me complete partitioning and run the install.

After install I booted the installed system. It seems anaconda created a 10GB partition on the first disk and a 10GB partition on the second disk and combined them into a single...volume?...and mounted it as /. I verified with 'btrfs filesystem df /' (thanks chris murphy) that the / partition says:

'Data, RAID0'
'Metadata, RAID1'

indicating it's storing the data striped, not redundant. 'df -h' shows the / partition as 20GB in size, further confirming this. Like in Chris' test, there is no '-d raid1' passed to mkfs.btrfs in the program.log.

Setting back to assigned.

this probably fails "The installer must be able to create and install to any workable partition layout using any file system offered in a default installer configuration, LVM, software, hardware or BIOS RAID, or combination of the above", so nominating as a Final blocker too.

Logs would help.

program.log and anaconda-tb.log attached to this bug; which other logs would you like? At the moment anaconda 18.19 Redundancy checkbox doesn't stay checked.

Created attachment 633057 [details]
all *.logs

All *.log files at installation completion, in /tmp.
Fedora-18-Beta-TC6-x86_64-Live-Desktop.iso
anaconda-18.19-1

Redundancy checkbox won't stay checked. Unchecks in between clicking between Root and Boot. Also unchecks itself upon clicking the Apply button.

I didn't notice it doing that, but I'll re-do my install, watch the checkbox, and get logs too.

erm, if you're installing from a live image, you can't change the filesystem for / , can you? that's one of the known limitations of live installs...

(In reply to comment #15)
That's oldui, because the install image was ext4, then resized to fit /. With newui they're doing it differently, presumably to support either ext4 or btrfs live installs. I end up with a completely valid bootable raid0 btrfs only install for boot root and home on subvols. It's just that it should be raid1.

(In reply to comment #15)
> erm, if you're installing from a live image, you can't change the filesystem
> for / , can you? that's one of the known limitations of live installs...

It has nothing to do with newui specifically, but the live backend was rewritten for F18 and this limitation was removed.

anaconda-18.22-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.22-1.fc18

Heh, I'm learning stuff from this bug.

So I did an install following the procedure outlined above with smoke13. 'btrfs filesystem df /' says DATA, RAID1: total=4.00GB used=2.63GB. So that looks like it's working. Funnily, 'df -h' reports rootfs Size: 20G Used: 5.8G Avail: 13G. So I think df doesn't understand btrfs RAID1 - it reports a filesystem twice as large as it should be (20G not 10G), with twice as much data on it as btrfs df. But that's a bug in df, probably, it seems like my test verifies this is fixed.

The behaviour of the custom part screen here still seems problematic - I just changed a 15GB partition to Device Type btrfs, with redundancy checked, and then the screen variously claimed it was either 15GB or 20GB in size, but gave me a 10GB RAID-1 device in the end. But that's another separate report. Setting VERIFIED.

anaconda 18.22-1 in smoke13 appears to fix this bug. I get a raid1 btrfs volume.

(In reply to comment #19)
re: how df works vs 'btrfs fi df /' there are recent discussions on linux-btrfs.org list about improving btrfs fi df, and also about the "doubling" effect. In some respect the question of file system size is perspective. For e.g. ext4 on md raid, you're right, the file system isn't 20GB but 10GB and "duplicated" by the md layer. But in btrfs that's not what happens, the file system is 20GB and files using the raid1 data profile take up twice as much space (on in each of mirrored chunks on different devices); it's expected that per subvolume and even per file data profiles can be applied, and same for compression options. So it seems to make more sense to treat the volume/pool as the true size that it is, since the various data profiles apply to the data, not the volume.

Package anaconda-18.22-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.22-1.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17432/anaconda-18.22-1.fc18
then log in and leave karma (feedback).

anaconda-18.23-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.23-1.fc18

anaconda-18.24-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.24-1.fc18

anaconda-18.25-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.25-1.fc18

anaconda-18.26-1.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/anaconda-18.26-1.fc18

18.26 went stable. Closing. (Bodhi closing of bugs when updates go stable is currently broken).