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 1169034 - ValueError: new value non-existent xfs filesystem is not valid as a default fs type
Summary: ValueError: new value non-existent xfs filesystem is not valid as a default f...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: anaconda
Version: 7.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Anaconda Maintenance Team
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-11-29 06:43 UTC by CongLi
Modified: 2023-10-06 17:27 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-02 15:38:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
/tmp/* (740.00 KB, application/x-tar)
2014-11-29 06:43 UTC, CongLi
no flags Details
screenshot (36.11 KB, image/png)
2014-11-29 06:44 UTC, CongLi
no flags Details
/var/log (2.03 MB, application/x-tar)
2014-11-29 06:45 UTC, CongLi
no flags Details
/run/install/* (20.00 KB, application/x-tar)
2014-11-29 06:45 UTC, CongLi
no flags Details

Description CongLi 2014-11-29 06:43:28 UTC
Created attachment 962654 [details]
/tmp/*

Description of problem:
ValueError: new value non-existent xfs filesystem is not valid as a default fs type

anaconda 19.21.106-1 for Red Hat Enterprise Linux 7.1 (pre-released) started.
10:20:18 Not asking for VNC because of an automated install
10:20:18 Not asking for VNC because text mode was explicitly asked for kickstart
Traceback (most recent call last):
  File "/sbin/anaconda", line 1055, in <module>
    setupDisplay(anaconda, opts, addon_paths)
  File "/sbin/anaconda", line 673, in setupDisplay
    anaconda.initInterface(addon_paths)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/anaconda.py", line 205, in initInterface
    self.intf = TextUserInterface(self.storage, self.payload
  File "/usr/lib64/python2.7/site-packages/pyanaconda/anaconda.py", line 156, in storage
    self._storage.setDefaultFSType(self.instClass.defaultFS)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1905, in setDefaultFSType
    self._check_valid_fstype(newtype)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1880, in _check_valid_fstype
    raise ValueError("new value %s is not valid as a default fs type" % mnt)
ValueError: new value non-existent xfs filesystem is not valid as a default fs type

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

How reproducible:
2 / 2

Steps to Reproduce:
1. install a host with the ks.
2.
3.

Actual results:
installed failed with error:
ValueError: new value non-existent xfs filesystem is not valid as a default fs type

Expected results:
install successfully

Additional info:
1. host info:
processor       : 47
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 9
model name      : AMD Opteron(tm) Processor 6172
stepping        : 1
microcode       : 0x10000c4
cpu MHz         : 2099.934
cache size      : 512 KB
physical id     : 1
siblings        : 12
core id         : 5
cpu cores       : 12
apicid          : 27
initial apicid  : 27
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid amd_dcm pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate npt lbrv svm_lock nrip_save pausefilter
bogomips        : 4200.42
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate

Comment 1 CongLi 2014-11-29 06:44:30 UTC
Created attachment 962655 [details]
screenshot

Comment 2 CongLi 2014-11-29 06:45:15 UTC
Created attachment 962656 [details]
/var/log

Comment 3 CongLi 2014-11-29 06:45:49 UTC
Created attachment 962657 [details]
/run/install/*

Comment 5 David Shea 2014-12-01 14:47:53 UTC
Do the versions of the kernel and initrd you are using to boot match? Can you attach the installer log files from /tmp?

Comment 6 CongLi 2014-12-02 03:06:19 UTC
(In reply to David Shea from comment #5)
> Do the versions of the kernel and initrd you are using to boot match? Can
> you attach the installer log files from /tmp?

Hi David,

1. Yes, they match.
kernel : http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL-7.1-20141127.0/compose/Server/x86_64/os/images/pxeboot/vmlinuz                                                     
initrd : http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL-7.1-20141127.0/compose/Server/x86_64/os/images/pxeboot/initrd

2. I have already attached all files under /tmp/ in the description.
Could you check it again?

Thanks.

Comment 7 David Shea 2014-12-02 15:38:43 UTC
(In reply to CongLi from comment #6)
> (In reply to David Shea from comment #5)
> > Do the versions of the kernel and initrd you are using to boot match? Can
> > you attach the installer log files from /tmp?
> 
> Hi David,
> 
> 1. Yes, they match.

No, they don't. The vmlinuz file is 3.10.0-206.el7.x86_64. The initrd contains modules for 3.10.0-205.el7.x86_64.

> kernel :
> http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL-7.1-20141127.0/
> compose/Server/x86_64/os/images/pxeboot/vmlinuz                             
> 
> initrd :
> http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL-7.1-20141127.0/
> compose/Server/x86_64/os/images/pxeboot/initrd
> 
> 2. I have already attached all files under /tmp/ in the description.
> Could you check it again?
> 
> Thanks.

Comment 8 Jeroen van Aart 2017-12-30 00:37:30 UTC
I can confirm this is again a problem on rhel 7.4.

We have to use kernel images from the 7.2 dvd iso to work around it. So I can confirm that this is not a problem on 7.2.

When I download rhel-workstation-7.4-x86_64-dvd.iso and copy the files:

images/pxeboot/initrd.img
images/pxeboot/vmlinuz

To my pxeboot server and then try to do a network install the crash happens in almost the exact same way. In this case it happens when choosing a fully automated install. If using a manual install it will at least boot into a gui where you can choose the device, partition the drive(s) etc. I did not test further than that.

The key phrase being:

"ValueError: new value non-existent xfs filesystem is not valid as a default fs type"

It does not matter whether your install chooses xfs filesystem or not.

Comment 9 Vendula Poncova 2018-01-02 12:47:25 UTC
Please, see https://access.redhat.com/solutions/697913

You should use initrd.img, vmlinuz and the repository (or stage2) from the same media or location.


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