Bug 1052770 - Booting from mmcblk0 does not work
Summary: Booting from mmcblk0 does not work
Keywords:
Status: CLOSED DUPLICATE of bug 126342
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 20
Hardware: arm
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-14 02:46 UTC by Jason Montleon
Modified: 2014-01-15 17:55 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-15 01:34:11 UTC
Type: Bug
Embargoed:


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

Description Jason Montleon 2014-01-14 02:46:29 UTC
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-14 02:49:25 UTC
Created attachment 849702 [details]
audit.log from affected system

Comment 2 Daniel Walsh 2014-01-14 21:50:10 UTC
There is either a problem in the kernel or glibc that is causing mmap_zero issues.

Comment 3 Josh Boyer 2014-01-15 01:34:11 UTC
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 07:09:59 UTC
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 15:50:30 UTC
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 17:55:13 UTC
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.