Bug 1052770

Summary: Booting from mmcblk0 does not work
Product: [Fedora] Fedora Reporter: Jason Montleon <jmontleo>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dwalsh, eparis, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, pmoore
Target Milestone: ---   
Target Release: ---   
Hardware: arm   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-14 20:34:11 EST Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
audit.log from affected system none

Description Jason Montleon 2014-01-13 21:46:29 EST
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

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:
module custom-boot 1.0;

require {
        type loadkeys_t;
        class memprotect mmap_zero;

#============= loadkeys_t ==============
allow loadkeys_t self:memprotect mmap_zero;

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.
Comment 1 Jason Montleon 2014-01-13 21:49:25 EST
Created attachment 849702 [details]
audit.log from affected system
Comment 2 Daniel Walsh 2014-01-14 16:50:10 EST
There is either a problem in the kernel or glibc that is causing mmap_zero issues.
Comment 3 Josh Boyer 2014-01-14 20:34:11 EST

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 ***
Comment 4 Jason Montleon 2014-01-15 02:09:59 EST
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'?
Comment 5 Eric Paris 2014-01-15 10:50:30 EST
I would guess that this is an ARM platform and that you have CONFIG_LSM_MMAP_MIN_ADDR set higher than 32k
Comment 6 Jason Montleon 2014-01-15 12:55:13 EST
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.