Description of problem: Anaconda complains "/boot file system cannot be of type btrfs subvolume", which is untrue, and then I can't progress the installation./ Version-Release number of selected component (if applicable): F26 alpha (rawhide) How reproducible: 100% Steps to Reproduce: 1. Attempting to install F26 alpha on my machine, 3 partitions exist: EFI, btrfs, swap 2. /boot/efi on EFI, / /home /boot on btrfs subfolumes 3. Anaconda complains, won't progress Expected results: Can install Fedora. Additional info: I boot from refind. I have working Arch and Ubuntu distributions installed with this exact partitioning scheme running fine on this machine. I've also successfully installed Manjaro with same configuration. /boot works just fine on btrfs subvolume. No other distro installers ever had problems. It just seems to be an old outdated error message. This problem is very frustrating, it's been broken for years now. I have attempted to install Fedora with intent to move away from Ubuntu on at least 5 occasions now, but every time I try, Anaconda hits me with this error message and I can't install. I then abandon Fedora hoping it'll get fixed and try again in a year or so. I think it's sad that my adoption of Fedora consistently fails because of an incorrect error in Anaconda which seems to be getting no attention. Guess I'm stuck with Mr Shuttleworth...
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
This was because, historically, grubby didn't support this configuration. However, I just landed a fix for this in rawhide (we plan to backport to F28): https://koji.fedoraproject.org/koji/buildinfo?buildID=1053784 Anaconda team, can we please enable this?
Ref https://bugzilla.redhat.com/show_bug.cgi?id=1094489 , https://bugzilla.redhat.com/show_bug.cgi?id=864198 .
I have submitted a patch to Anaconda: https://github.com/rhinstaller/anaconda/pull/1375
Proposed as a Freeze Exception for 28-beta by Fedora user npmccallum using the blocker tracking app because: This freeze exception depends on the freeze exception for #1094489. Basically, anaconda doesn't whitelist /boot on btrfs subvolumes because grubby didn't support it. Grubby does now (#1094489). Thus, we want to add this configuration to the whitelist. I have tested this configuration manually, but for broader testing it is crucial we land in beta. The worst case scenario is that if we discover a bad bug we just remove the configuration from the whitelist again. This is a single line change. For the details of the change see: https://github.com/rhinstaller/anaconda/pull/1375
Discussed during the 2018-03-12 blocker review meeting: [1] The decision to classify this bug as an AcceptedFreezeException was made as this is a feature that people have been asking for for a long time that would add significant value to the Fedora 28 release, and if we want to add that feature, it would be best to test it in Beta instead of Final. [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2018-03-12/f28-blocker-review.2018-03-12-16.01.txt
Huzzah! Looking forward to F28!
*** Bug 1560506 has been marked as a duplicate of this bug. ***
Works just fine with SUSE Tumbleweed. If they can do it, so can Fedora.
Doing this correctly might be a bit tricky. There's no advantage and some disadvantages of /boot being on a subvolume other than /. When snapshotting, you want /boot in parity with / so that there are matching kernels in /boot with modules on /. Therefore it's better if /boot is a normal directory, rather that on its own subvolume. Whereas when the user has chosen to encrypt root, suddenly /boot needs to once again become a separate partition and fs volume - until such time that the installer can configure GRUB to support encrypted boot.
Personally, I'd be perfectly happy with /boot as a normal direcetory, except that Anaconda wouldn't allow me to do that either. It insists on a /boot volume. In the encryption scenario you mention above, I think there would be 2 btrfs partitions, one encrypted with all the root's, and one unencrypted with the respective /boot's. Even though they're separate partitions, they still want /boot subvolumes to map to their respective / subvolumes on the encrypted partition. The snapshot point is real, but that can be managed.
Once https://github.com/rhinstaller/anaconda/pull/1375 is merged, I'm pretty sure anaconda will allow omitting a /boot mountpoint, which will then cause the already existing /boot directory to be used - using the same logic as when ext4/XFS root is on a plain and unencrypted partition.
Great. That'll be simpler. /boot on subvolume is still useful though in niche cases.
When will this be fixed, this problem is still in the F28 Beta and I don't want to install till this is fixed. If openSUSE, Ubuntu, Arch, Debian, etc can have /boot in the btrfs subvolume so can Fedora.
(In reply to Christopher Patrick from comment #14) > When will this be fixed, this problem is still in the F28 Beta and I don't > want to install till this is fixed. If openSUSE, Ubuntu, Arch, Debian, etc > can have /boot in the btrfs subvolume so can Fedora. Not in F28.
That sucks since you for approval to try it in f28 and people have been wanting it for years
Please note that we are blocked on upstream Anaconda merger. Upstream Anaconda also manages packages in Fedora directly from upstream, so there is no possibility of carrying a downstream patch (I suggested this). Upstream has a lot on its plate, so please focus your volunteer efforts there. I have created a set of Anaconda update images for testing this on F27: https://npmccallum.fedorapeople.org/anaconda/ Once F28 is released, we can do the same thing there.
OK, thanks sounds good
So, wait up. Given that "The decision to classify this bug as an AcceptedFreezeException was made..." [above], I'm hearing that the fixes didn't get merged anyway? F28 will ship without these fixes once again?
Yes. Granting a freeze exception *allows* the changes to be pushed out during a freeze, *if* the maintainer of the package wants to merge them at all and in fact does so and submits an update. It doesn't *compel* anyone to push any changes anywhere. In this case the anaconda team decided they did not want to take the relevant patch at this time.
How do I get the updates.img to work I've tried the boot preminators and adding it to.a f27 workstation live USB and still get the /boot cannot be UEFI error.
*** Bug 1565694 has been marked as a duplicate of this bug. ***
(In reply to Christopher Patrick from comment #21) > How do I get the updates.img to work I've tried the boot preminators and > adding it to.a f27 workstation live USB and still get the /boot cannot be > UEFI error. http://npmccallum.gitlab.io/post/boot-on-btrfs-subvolume/
Thanks i got it working now
Tested the patch https://github.com/rhinstaller/anaconda/pull/1375/commits/beaefbce380ce655408970befbf35dac556e7ac0 applied to Fedora-Workstation-Live-x86_64-28_Beta-1.1.iso and it works: a. Installer allows /boot mountpoint on a Btrfs subvolume "boot", or simply not specified in which case /boot is a directory on the subvolume "root" b. kernel updates result in correctly modified grub.cfg and the newly installed kernel is used by default
Looks like still anaconda GUI installer does not allow to have /boot on btrfs.
The pull requests are in, they just haven't had time to merge them yet. https://github.com/rhinstaller/anaconda/pull/1375 https://github.com/rhinstaller/anaconda/pull/1386
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
I have dropped btrfs support for Fedora 30 and Fedora 31. I run a separate btrfs system with another distribution.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I believe mkolman was telling me this is finally addressed in rawhide?
Two weeks ago when last time I've been using rawhide install image still was not possibel to configure in anaconda GUI system swap layout without swap and /boot on the same btrfs where is rest of the root fs. Simple after forma such install layout installer has been refusing to install such system. So issue still is unresolved.
We agreed that this is a community feature and we will merge the PR as soon as community rebase the existing PR. See https://github.com/rhinstaller/anaconda/blob/master/CONTRIBUTING.rst#pure-community-features. https://github.com/rhinstaller/anaconda/pull/1375 As soon as this will be prepared we are happy to merge it.
Revised pull request posted: https://github.com/rhinstaller/anaconda/pull/2255
Assigned to a developer of this feature.
🎉🎉🎉
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle. Changing version to 32.
This is now supported in Fedora 32.
Don't you want to write a blog post/announcement about this Neal? :)