Bug 1016840 - kickstart ignores mountpoints for preexisting btrfs volumes/subvolumes
kickstart ignores mountpoints for preexisting btrfs volumes/subvolumes
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda (Show other bugs)
All Linux
unspecified Severity medium
: rc
: ---
Assigned To: David Lehman
Release Test Team
Depends On:
  Show dependency treegraph
Reported: 2013-10-08 15:36 EDT by David Lehman
Modified: 2014-06-17 21:40 EDT (History)
3 users (show)

See Also:
Fixed In Version: anaconda-19.31.28-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-13 08:17:33 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
generated kickstart used for installation (1.39 KB, text/plain)
2014-02-20 07:19 EST, Peter Kotvan
no flags Details

  None (edit)
Description David Lehman 2013-10-08 15:36:26 EDT
Description of problem:
When an existing btrfs volume or subvolume is assigned a mountpoint via kickstart the specified mountpoint is disregarded -- the filesystem is not mountpoint during installation, nor is there an entry for it in /etc/fstab.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. create some btrfs vols/subvols
2. specify that they be mounted without reformatting via ks.cfg
3. observe results

Actual results:
mountpoints are not assigned

Expected results:
mountpoints assigned as per ks.cfg

Additional info:
Fedora bug 892747 -- patch exists already but has not been reviewed or pushed.
Comment 2 Peter Kotvan 2014-02-20 07:18:32 EST
I have tried to verify this bug with following setup:

system with two hard disks:
vda: /boot (xfs), / (xfs), swap
vdb: /home (btrfs)

I've reinstalled this system manually recreating all partitions except /home which reused. The installation went without problems.

After that I tried to use generated kickstart from /root/anacond-ks.cfg to reinstall the system once again but anaconda fails before starting GUI with:

"The following problem occurred on line 33 of the kickstart file:
btrfs subvol requires specification of parent volume"

So i have tried to modify the line to include parent volume:
btrfs /home --noformat --useexisting --subvol --name=home rhel

This time the GUI started properly but with "No disks selected" in Installation Destination with following error:

The following problem occurred on line 32 of the kickstart file:
Specified nonexistent BTRFS volume in btrfs command
Comment 3 Peter Kotvan 2014-02-20 07:19:34 EST
Created attachment 865486 [details]
generated kickstart used for installation
Comment 4 David Lehman 2014-02-21 19:05:17 EST
See https://fedoraproject.org/wiki/Anaconda/Kickstart#btrfs if you haven't already.

You cannot use btrfs as an fstype in kickstart. You have to define a volume and, optionally, some subvolumes.

You will need to identify your existing btrfs volume using label or UUID.

I'm not sure if setting it back to ON_QA is correct, but I believe the failure was in the test procedure.
Comment 5 Peter Kotvan 2014-02-26 06:58:41 EST
I was not successful to write kickstart which would reuse btrfs partition myself so I tried to use the one generated by anaconda itself and that kickstart also failed to reuse btrfs.

Could you please provide kickstart you used to produce this bug?
Comment 6 David Lehman 2014-02-27 13:28:07 EST
This sets up the btrfs layout in a first installation:

# Partition clearing information
clearpart --all --initlabel --drives=sda

# Disk partitioning information
part swap --fstype="swap" --ondisk=sda --size=2048
part /boot --fstype="xfs" --ondisk=sda --size=500
part btrfs.12 --fstype="btrfs" --ondisk=sda --size=4096 --grow
btrfs none --label=rhel --data=single btrfs.12
btrfs /home --subvol --name=home 
btrfs / --subvol --name=root 

This will perform a second installation which will set a mountpoint for the preexisting home subvolume from the previous (above) installation:

cleapart --type=none
part swap --fstype="swap" --onpart=sda2
part /boot --fstype="xfs" --onpart=sda1
btrfs /home --subvol --name=home --useexisting --noformat LABEL=rhel
btrfs / --subvol --name=newroot LABEL=rhel
Comment 7 Peter Kotvan 2014-03-04 06:17:40 EST
I have followed your suggestions but any of them does not work. Suggestion for installation failed with bug 1072060. But this can be fixed with adding label "rhel" of btrfs volume at the end of last two lines.

The suggestion for second installation fails with anaconda reporting an error "Unable to allocate requested partition scheme".
Comment 8 David Lehman 2014-03-04 09:34:32 EST
Since you did not include the logs I can only guess what went wrong. Try this:

First install:

# Partition clearing information
clearpart --all --initlabel --drives=sda

# Disk partitioning information
part swap --fstype="swap" --ondisk=sda --size=2048 --label=swap
part /boot --fstype="xfs" --ondisk=sda --size=500 --label=boot
part btrfs.12 --fstype="btrfs" --ondisk=sda --size=4096 --grow
btrfs none --label=rhel --data=single btrfs.12
btrfs /home --subvol --name=home rhel
btrfs / --subvol --name=root rhel

Second install:

cleapart --type=none
part swap --fstype="swap" --onpart=LABEL=swap
part /boot --fstype="xfs" --onpart=LABEL=boot
btrfs /home --subvol --name=home --useexisting --noformat LABEL=rhel
btrfs / --subvol --name=newroot LABEL=rhel

If this does not work, please attach anaconda.log and storage.log.
Comment 9 Peter Kotvan 2014-03-05 06:01:24 EST
With these everything went fine.
Comment 10 Ludek Smid 2014-06-13 08:17:33 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

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