Bug 1016840

Summary: kickstart ignores mountpoints for preexisting btrfs volumes/subvolumes
Product: Red Hat Enterprise Linux 7 Reporter: David Lehman <dlehman>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED CURRENTRELEASE QA Contact: Release Test Team <release-test-team>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.0CC: dlehman, mbanas, pkotvan
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: anaconda-19.31.28-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 12:17:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
generated kickstart used for installation none

Description David Lehman 2013-10-08 19:36:26 UTC
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):
anaconda-19.31.22-1.el7

How reproducible:
Always

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 12:18:32 UTC
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 12:19:34 UTC
Created attachment 865486 [details]
generated kickstart used for installation

Comment 4 David Lehman 2014-02-22 00:05:17 UTC
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 11:58:41 UTC
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 18:28:07 UTC
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 11:17:40 UTC
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 14:34:32 UTC
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 11:01:24 UTC
With these everything went fine.

Comment 10 Ludek Smid 2014-06-13 12:17:33 UTC
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.