Bug 886691 - RFE: basic support for installing on existing btrfs volume
RFE: basic support for installing on existing btrfs volume
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
Unspecified Linux
unspecified Severity high
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-12 16:45 EST by Gene Czarcinski
Modified: 2013-08-12 14:35 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-12 14:35:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gene Czarcinski 2012-12-12 16:45:46 EST
Description of problem:
There is no way that this will be addresses before F18 but I would like to see it soon after the release.  Individuals could then do more testing with btrfs

Currently (F18-beta), you can install root and additional subvolumes on a newly created btrfs volume (storage pool).  You can also do this with kickstart IF it is a freshly formatted btrfs pool.

You cannot create a new subvolume for root ... either with the gui or kickstart (or, at least I have not figured out how to do it).

Yes, btrfs may not be ready for prime time but I am not asking to make it the default ... stick with LVM for now ... it is known to work.

But, if Fedora is ever going to switch over to using btrfs as a default, we have to be able to create new subvolumes in existing storage pools and begin testing these to find any bugs.
Comment 1 Chris Murphy 2012-12-13 17:14:45 EST
Including /boot in a subvol, presently disallowed by anaconda 18.37.2-1. There is a grubby bug that may be slowing this up, bug 864198, which prevents kernel updates from being added to grub.cfg.
Comment 2 Chris Murphy 2013-01-04 19:49:43 EST
(In reply to comment #1)
> Including /boot in a subvol, presently disallowed by anaconda 18.37.2-1.
Fixed in 18.37.8-1.

Although ext4 is still default for /boot when using "guided" autopartitioning and choosing 'btrfs' in the partition scheme configuration popup.
Comment 3 Gene Czarcinski 2013-01-05 15:29:43 EST
OK, I just completed an F18 install using smoke14 on a qemu-kvm/libvirt virtual system.

Not only does it install with /boot as a btrfs subvolume but it boots too.

Very good  I am more than pleased!

Now if it would just set the values in fstab correctly with fs_freq and fs_passno both set to zero.

And then there is the larger problem of being able to install into a new subvolume of an existing btrfs volume but we need to leave something for F19 ;}}
Comment 4 Chris Murphy 2013-01-05 16:20:10 EST
(In reply to comment #3)
You can install to a new subvol of an existing volume, the root subvol must be new, but other subvols can be new or reused.

However, creating new root currently causes a crash for me if it's a multiple device Btrfs volume. Bug 892196.
Comment 5 Gene Czarcinski 2013-01-07 10:03:33 EST
Yup, I just verified that you can install with root on a new subvol of and existing single device btrfs volume ... using kickstart!

If there is a way to do this using the anaconda gui, it is not obvious to me.

As far as that goes, how do you manually configure a btrfs volume or an LVM Volgroup?
Comment 6 Chris Murphy 2013-01-07 11:58:59 EST
It's definitely not obvious. Because LVM is default, any new mount point added in Manual Partitioning will cause a complaint that you don't have enough space. So in the previous step before Manual Partitioning, in the Installation Options modal dialog – choose BTRFS for Partition scheme configuration, and check "let me customize" to get to Manual Partitioning. There, click +, enter /, and do not enter a capacity. Now Root moun point is added as a Btrfs subvol to an existing volume.

As for a boot subvol added to existing volume, it's trickier because /boot is always ext4 by default. Again you'll get a no free space error. So add any other mount point such as /usr, which will be added as a subvol, then change the mount point after the fact to /boot. The problem here is that the name of the subvol will be usr, and can't be changed in anaconda. But it can be fixed after installation, in order: mount the top-level and rename the subvol to boot; change the entry in fstab; dracut -f; grub2-install; grub2-mkconfig.
Comment 7 Gene Czarcinski 2013-01-07 13:01:35 EST
Since you can boot from /boot on btrfs, you  do not really need to make it a separate subvol and leave it as part of the new root partition.

Note: to reuse an existing subvol such as "home", you need to specify --useexisting on the kickstart btrfs subvol definition even if the anaconda kickstart documentation says that it does not have any meaning.  If it is not included, anaconda crashes ... no error messages, just bang and you are rebooting.

I guess this means I will be filing another bugzilla report.

This testing was with F18 RC1 netinstall.
Comment 8 Gene Czarcinski 2013-08-12 14:35:44 EDT
I am closing this.  It is not clear that you can create a new root subvolume ("/") in an existing btrfs volume from the gui but you can do it from kickstart and this is good enough for me.  Tested with Fedora 19 ... been busy with other stuff and just got back to this.

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