Bug 892747

Still true.  Documentation still says that --useexisting has no meaning.  Yeah, right.

Fixed kickstart doc on wiki today. I have a patch for the failure to set a mountpoint (which I see is not mentioned here at all) -- will send it for review on monday.

Indeed!!!  The failure to set the mountpoint is the next problem I started to look at.  Lucky for me, you have already identified this and have a patch!  Thank you.  If you have an update file I can use to test against (F20 alpha or whatever), I will test it.

I assume that this current response is the result of my messages on the mailing lists.  I have no idea why my initial report did not mention that, while --useexisting get rid of the error condition, the subvolume was not in /etc/fstab as a mount point.

Actually, this has only become a larger problem for me as I have begun to make more use of btrfs and more use of multiple, separate btrfs volumes.  My extreme case is where I have a "system" btrfs volume on a small SSD, a separate btrfs volume which has the home subvolume among others, and a third btrfs subvolume for data storage.

Currently, I am using a post install script to append entries to /etc/fstab to get around the problem of missing mount points.

ping.

I only recently (today) became aware that there was an anaconda patch mailing list.  Checking that and the git repository, I do not see any fix for this problem.

I tried coming up with something myself but it is not as easy as it appears.  On the surface of it, it looks like adding a couple of lines of code --

class BTRFSData(commands.btrfs.F17_BTRFSData):
...
        if self.preexist: 
...
           dev.format.mountpoint = self.mountpoint
           dev.format.mountopts = "subvol=%s" % (self.name)

This is similar to what is done for logvol and partitions BUT ... it does not work
and the actual root is home/root2

If I do not define mountopts, the the /etc/fstab has subvolid=0 and things are still screwed up.

Like a said, a bit more complicated and well beyond my understanding of how anaconda and python work.

Sure would like to test your patch.

The light-bulb just lit up ... once I figured out what was right/wrong, the fix is simple.  I will post my version of a patch later today.

Two questions/problems:

1.  I am getting a device rather than a UUID in /etc/fstab ... need to see how to drive getting UUID.

2.  Currently, the test if for self.preexist ... should not the test also include "not self.format" since for the btrfs command, they can be used interchangably?

Created attachment 810721 [details]
Patch to kickstart.py for Fedora 19

1, still not getting UUID in /etc/fstab
2. tested against anaconda-19.30-13 installing Fedora 19
3. Working on similar patch for Fedora 20 anaconda 20.22-1

Created attachment 810724 [details]
fix btrfs subvolume support for existing subvolumes

Build on Fedora 20 TC1 system, tested installing Fedora 20 TC2 system with anaconda-20-22-1.

OK, the UUID thing looks like it really is a bug ... the problem is that the fstabSpec attribute for the the "existing" btrfs subvolume has a value of /dev/___ that than UUID=____

Other regular partitions or new BTRFS subvolumes correctly have UUID= in /etc/fstab

Created attachment 811586 [details]
Fedora 19 (anaconda 19.30.13-1) support exiting BTRFs subvolume

The patch add support for existing BTRFS subvolumes to be added to /etc/fstab if --noformat is specified.  Also, if either --useexiting or --noformat can now be specified for a BTRFS existing volume.

Created attachment 811587 [details]
Fedora 20 (anaconda 20-22-1) existing BTRFS support with --noformat

This fix adds support for an existing BTRFS subvolume with --noformat specified to be added to /etc/fstab with the correct UUID= of the parent BTRFS volume.

This patch also changes things so that either --noformat or --useexisting can be used on an existing BTRFS volume specification.

A BTRFS specification with --useexisting specified is currently ignored.  This could "easily" be turned into the equivalent of "reformat" by scheduling a subvolume delete action before then doing the create.

Yes, there was nothing wrong with the fstabSpec property code, the property being executed was different from the one I expected.

Another point ... although the documentation has been updated, it is still incorrect.  Both --useexisting and --noformat have NO meaning for a BTRFS volume and the volume specification is ONLY done when the volume is created.  One or more partition statements are used to define and existing BTRFS volume.

Therefore, --noformat (and possibly --useexisting) can only have a possible meaning with respect to a subvolume.

It has taken me a little time to realize that this is how the code really works.

Created attachment 811736 [details]
anaconda-19.30.13-1 patch (for creating updates)

slightly revised

Created attachment 811737 [details]
anaconda-20-22-1

slightly revised.  Build on Fedora 20 beta-TC1+ system and then tested by installing with Beta-TC2+all-repos

anaconda-20.25.1-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.25.1-1.fc20

Package anaconda-20.25.1-1.fc20, python-blivet-0.23.1-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-20.25.1-1.fc20 python-blivet-0.23.1-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-19194/python-blivet-0.23.1-1.fc20,anaconda-20.25.1-1.fc20
then log in and leave karma (feedback).

OK, since I need python-blivet-0.23.1-1, AND it is in Beta-TC5, I gave that a try.

NOTHING IS FIXED!  And from what I see in the code, this is what I expect!

Please, PLEASE look at the patches attached to this report AND the code that is done for both logical volume and regular partitions.  That is what I did.

You need two additional lines of code after the 
    device.format.mountpoint = self.mountpoint
and they are:
    device.format.mountopts = "subvol=%s" % (self.name)
    device.format.uuid = dev.uuid

The first one sets the proper subvol name and the second provides the UUID of the parent (the BTRFS volume).  Without the UUID, the /dev/___ will be used.

I also noticed that swap is no longer listed in /etc/fstab ... was this intentional?  I am not sure (and from comments in the code, other are not either) why it ever was listed.

However, I can also understand that just because you have a volume that looks like it is swap does not mean that you want it used for swap so there is a good reason for having it listed in /etc/fstab.  I hope this does not break something.

BTW, to arrive at needing all three of the above three lines of code, I sat patently tracing anaconda install both the kickstart part and the install part to see what actually happened and what code actually was executed.

swap is a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1020867

Oh my, one step forward, fourteen back. I took mu "little" advice and created an updates image for TC5 ... oops, still no existing BTRFS subvol in /etc/fstab.  I am suspicious of the changes to python-blivet.

Question: what was "wrong" with my proposed patch for fixing existing subvolumes?  It used exactly the same approach as that used for regular partitions and logical volumes.  Whatever change was made seems to have screwed up handling of swap as a side effect.

Created attachment 813828 [details]
fix anaconda-20.25.1-1

OK, this will fix 20.25.1 so that it really works.

device.format needs some stuff se ... not device.  Setting:
    device.format.mountpoint = self.mountpoint
actually gets it added to the queue.

anaconda-20.25.1-1.fc20, python-blivet-0.23.1-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

This problem is not fixed by anaconda-20.25.1 and python-blivet-0.23.1-1 as available in Fedora-20-Beta-TC5 as I have previously stated.

anaconda-20.25.4-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/anaconda-20.25.4-1.fc20

Package anaconda-20.25.4-1.fc20, pykickstart-1.99.44-1.fc20, python-blivet-0.23.2-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing anaconda-20.25.4-1.fc20 pykickstart-1.99.44-1.fc20 python-blivet-0.23.2-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-20033/pykickstart-1.99.44-1.fc20,python-blivet-0.23.2-1.fc20,anaconda-20.25.4-1.fc20
then log in and leave karma (feedback).

Already did that.  Fixes "good enough for now" and submitted patch to fix getting UUID in fstab.  I will also attach that patch here.

Created attachment 816542 [details]
set subvol UUID so UUID is used in fstab - for anaconda-20.25.4-1

anaconda-20.25.4-1.fc20, pykickstart-1.99.44-1.fc20, python-blivet-0.23.2-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.