Bug 1169034

Summary: ValueError: new value non-existent xfs filesystem is not valid as a default fs type
Product: Red Hat Enterprise Linux 7 Reporter: CongLi <coli>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED NOTABUG QA Contact: Release Test Team <release-test-team-automation>
Severity: high Docs Contact:
Priority: high    
Version: 7.1CC: cheliu, coli, jeroen.vanaart, michen, risantam, scui, shuang, vponcova, yaxue
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-12-02 15:38:43 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:
Embargoed:
Attachments:
Description Flags
/tmp/*
none
screenshot
none
/var/log
none
/run/install/* none

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.