Description of problem: 1. two disks chosen for installation 2. root and home set to btrfs with redundancy checked 3. minimal install reproducible. 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/devices.py", line 784, in create : raise DeviceCreateError(str(e), self.name) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 241, in execute : self.device.create() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 324, in processActions : action.execute() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 360, in doIt : self.devicetree.processActions() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 198, in turnOnFilesystems : storage.doIt() : File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 101, in doInstall : turnOnFilesystems(storage) : File "/usr/lib64/python2.7/threading.py", line 504, in run : self.__target(*self.__args, **self.__kwargs) : File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 87, in run : threading.Thread.run(self, *args, **kwargs) :DeviceCreateError: ('-6', 'fedora_f18v')
Created attachment 624551 [details] File: anaconda-tb
Created attachment 624552 [details] File: product
Created attachment 624553 [details] File: type
Created attachment 624554 [details] File: ifcfg.log
Created attachment 624555 [details] File: storage.log
Created attachment 624556 [details] File: version
Created attachment 624557 [details] File: environ
Created attachment 624558 [details] File: anaconda.log
Created attachment 624559 [details] File: syslog
Created attachment 624560 [details] File: hashmarkername
Created attachment 624561 [details] File: packaging.log
Created attachment 624562 [details] File: cmdline_file
Created attachment 624563 [details] File: release
Created attachment 624564 [details] File: program.log
Reproducible 100% in Vbox 4.2.0 VM with 80GB VDIs. Will try to reproduce in KVM on request. Exact steps to reproduce, starting with new VDIs, TC3 netinstall 1. Boot from Fedora-18-Beta-TC3-x86_64-netinst.iso 2. Installation Destination > select two 80GB disk icons > custom partitioning checked, contine. 3. Click "click here to create them automatically" 4. Select Home > Customize > Device Type BTRFS > Redundancy checked 5. Select Root > Customize > Device Type BTRFS > Redundancy is already checked NOTE at this point Home is 108GB which exceeds the 80GB size of either disk, so somehow the redundancy option may not in fact be having an effect. 6. Clicked Finish Partitioning 7. Leaving GNOME Desktop as Software Selection (default) for this attempt. 8. Begin Installation Status hangs at "Creating disklabel on /dev/sda" with a dialog that says "unknown error has occured" Attaching a new set of logs for this reproduction as tgz. Propose blocker: Beta Release Criteria #10. Installer's custom partitioning mode must be capable of creating an offered filesystem or reject obviously invalid operations without crashing; and Criteria #11, installer must be able to create and install to software RAID-1 (i.e. BTRFS redundancy). No contra-argument or work around discovered.
Created attachment 625334 [details] new logs per comment 15
Discussed at 2012-10-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-11/f18beta-blocker-review-3.1.2012-10-11-16.04.log.txt . The partitioning criteria are somewhat in flux ATM but there was solid agreement that whatever they wind up being, they should cover this bug. :) It's accepted as a blocker under current criterion "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".
00:34:07,268 INFO program: Running... mkfs.btrfs --label=fedora_f18v /dev/sda2 /dev/sdb1 00:34:07,305 INFO program: 00:34:07,307 INFO program: WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL 00:34:07,307 INFO program: WARNING! - see http://btrfs.wiki.kernel.org before using 00:34:07,307 INFO program: 00:34:07,308 INFO program: adding device /dev/sdb1 id 2 00:34:07,308 INFO program: fs created label fedora_f18v on /dev/sda2 00:34:07,308 INFO program: nodesize 4096 leafsize 4096 sectorsize 4096 size 850.00GB 00:34:07,308 INFO program: Btrfs Btrfs v0.19 mkfs.btrfs is getting SIGABRT again at the very end of fs creation.
This command isn't correct for the option specified in the UI: mkfs.btrfs --label=fedora_f18v /dev/sda2 /dev/sdb1 It's missing -d raid1. The above command is the equivalent of -d raid0. However the resulting raid0 on sda2 and sdb1 is valid, no file system errors on mount. And the same command in shell results in no errors.
Give this a whirl http://koji.fedoraproject.org/koji/taskinfo?taskID=4600465
setting needinfo tflink - he will build a smoketest image with the btrfs-progs scratch build included, for Chris to test with.
Smoketest image built with anaconda-18.18-1, new firewalld and the build from comment#20. http://dl.fedoraproject.org/pub/alt/qa/18/20121017_f18b-smoke11/
(In reply to comment #22) > Smoketest11 Appears to be fixed, installer proceeds. New problem is that 'btrfs subvolume list <mp>' does not list subvols; reboot to earlier version of btrfs-progs and the command does list subvols on the same volume. I'll file a separate bug on that if it remains reproducible with the next TC.
(In reply to comment #20) > Give this a whirl > > http://koji.fedoraproject.org/koji/taskinfo?taskID=4600465 Josef: is that any different than the build in the latest btrfs-progs update [1]? If so, how is it different? If not, would you mind editing that update as fixing this bug? [1] https://admin.fedoraproject.org/updates/FEDORA-2012-16387/btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18
btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-16387/btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18
@Tom, I've updated the update (heh). @Chris, well that's weird, definitely file a new bug and I'll look at whats going on right now.
(In reply to comment #26) > @Chris, well that's weird, definitely file a new bug and I'll look at whats > going on right now. User error. When subvols are mounted, btrfs subvolume list <mp> returns nothing. If I mount the device without subvol= mount option, of course it then lists the subvols.
The fix should be in TC6, so can we just verify that and leave karma on the update please? Thanks!
I was able to reproduce this with a somewhat different setup with TC4: a KVM VM with a 10GB and 15GB disk, wipe both entirely, 'create partitions automatically', set / type to BTRFS and redundancy. As for Chris, this caused a crash with "DeviceCreateError: ('-6'" at install start time. Following the same procedure with TC6 causes no crash, though I'm curious what partition layout I'll actually get. custom partitioning continued to show the size of / as 14GB even after I set it to redundant, which seems impossible. I suspect it'll wind up combined/striped, not mirrored, with 5GB of space wasted. The 'redundancy' checkbox had '+14.4GB' written next to it, but it didn't object to me checking it and continuing with the install. Anyway, the bug reported here seems to be fixed. Chris or David, is there another report open for the apparent problems with actually using BTRFS redundancy?
So before I file a new bug, I'm not sure if this is right or not. The installed system has a /dev/vda2, size 10GB, labelled 'fedora'. It has a /dev/vdb1, size 10GB, labelled 'fedora'. /dev/vda2 is mounted as /, /dev/vdb1 isn't mounted at all. That's according to gnome-disks. According to 'mount', /dev/vda2 is mounted as / , and /dev/vdb1 isn't mentioned at all. /etc/fstab says: UUID=blahblahblah / btrfs subvol=root 1 1 if I do ls -l /dev/disks/by-uuid/blahblahblah (the same UUID referred to in the fstab) it just seems to be a symlink to /dev/vda2, again, vdb1 doesn't seem to come into it. HOWEVER, if I try and mount /dev/vdb1 with gnome-disks, then look at 'mount' again, it says that /dev/vda2 is mounted at /run/media/test/fedora (not /dev/vdb1). So I'm guessing that things are actually working right here, and this is just how a redundant BTRFS...what do you call it? volume?...looks to 'mount' and 'gnome-disks'. If so then it seems those components could do with some improvements in how they display btrfs mounts, but anaconda actually did the right thing (though it didn't really display it very well).
(In reply to comment #29) (In reply to comment #29) The linux partitions are raid0 regardless of UI options checked. This filed under Bug 866101. I can explain other stuff better via chat.
OK, so it looks like it did indeed set it up as RAID-0 not RAID-1. Do we have a bug for that?
whoops, we do, you said so.
Re-opening this because the associated update has not yet been pushed to stable. Will move to VERIFIED
I tried to test mkfs.btrfs with btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 and hit bug 871778. I don't know whether it is related to this bug or a different one.
That doesn't look related to this. I'm not sure trying to format a zero-filled file is even a valid test.
(In reply to comment #36) > That doesn't look related to this. I'm not sure trying to format a > zero-filled file is even a valid test. It definitely works with ext4. You can create your ext4 partition in a file and then mount it over loopback.
btrfs-progs-0.20.rc1.20121017git91d9eec-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/btrfs-progs-0.20.rc1.20121017git91d9eec-2.fc18
Package btrfs-progs-0.20.rc1.20121017git91d9eec-2.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 btrfs-progs-0.20.rc1.20121017git91d9eec-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-17438/btrfs-progs-0.20.rc1.20121017git91d9eec-2.fc18 then log in and leave karma (feedback).
Josef, the update has been unpushed. We have now no Bodhi update to fix this Beta blocker.
Kamil: no, it's fine. We pushed the *earlier* update stable, because we didn't want to take the later one. https://admin.fedoraproject.org/updates/FEDORA-2012-16387/btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18 is stable and in the package set at https://dl.fedoraproject.org/pub/fedora/linux/development/18/x86_64/os/Packages/b/ . Closing bug.
btrfs-progs-0.20.rc1.20121017git91d9eec-3.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/btrfs-progs-0.20.rc1.20121017git91d9eec-3.fc18
btrfs-progs-0.20.rc1.20121017git91d9eec-3.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.