Description of problem: I installed Fedora 20 Arm on a Cubox-i and was initially unable to boot. When the SD Card is inserted in the system it appears as /dev/mmcblk0 I had to boot with enforcing=0 and do the following to get it to where I could boot in enforcing mode. setsebool -P mmap_low_allowed on semodule -i custom-boot.pp Even after that I was unable to log in until I did the following. semodule -i custom-login.pp (The te files are in the additional info section below.) Version-Release number of selected component (if applicable): Fedora 20 selinux-policy-targeted-3.12.1-106.fc20.noarch How reproducible: Always. I have reinstalled a few times and verified the process to get the system booting. Steps to Reproduce: 1. xzcat Fedora-Minimal-armhfp-20-1-sda.raw.xz > /dev/<location-of-your-fedora-20-arm-media> 2. dd u-boot, to the sd card, insert in the Cubox-i, and plug it in Actual results: The boot process hangs while booting Expected results: The system boots normally Additional info: custom-boot.te: module custom-boot 1.0; require { type loadkeys_t; class memprotect mmap_zero; } #============= loadkeys_t ============== allow loadkeys_t self:memprotect mmap_zero; custom-login.te: module custom-login 1.0; require { type local_login_t; type getty_t; class memprotect mmap_zero; } #============= getty_t ============== #!!!! This avc is allowed in the current policy allow getty_t self:memprotect mmap_zero; #============= local_login_t ============== allow local_login_t self:memprotect mmap_zero; There were similar messages for firewalld_t and iptables_t as well. The audit.log from the system is attached.
Created attachment 849702 [details] audit.log from affected system
There is either a problem in the kernel or glibc that is causing mmap_zero issues.
kernel=3.13.0-0.rc7.git0.300.cubox_i4pro.fc20.armv7hl That's not a kernel provided by Fedora. I have no idea where you got it from or what is in it. *** This bug has been marked as a duplicate of bug 126342 ***
I built it using the 3.13-rc7 kernel patch with support for the Cubox-i I have seen pretty much the same thing on Pidora for the Raspberry Pi, which also boots from mmcblk0, but has the same problem of currently requiring a custom kernel. Is it possible this is something to do with the mmc driver, rather than just 'custom kernels'?
I would guess that this is an ARM platform and that you have CONFIG_LSM_MMAP_MIN_ADDR set higher than 32k
Eric, that is correct: CONFIG_LSM_MMAP_MIN_ADDR=65536 I will go ahead and rebuild it using a lower value. I understand how I ended up with this wrong value now, too. I did a rpmbuild -bp on the current kernel source and used the resulting .config for most of the defaults. Unfortunately, looking closer the correct .config isn't put in place until the build phase, so I actually used the wrong values for this and possibly other things. Thanks again for the pointer.