Description of problem: Anaconda allows Boot to be Device Type BTRFS, after clicking Finishing Partitioning the hub reports: Storage > Installation Destination > Error checking storage configuration. Version-Release number of selected component (if applicable): anaconda 18.18 Fedora-18-Beta-TC5-x86_64-netinst.iso How reproducible: 100% Steps to Reproduce: 1. Boot netinst 2. Installation Destination > select single local disk > choose 'let me customize the partitioning' 3. Manual Partitioning: click Home > Customize > Device Type BTRFS. 4. Repeat for Boot. 5. Repeat for Root. 6. Click through Home, Boot, Root, again to confirm Device Type BTRFS for all. 6. Click Finish Partitioning. Actual results: Installer cannot proceed with selected option due to the error. Expected results: 1. Worked with smoke11, I had a btrfs volume with boot, root, home subvols, although I don't know if anything would install to it; 2 /boot on boot subvolume does work[2] so the error is bogus, installation should proceed. 3. Manual partitioning shouldn't allow the user to select an invalid option. Additional info: [1] Fedora-18b-smoke11-x86_64-netinst.iso [2] grub2-install bakes proper prefix into core.img to support boot in subvol; grub2-mkconfig creates proper grub.cfg pointing to boot subvol as well. Works with arbitrarily named subvols.
Created attachment 630308 [details] anaconda.log
Created attachment 630318 [details] program.log
Created attachment 630319 [details] storage.log 21:24:15,251 DEBUG storage: stage1 device cannot be of type btrfs subvolume 21:24:15,252 DEBUG storage: stage1 device cannot be of type btrfs volume 21:24:15,252 DEBUG storage: stage1 device cannot be of type btrfs subvolume 21:24:15,252 DEBUG storage: stage1 device cannot be of type btrfs subvolume
Reproducible with Fedora-18-Beta-TC5-x86_64-Live-Desktop.iso. After updating to anaconda-18.19-1.fc18 the problem appears to be fixed: boot, root, home are subvols, resulting system is bootable.
With two disks selected, all other steps the same, the error occurs. According to btrfs wiki documentation this should be possible with grub 2.00. If there is a way to override this check in anaconda, and allow it to install to a 2+ disk raid0/1, I'll test. "GRUB 2.00 supports many btrfs configurations (including zlib and lzo compression, and RAID0/1/10 multi-dev filesystems)." https://btrfs.wiki.kernel.org/index.php/FAQ#Does_grub_support_btrfs.3F
(In reply to comment #5) DISREGARD: this was user error. 18.19-1 had not been installed. Once installed the error does not occur with a 2 disk raid0 btrfs volume, which also places boot, root, home in subvols. System is bootable.
Am I reading correctly that this bug report can therefore be closed?
Yes. Was a bug in 18.18, fixed in 18.19.
The code to disallow /boot on a subvolume is still there. If convenient, please attach the logs from the install described in comment 6.
Created attachment 635899 [details] anaconda.log per c9 request TC6/18.19 using /boot on btrfs subvol
Created attachment 635900 [details] program.log per c9 request TC6/18.19 using /boot on btrfs subvol
Created attachment 635901 [details] storage.log per c9 request TC6/18.19 using /boot on btrfs subvol
Created attachment 635902 [details] storage.state per c9 request TC6/18.19 using /boot on btrfs subvol
Somehow we're setting the storage spoke as complete in spite of errors in the sanity check. I think I see the problem. Will update after testing.
Is the idea to have or not have /boot on a boot subvol? It does work, although it instigates a bug in grubby, bug 864198 (viable work around is to manually use grub2-mkconfig).
I also tried to create /boot btrfs subvol and found that i cant. Will the requirement for /boot to not to be a btrfs subvol be enforced for F18?
Can someone find out whether /boot on a subvol with a name other than boot works with grub2?
What is the status of the support of /boot as a btrfs subvol? Currently (18.37.2) anaconda still does not let me create one. Is there any chance that it will be supported for F18 or has it been delayed for F19? (or ditched?) Maybe a different bug is happening: This is the third distinct time that i noticed that an anaconda-tb-XXX file was generated but no 'unknown error' has ever been shown. I now routinely check for unreported 'unknown error', or more likely an 'incognito error' :-(
(In reply to comment #17) > Can someone find out whether /boot on a subvol with a name other than boot > works with grub2? Sorry I missed this question somehow. Yes it does. It also works if /boot is on a subvol which is also in a subvol, e.g. Fedora18/hello. Both grub2-install and grub2-mkconfig figure this out so long as the fstab subvol= is correct.
dracut-024-17.git20121220.fc18, anaconda-18.37.7-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.7-1.fc18
Package dracut-024-17.git20121220.fc18, anaconda-18.37.8-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 dracut-024-17.git20121220.fc18 anaconda-18.37.8-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-20838/dracut-024-17.git20121220.fc18,anaconda-18.37.8-1.fc18 then log in and leave karma (feedback).
Works for me: dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18 "Guided" autopart "partitioning scheme configuration" = BTRFS still produces /boot on ext4. Intentional? Manual Partitioning, Boot, Root, Home on Btrfs subvols is bootable. Renamed subvols boot, root, home; changed them in fstab accordingly; rerun grub2-install and grub2-mkconfig. System is still bootable.
(In reply to comment #22) > Works for me: dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18 > > "Guided" autopart "partitioning scheme configuration" = BTRFS still produces > /boot on ext4. Intentional? As a consequence of this, I think, I cannot add a new Boot mount point to an existing Btrfs volume. Bug 890302.
dracut-024-17.git20121220.fc18, anaconda-18.37.8-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.