RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1112697 - RFE: allow to override default fs type for autopart
Summary: RFE: allow to override default fs type for autopart
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Lane
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 1129912
TreeView+ depends on / blocked
 
Reported: 2014-06-24 13:55 UTC by Jan Stancek
Modified: 2015-03-05 14:01 UTC (History)
9 users (show)

Fixed In Version: anaconda-19.31.105-1
Doc Type: Enhancement
Doc Text:
Feature: Add the ability to specify the filesystem type when using the kickstart autopart command. Reason: More flexibility in auto-partitioning installations. Result: The kickstart autopart command now supports the --fstype= option allowing the user to select any of the supported filesystems as the one to use when autopartition the system. Note that btrfs is not a fstype and is selected as before, with autopart --type=btrfs
Clone Of:
: 1129912 (view as bug list)
Environment:
Last Closed: 2015-03-05 14:01:34 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
storage.log --fstype=ext4, RHEL-7.1-20140828.n.0 (167.41 KB, text/plain)
2014-09-01 13:14 UTC, Jan Stancek 		no flags Details
Patch to fix fstype on /boot (227.80 KB, application/x-gzip)
2014-10-30 21:41 UTC, Brian Lane 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:0312 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2015-03-05 17:35:22 UTC

Description Jan Stancek 2014-06-24 13:55:20 UTC 
Description of problem:
Allow to override default file system (currently xfs) when using "autopart", for example:
  autopart --type=lvm --fstype=ext4

Our automated system for testing (Beaker) relies by default on "autopart", but there seems to be no option to override default file system (currently xfs).

It is possible to create custom/similar layout with combination of part/volgroup/logvol, but it requires hand-crafting kickstarts for specific system and it's not generic for all systems (e.g. if they have multiple drives) or architectures (e.g. /boot on s390x is logical volume, on x86_64 it's dedicated partition)

Version-Release number of selected component (if applicable):
anaconda-19.31.79-1.el7
Comment 3 Jan Stancek 2014-09-01 13:14:17 UTC 
Created attachment 933388 [details]
storage.log --fstype=ext4, RHEL-7.1-20140828.n.0

On RHEL-7.1-20140828.n.0 with --fstype=ext4 all volumes are ext4 except the /boot, which is still xfs:

zerombr
clearpart --all --initlabel
autopart --fstype=ext4

# df -hT
Filesystem                            Type      Size  Used Avail Use% Mounted on
/dev/mapper/rhel_dell--pet20--01-root ext4       50G  1.7G   45G   4% /
devtmpfs                              devtmpfs  1.9G     0  1.9G   0% /dev
tmpfs                                 tmpfs     1.9G     0  1.9G   0% /dev/shm
tmpfs                                 tmpfs     1.9G  8.5M  1.8G   1% /run
tmpfs                                 tmpfs     1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sda1                             xfs       494M  111M  383M  23% /boot
/dev/mapper/rhel_dell--pet20--01-home ext4      864G   77M  820G   1% /home

# yum info -q anaconda
Available Packages
Name        : anaconda
Arch        : x86_64
Version     : 19.31.85
Release     : 1.el7
...

# yum info -q pykickstart
Available Packages
Name        : pykickstart
Arch        : noarch
Version     : 1.99.43.12

Attached is storage.log from installation.
Comment 4 Brian Lane 2014-10-30 16:27:36 UTC 
This should be fixed, I'd expect all default partitions to be the same type.
Comment 5 Brian Lane 2014-10-30 21:41:28 UTC 
Created attachment 952356 [details]
Patch to fix fstype on /boot

Give this updates.img a try against anaconda-19.31.104-1
Comment 7 Jan Stancek 2014-11-03 12:48:32 UTC 
(In reply to bcl from comment #5)
> Created attachment 952356 [details]
> Patch to fix fstype on /boot
> 
> Give this updates.img a try against anaconda-19.31.104-1

autopart --fstype=ext4 -> OK, lvm volumes and /boot are ext4
autopart --fstype=xfs -> OK, lvm volumes and /boot are xfs
autopart --fstype=btrfs -> failed with "btrfs is not valid fstype, use --type=btrfs instead", I was expecting "--fstype=btrfs --type=lvm" to be supported, where --type=lvm is default partitioning scheme.
Comment 8 Brian Lane 2014-11-03 20:27:43 UTC 
(In reply to Jan Stancek from comment #7)
> (In reply to bcl from comment #5)
> > Created attachment 952356 [details]
> > Patch to fix fstype on /boot
> > 
> > Give this updates.img a try against anaconda-19.31.104-1
> 
> autopart --fstype=ext4 -> OK, lvm volumes and /boot are ext4
> autopart --fstype=xfs -> OK, lvm volumes and /boot are xfs
> autopart --fstype=btrfs -> failed with "btrfs is not valid fstype, use
> --type=btrfs instead", I was expecting "--fstype=btrfs --type=lvm" to be
> supported, where --type=lvm is default partitioning scheme.

That's expected. btrfs is both a filesystem and a volume manager, it was already supported using --type. You can't use lvm and btrfs at the same time.
Comment 9 Steve Whitehouse 2014-11-04 10:52:03 UTC 
RE: comment #8

It is possible to use btrfs with LVM rather than using its own internal volume management, and I think it is something that we should support. Maybe this is not the right place to raise that issue, but longer term we should allow for both set ups.
Comment 10 Brian Lane 2014-11-04 16:45:30 UTC 
(In reply to Steve Whitehouse from comment #9)
> RE: comment #8
> 
> It is possible to use btrfs with LVM rather than using its own internal
> volume management, and I think it is something that we should support. Maybe
> this is not the right place to raise that issue, but longer term we should
> allow for both set ups.

That's outside the scope of this bug. You would need to file RFEs with python-blivet to implement it and with Anaconda to support it with a good description of why you think it needs to be supported.
Comment 11 Alexander Todorov 2014-11-14 14:16:02 UTC 
Moving to VERIFIED, see comment #8. Please open RFEs for using btfs with LVM volume management as described in comment #10.
Comment 13 errata-xmlrpc 2015-03-05 14:01:34 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-0312.html
Note You need to log in before you can comment on or make changes to this bug.