Bug 1052770 - Booting from mmcblk0 does not work
Booting from mmcblk0 does not work
Status: CLOSED DUPLICATE of bug 126342
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
arm Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-13 21:46 EST by Jason Montleon
Modified: 2014-01-15 12:55 EST (History)
8 users (show)

See Also:
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: ---


Attachments (Terms of Use)
audit.log from affected system (65.56 KB, text/x-log)
2014-01-13 21:49 EST, Jason Montleon
no flags Details

  None (edit)
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
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.
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
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 ***
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.

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