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