Bug 1418336 - Anaconda won't accept /boot on btrfs subvol, installation is impossible on my machine
Summary: Anaconda won't accept /boot on btrfs subvol, installation is impossible on my...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 32
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
Assignee: Neal Gompa
QA Contact: Fedora Extras Quality Assurance
Whiteboard: AcceptedFreezeException
: 1560506 1565694 (view as bug list)
Depends On: 1094489
Blocks: F28BetaFreezeException
TreeView+ depends on / blocked
Reported: 2017-02-01 15:14 UTC by Manu
Modified: 2020-04-06 10:47 UTC (History)
22 users (show)

Fixed In Version: anaconda-32.18-1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-04-03 14:41:09 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 864198 0 unspecified CLOSED grubby fatal error updating grub.cfg when /boot is btrfs 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1094489 0 unspecified CLOSED add support for btrfs in grub2 on /boot 2021-02-22 00:41:40 UTC

Internal Links: 864198 1094489

Description Manu 2017-02-01 15:14:18 UTC
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:


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...

Comment 1 Fedora End Of Life 2017-02-28 11:09:16 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 2 Nathaniel McCallum 2018-03-05 19:02:35 UTC
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):


Anaconda team, can we please enable this?

Comment 4 Nathaniel McCallum 2018-03-05 20:36:41 UTC
I have submitted a patch to Anaconda:


Comment 5 Fedora Blocker Bugs Application 2018-03-06 16:26:18 UTC
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:

Comment 6 Geoffrey Marr 2018-03-12 20:46:53 UTC
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

Comment 7 Manu 2018-03-12 21:06:53 UTC
Huzzah! Looking forward to F28!

Comment 8 Samantha N. Bueno 2018-03-26 16:41:59 UTC
*** Bug 1560506 has been marked as a duplicate of this bug. ***

Comment 9 Leslie Satenstein 2018-04-05 19:42:23 UTC
Works just fine with SUSE Tumbleweed.  If they can do it, so can Fedora.

Comment 10 Chris Murphy 2018-04-05 20:12:32 UTC
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.

Comment 11 Manu 2018-04-05 22:58:49 UTC
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.

Comment 12 Chris Murphy 2018-04-05 23:46:54 UTC
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.

Comment 13 Manu 2018-04-06 00:01:19 UTC
Great. That'll be simpler.
/boot on subvolume is still useful though in niche cases.

Comment 14 Christopher Patrick 2018-04-09 04:03:49 UTC
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.

Comment 15 Samantha N. Bueno 2018-04-09 09:04:20 UTC
(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.

Comment 16 Christopher Patrick 2018-04-09 18:57:43 UTC
That sucks since you for approval to try it in f28 and people have been wanting it for years

Comment 17 Nathaniel McCallum 2018-04-09 19:04:24 UTC
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:

Once F28 is released, we can do the same thing there.

Comment 18 Christopher Patrick 2018-04-09 19:15:57 UTC
OK, thanks sounds good

Comment 19 Manu 2018-04-09 22:39:05 UTC
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?

Comment 20 Adam Williamson 2018-04-09 22:41:44 UTC
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.

Comment 21 Christopher Patrick 2018-04-09 23:15:11 UTC
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.

Comment 22 Samantha N. Bueno 2018-04-10 14:54:43 UTC
*** Bug 1565694 has been marked as a duplicate of this bug. ***

Comment 23 Nathaniel McCallum 2018-04-10 16:24:07 UTC
(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.


Comment 24 Christopher Patrick 2018-04-11 00:40:42 UTC
Thanks i got it working now

Comment 25 Christopher Patrick 2018-04-11 00:48:39 UTC
Thanks i got it working now

Comment 26 Chris Murphy 2018-04-11 01:10:43 UTC
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

Comment 27 Tomasz Kłoczko 2018-06-26 12:50:35 UTC
Looks like still anaconda GUI installer does not allow to have /boot on btrfs.

Comment 28 Chris Murphy 2018-06-26 16:27:27 UTC
The pull requests are in, they just haven't had time to merge them yet.

Comment 29 Jan Kurik 2018-08-14 10:31:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 30 Leslie Satenstein 2019-10-06 16:40:41 UTC
I have dropped btrfs support for Fedora 30 and Fedora 31.  I run a separate btrfs system with another distribution.

Comment 31 Ben Cotton 2019-10-31 18:47:27 UTC
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.

Comment 32 Adam Williamson 2019-11-04 18:08:56 UTC
I believe mkolman was telling me this is finally addressed in rawhide?

Comment 33 Tomasz Kłoczko 2019-11-04 20:42:31 UTC
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.

Comment 34 Jiri Konecny 2019-11-05 11:13:18 UTC
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.


As soon as this will be prepared we are happy to merge it.

Comment 35 Neal Gompa 2019-12-18 01:08:03 UTC
Revised pull request posted: https://github.com/rhinstaller/anaconda/pull/2255

Comment 36 Jiri Konecny 2019-12-18 11:18:57 UTC
Assigned to a developer of this feature.

Comment 37 Adam Williamson 2020-01-07 15:52:53 UTC

Comment 38 Ben Cotton 2020-02-11 15:41:22 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 32 development cycle.
Changing version to 32.

Comment 39 Neal Gompa 2020-04-03 14:41:09 UTC
This is now supported in Fedora 32.

Comment 40 Jiri Konecny 2020-04-06 10:47:53 UTC
Don't you want to write a blog post/announcement about this Neal? :)

Note You need to log in before you can comment on or make changes to this bug.