Description of problem: initial-setup-graphical fails to run on ARM Version-Release number of selected component (if applicable): initial-setup-0.3.14-1.fc21.armv7hl How reproducible: everytime Steps to Reproduce: 1. Boot any rawhide ARM graphical image Actual results: Log in screen when system is booted. Expected results: initial-setup-graphical configuration Additional info: systemctl status initial-setup-graphical -l initial-setup-graphical.service - Initial Setup configuration program Loaded: loaded (/usr/lib/systemd/system/initial-setup-graphical.service; enabled) Active: failed (Result: exit-code) since Wed 1969-12-31 19:00:26 EST; 6min ago Process: 529 ExecStart=/bin/xinit /bin/firstboot-windowmanager /bin/initial-setup -- /bin/Xorg :9 -ac -nolisten tcp (code=exited, status=203/EXEC) Process: 443 ExecStartPre=/bin/plymouth quit (code=exited, status=0/SUCCESS) Main PID: 529 (code=exited, status=203/EXEC) CGroup: /system.slice/initial-setup-graphical.service Dec 31 19:00:26 localhost systemd[529]: Failed at step EXEC spawning /bin/xinit: Permission denied Dec 31 19:00:26 localhost systemd[1]: initial-setup-graphical.service: main process exited, code=exited, status=203/EXEC Dec 31 19:00:26 localhost systemd[1]: Failed to start Initial Setup configuration program. Dec 31 19:00:26 localhost systemd[1]: Unit initial-setup-graphical.service entered failed state.
Martin, a bit of fun ahead.
Hans, a bit of fun ahead.[1] [1] https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights#Dependencies
(In reply to Martin Kolman from comment #2) > Hans, a bit of fun ahead.[1] > > [1] https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights#Dependencies That has not landed yet, so whatever is going on here it is not caused by this.
Disabling SELinux on Rawhide nightlies allows initial-setup to run (both GUI and Text).
(In reply to Paul Whalen from comment #4) > Disabling SELinux on Rawhide nightlies allows initial-setup to run (both GUI > and Text). Well, that looks like a bug in the SELinux policy on ARM, so reassigning.
Could you attach AVC msgs from permissive mode? # setenforce 0 re-test # ausearch -m avc -ts recent
ausearch -m avc ---- time->Sat Jan 1 00:51:39 2000 type=UNKNOWN[1327] msg=audit(946687899.842:38): proctitle=2F7573722F7362696E2F4E6574776F726B4D616E61676572002D2D6E6F2D6461656D6F6E type=SYSCALL msg=audit(946687899.842:38): arch=40000028 syscall=125 per=800000 success=no exit=-13 a0=b63b8000 a1=98000 a2=5 a3=15 items=0 ppid=1 pid=581 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="NetworkManager" exe="/usr/sbin/NetworkManager" subj=system_u:system_r:NetworkManager_t:s0 key=(null) type=AVC msg=audit(946687899.842:38): avc: denied { execmod } for pid=581 comm="NetworkManager" path="/usr/lib/libgcrypt.so.20.0.1" dev="mmcblk0p3" ino=8251 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file ---- time->Sat Jan 1 00:54:45 2000 type=UNKNOWN[1327] msg=audit(946688085.830:33): proctitle=2F7573722F7362696E2F4E6574776F726B4D616E61676572002D2D6E6F2D6461656D6F6E type=SYSCALL msg=audit(946688085.830:33): arch=40000028 syscall=125 per=800000 success=yes exit=0 a0=b6332000 a1=98000 a2=5 a3=15 items=0 ppid=1 pid=569 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="NetworkManager" exe="/usr/sbin/NetworkManager" subj=system_u:system_r:NetworkManager_t:s0 key=(null) type=AVC msg=audit(946688085.830:33): avc: denied { execmod } for pid=569 comm="NetworkManager" path="/usr/lib/libgcrypt.so.20.0.1" dev="mmcblk0p3" ino=8251 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=file ---- time->Sat Jan 1 00:54:49 2000 type=UNKNOWN[1327] msg=audit(946688089.321:47): proctitle=2F7573722F6C69622F706F6C6B69742D312F706F6C6B697464002D2D6E6F2D6465627567 type=SYSCALL msg=audit(946688089.321:47): arch=40000028 syscall=5 per=800000 success=yes exit=4 a0=b63eb164 a1=20000 a2=0 a3=0 items=0 ppid=1 pid=599 auid=4294967295 uid=999 gid=999 euid=999 suid=999 fsuid=999 egid=999 sgid=999 fsgid=999 tty=(none) ses=4294967295 comm="polkitd" exe="/usr/lib/polkit-1/polkitd" subj=system_u:system_r:policykit_t:s0 key=(null) type=AVC msg=audit(946688089.321:47): avc: denied { open } for pid=599 comm="polkitd" path="/dev/urandom" dev="devtmpfs" ino=7111 scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file type=AVC msg=audit(946688089.321:47): avc: denied { read } for pid=599 comm="polkitd" name="urandom" dev="devtmpfs" ino=7111 scontext=system_u:system_r:policykit_t:s0 tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file Is what i get on an arm ssystem
execmod indicates /usr/lib/libgcrypt.so.20.0.1 is built incorrectly. Meaning it is not built with PIE and PIC? execmod is explained below http://www.akkadia.org/drepper/selinux-mem.html #============= policykit_t ============== #!!!! This avc is allowed in the current policy allow policykit_t urandom_device_t:chr_file { read open }; policykit_t is allowed to read urandom_device_t in Rawhide. rpm -q selinux-policy selinux-policy-3.13.1-46.fc21.noarch
I'll fix it.
Created attachment 897320 [details] disable non-PIC asm on armv7hl OK, I've fixed this. We need to disable camellia, cast5, and rijndael ARM asm right now, as those files are written in a non-PIC way. I'll look at fixing these upstream, but in the meantime we can just fallback to C.
Fixed and re-enabled in 1.6.1-4