Red Hat Bugzilla – Bug 1469074
Kickstarted installation fails at setting root password (status=-6)
Last modified: 2017-07-14 04:11:28 EDT
Created attachment 1295781 [details] rsyslogd.log Description of problem: When trying to kickstart Fedora 26 with an automated kickstart the installer fails to set the root password (Creating users) and just reboots at that stage of the install process. The setup rpm which creates the /etc/shadow file has no permissions set, but this is the same as in Fedora 24 which is working for us, so unsure if this is related. Attached here are the errors.tgz file from the machine, the rsyslog logfile and the ipxe, kickstart files used for the install. Hostnames, domainnames and passwords have been obfuscated. File "/usr/lib64/python3.6/site-packages/pyanaconda/users.py", line 455, in setUserPassword#012 raise OSError("Unable to set password for new user: status=%s" % proc.returncode)#012#01 2OSError: Unable to set password for new user: status=-6 Version-Release number of selected component (if applicable): Fedora 26 pxe images from 2017-05-31 How reproducible: Always Steps to Reproduce: 1. pxeboot host with attached kickstart 2. wait for installer to fail 3. Actual results: Install is aborted Expected results: OS to be installed
Created attachment 1295782 [details] ipxe
Created attachment 1295783 [details] kickstart
Created attachment 1295784 [details] errors.tgz
Created attachment 1296101 [details] anaconda-tb from errors.tgz
For some reason the "chpasswd -R /mnt/sysimage/ -e root:<pass>" failed with return code -6. It would be nice to see what is happening there and provides us logs from /tmp/ when this error happens. To block installation from rebooting, you can add inst.nokill to the ipxe.
Created attachment 1296259 [details] log files from /tmp I've attached log files from /tmp. I don't see anything much more informative than was already in the previous attachments. We have the machine still booted in this state, so if there's anything else you can think of that would help diagnose, I'm happy to collect more outputs. Digging into this further myself, the most interesting syslog entries are: 09:01:42,313 NOTICE audit:USER_AVC pid=27486 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:initrc_t:s0 msg='avc: could not determine enforcing mode: No such file or directory#012 exe="/usr/sbin/chpasswd" sauid=0 hostname=? addr=? terminal=?' 09:01:42,313 NOTICE audit:ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 subj=system_u:system_r:initrc_t:s0 pid=27486 comm="chpasswd" exe="/usr/sbin/chpasswd" sig=6 res=1 09:01:42,321 INFO systemd:Started Process Core Dump (PID 27487/UID 0). 09:01:42,362 CRIT systemd-coredump:Process 27486 (chpasswd) of user 0 dumped core. Stack trace of thread 27486: 0 0x00007f00736a37bb raise (libc.so.6) 1 0x00007f00736a55d1 abort (libc.so.6) 2 0x00007f007369be9a __assert_fail_base (libc.so.6) 3 0x00007f007369bf12 __assert_fail (libc.so.6) 4 0x00007f0073ea303c avc_context_to_sid_raw (libselinux.so.1) 5 0x00007f0073ea3070 avc_context_to_sid (libselinux.so.1) 6 0x00007f0073ea6dad selinux_check_access (libselinux.so.1) 7 0x000055aad8265718 main (chpasswd) 8 0x00007f007368d5fe __libc_start_main (libc.so.6) 9 0x000055aad8265cca _start (chpasswd) This feels a bit like selinux is enabled in part of the stack but not the other (either in the install environment versus chrooted into the sytsem or vice-versa?). We've reused our previous kickstart template that turns off selinux for installing fedora 24 and centos systems. We'll re-test with selinux=0 and inst.selinux=0 instead of noselinux to see if this has any impact. [anaconda root@fed26machine / (chroot)]# cat /proc/cmdline ks=https://build.example.local/kickstart ramdisk_size=8216 pcie_aspm=off ipv6.disable=1 noselinux cmdline inst.sshd noverifyssl biosdevname=0 net.ifnames=0 inst.nokill [anaconda root@fed26machine / (chroot)]# getenforce Disabled [anaconda root@fed26machine /]# ls -al /selinux ls: cannot access '/selinux': No such file or director
Just a note: I use "rootpw --iscrypted ..." with an encrypted password (see http://pykickstart.readthedocs.io/en/latest/kickstart-docs.html#rootpw ) in the kickstart file. I don't use selinux option (because I want the default, SELinux enabled), nor do I disable firewall, and I don't use sshpw. Setting root password works for me for Fedora 26 x86_64 kickstart installation. /etc/shadow contains in the root line the encrypted password string.
Thanks for the feedback. It turns out this was indeed the way we were disabling selinux. Replacing "noselinux" kernel commandline option with "selinux=0 inst.selinux=0" allowed the installation to proceed. Root cause seems to have been having selinux enabled inside the installed system but not in the install environment kernel, was causing problems when libselinux tried to access the non-existent /selinux mount. Closing this one