Bug 1469074 - Kickstarted installation fails at setting root password (status=-6)
Summary: Kickstarted installation fails at setting root password (status=-6)
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 26
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-10 10:58 UTC by Ben Roberts
Modified: 2017-07-14 08:11 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-07-14 08:11:28 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
rsyslogd.log (852.15 KB, text/plain)
2017-07-10 10:58 UTC, Ben Roberts
no flags Details
ipxe (319 bytes, text/plain)
2017-07-10 10:58 UTC, Ben Roberts
no flags Details
kickstart (2.32 KB, text/plain)
2017-07-10 10:59 UTC, Ben Roberts
no flags Details
errors.tgz (33.58 KB, application/x-gzip)
2017-07-10 10:59 UTC, Ben Roberts
no flags Details
anaconda-tb from errors.tgz (332.58 KB, text/plain)
2017-07-11 07:08 UTC, Jiri Konecny
no flags Details
log files from /tmp (266.53 KB, application/x-gzip)
2017-07-11 13:41 UTC, Ben Roberts
no flags Details

Description Ben Roberts 2017-07-10 10:58:12 UTC
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

Comment 1 Ben Roberts 2017-07-10 10:58:48 UTC
Created attachment 1295782 [details]
ipxe

Comment 2 Ben Roberts 2017-07-10 10:59:11 UTC
Created attachment 1295783 [details]
kickstart

Comment 3 Ben Roberts 2017-07-10 10:59:29 UTC
Created attachment 1295784 [details]
errors.tgz

Comment 4 Jiri Konecny 2017-07-11 07:08:29 UTC
Created attachment 1296101 [details]
anaconda-tb from errors.tgz

Comment 5 Jiri Konecny 2017-07-11 07:20:41 UTC
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.

Comment 6 Ben Roberts 2017-07-11 13:41:47 UTC
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

Comment 7 Edgar Hoch 2017-07-11 20:16:18 UTC
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.

Comment 8 Ben Roberts 2017-07-14 08:11:28 UTC
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


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