Description of problem: anaconda refuses to install to what it calls /boot subvolume Version-Release number of selected component (if applicable): 20.25.14-1 How reproducible: every time Steps to Reproduce: 1. boot F20TC DVD 2. select single disk 3. select btrfs filesystem and custom partitioning 4. create a 50GB / on the disk. I DID NO creat a /boot or any other subvolumes. ONLY / Actual results: Paritioner says /boot cannot be on a subvolume Expected results: Same good installation that I have had on F18, F19, and all of the F20 alphas, betas and final TCs until TC5 Additional info: This has to be a regression or a serious misunderstanding somewhere since I have been able to do an install to a btrfs / and boot into it as outlined above. I know there have been problems with grubby when updating the kernel, but running grub2-mkconfig fixes that problem and it does not affect the installation.
The behavior is regrettable but intentional as a faux-fix for bug 864198 which couldn't be fixed time for F20. The rationale is discussed in that bug. I wish it were easier for anaconda to enable a warning placard for the screen when the user chooses options known to to have problems, rather than having to write a bunch of exception code to change the behavior of the installer at the last minute which risks additional regressions.
This is most unfortunate. We now have one less very easy and straightforward installation method that could have become a default install method. Fedora has taken a huge step back from being "bleeding edge" software. At least could there be a command line parameter that would allow the installation to a btrfs fs? After all, all of the flavors of F20 until TC5 installed to a btrfs fs. Also, why not leave this open and just not a blocker? Otherwise it could fall off the developers radar screen.
I just noticed that it looks like Chris Murphy closed this bug. Is Mr. Murphy one of the anaconda developers? If not, he should not be closing other peoples bugs.
Reopening since this is a regression in anaconda. It may not be a blocker due to bureaucratic handling, but it does deserve to be on the developers radar. Please leave it open, even if the regression is not fixed in F20, it can be carried over to F21.
Devs have better things to do than clean up incorrectly filed bugs. This bug is now a duplicate of bug 1039124. *** This bug has been marked as a duplicate of bug 1039124 ***
https://ohjeezlinux.wordpress.com/2013/01/03/new-rule-about-regressions/ It is not a regression. It is an intentional code change. Those things are very different things. The tool for updating the bootloader, grubby, doesn't correctly handle /boot on btrfs. Its maintainer, pjones, is not interested in making that work right now. https://bugzilla.redhat.com/show_bug.cgi?id=864198#c44 https://bugzilla.redhat.com/show_bug.cgi?id=864198#c50 if the underlying tools are not capable of supporting a given layout, anaconda should not allow it.
So now a duplicate of a newer bug? Someone is playing games. It is a regression. Until final TC5, every version installed and booted with /boot within the btrfs fs. There is a simple workaround for the grubby problem. Run grub2-mkconfig. In fact I did a horrible hack of grubby so I avoided the problem in the 14 successful F20 installs I have done on btrfs. Sure the workaround for us btrfs fans is easy--put /boot on an ext4 partition. But that doesn't keep the pressure on to fix the base problem and see what other problems there are with booting. Would the common brown bear be able to deal with the grubby problem? Probably not. But most of folks who test each fedora release from start to finish would quickly work around it and then real btrfs bugs could be found. OK, I know I am just a lone voice in the darkness and I will now shut-up and color in my coloring book. Respectfully, Clyde Kunkel