trouble installing rhel7 as second OS on late 2013 macbook pro

Latest response

I'm attempting to install to a late 2013 13" Macbook Pro. Running "dmidecode -s system-product-name" prints out "MacBookPro11,1".

The installation image boots fine from DVD or from SD card.

Everything seems fine until I try to create partitions for the install. I'm trying to do an encrypted btrfs filesystem.

Automatic partitioning results in an error "failed to find a suitable stage1 device".

Manual partitioning (following instructions at http://fedoraproject.org/wiki/Common_F19_bugs#mac-uefi-esp) results in "you have not created a bootloader stage1 target device" and "You have not created a bootable partition.".

Has anyone else found a way to successfully install RHEL7 (or Fedora 19 for that matter) to this laptop?

Abrahm

Responses

I deleted all partitions on the disk.

Automatic partitioning appears to be error-free, but installation fails with "An unknown error has occurred". The stack trace ends in "FormatCreateError: (OSError(2, 'No such file or directory'), '/dev/sda1')".

I get the same "you have not created a bootloader stage1 target device" and "You have not created a bootable partition." errors when I select select "I want to review/modify my disk partitions before continuing" and "Click here to create them automatically".

This bug does not seem to be reproducible with OVMF EFI kvm vm.

The installer appears change its behavior if it thinks its running on a mac. There are errors about an HFS+ partition, but none exist and none should be created.

I found a workaround. This is what actually worked, but it is not ideal.

  1. Boot to installation media.
  2. Switch to vt2. (ctrl-alt-f2).
  3. Run parted. Delete all partitions.
  4. Edit /usr/lib/python2.7/site-packages/blivet/arch.py. Modify isMactel() function to always return False.
  5. Run restart-anaconda.

I will try to figure out how to install alongside OS X.

I reinstalled OS X Mavericks. Editing arch.py allows installation to get past the partitioning as described above.

Unfortunately anaconda decides that it should install hfsplus-tools which which causes installation to fail.

The spec file for anaconda file does not mark hfsplus-tools as a dependency if building for RHEL. Unfortunately, blivet expects the package to be there if you have any hfs+ partitions (I'm kinda guessing here).

To get past this, edit /usr/lib/python2.7/site-packages/blivet/formats/fs.py. Find the "class HFSPlus" definition. Comment out the _mkfs, _fsck, _packages, _formattable, and _check properties.

This allows package installation to finish.

Almost none of the tunables presented in powertop are marked "Good" out-of-the-box, even after changing the tuned policy to powersave. Fixing these has a significant impact on power consumption and should be addressed before using this computer unplugged.

Upon resume from sleep, there is some display corruption that isn't there in Fedora 20. Resume from hibernate did not work the first time I tried it, but it does work in Fedora 20.

Audio through the built-in speakers does not work out-of-the-box. There are published workarounds for this.

Many problems seem to be addressed by later kernels.

I installed kernel 3.13.0-0.rc6.git0.1.fc21.x86_64 from koji. The display corruption after sleep is fixed. Audio is fixed. Hibernate is fixed.

Wireless works with akmod-wl (and dependencies) from rpmfusion.

Keyboard backlight keys don't work, but they do in Fedora 20.

I added libata.force=noncq to the kernel command line to work around the SSD hangups. I also added hid_apple.fnmode=2.

In grub, the editing instructions don't say that F10 will work, but it does. Fedora 20 does include that statement. The control key does not work as expected inside grub.

Seems like you've been solving this one all by yourself, Abraham! Thanks for following up. Hopefully your suggestions will be useful for other users.

By the way, I notice you've used two separate logins to comment in this thread. Is there any particular reason for that? If you're having issues with a login or account I might be able to help out.

David, I have an account for work, and I have a personal account. I plan to use my personal account for forum use from now on. I am not having any account issues.

Thanks!

Update for RHEL 7 Beta on the macbookpro11,1:

Wireless requires akmod-wl version 6+ from rpmfusion-updates, not rpmfusion. It also frequently produces warning stack traces in the kernel log. I haven't tried to debug this yet.
I haven't figured out the keyboard backlight yet.
I haven't figured out how to fix the control key in grub yet.
I haven't tried to figure out how to get the webcam to work yet.
The laptop appears to need Fan-Control-Daemon to cool off properly during CPU/GPU intensive workloads.

The backlight flashes to max brightness right before the laptop goes to sleep. This is unpleasant and hopefully not damaging in any way.

For daily use, I've installed Fedora 19 for this laptop for better 3rd-party repo support and better wine support (for RSA SecurID, I have no luck with stoken). All of the above is still relavent, with the following addition: the base Fedora 19 3.9.5 kernel does not allow graphical boot, but graphical installation is required for manual partitioning.

To install, I used the RHEL 7 Beta installation image to boot as above, but specified a fedora 19 repo on the kernel command line (see anaconda parameters documentation). Editing /usr/lib/python2.7/site-packages/blivet/formats/fs.py is not required since hfsplus-tools is available for fedora 19. At first boot, add nomodeset in addition to libata.force=noncq and update all the packages. Graphical boot should work after updating. The RHEL7 redhat EFI directory prevented fedora from properly updating its grub setup. I removed the redhat directory for fedora to update its grub.cfg correctly.

(There also seems to be a hard-drive numbering issue when editing grub.cfg on the fly. I had to poke around a bit to get file-name autocomplete to work to choose a different kernel. Using the nomodeset argument worked much better to boot the system.)

With the 3.13.0-0.rc7.git0.1.fc21.x86_64 kernel and Fan-Control-Daemon, RHEL 7 Beta and Fedora 19 are both fairly well behaved. I've already spent too much time playing with this stuff, so I'll likely stick with Fedora 19 until RHEL 7 GA is out. Switching between F19 and RHEL7 is pretty seamless right now. I can switch between the two distros without any interruption to my workflow (git/vim/make/motif/xorg/c/c++/perf/gdb).

Also, the thunderbolt gigabit ethernet adapter works if plugged in at boot. Thunderbolt hotplug support isn't in the kernel yet. I haven't tested the patches from the lkml yet, but might give them a shot at some point (see http://lkml.indiana.edu/hypermail/linux/kernel/1311.3/03298.html).

Fan-Control-Daemon is not needed. I thought my fan(s?) weren't working correctly, but they appear to be working fine without that userspace daemon.

The display corruption after sleep still happens sometimes, but you can press alt-tab (or something else) to cause the screen to redraw.

The processor gets throttled under load without Fan-Control-Daemon. The processor doesn't throttle with Fan-Control-Daemon installed. The processor clock remains at 3.2Ghz under load as long as I've watched.

Sometimes, after resume from sleep, the backlight will remain off. You can turn it back on with the shortcut keys.

KDE often miscalculates remaining battery power. Since KDE uses this information to put the laptop to sleep or hibernate, this is quite disruptive. KDE will report that it is at 10% or less, but the capacities reported in /sys/.../BAT0/... show that the battery is almost full.

The touchpad is a joy to use inside OS X. It is not a joy to use in RHEL 7. The synaptic driver has basic support for clickpads, but the experience is a bit frustrating. In RHEL, I frequently experience accidental clicks, scrolls, failed clicks, and accidental mouse moves. I do not experience these things under OS X. The touchpad is relatively configurable, but not through any gui. The worst problem is that the synaptic driver does not support having one finger on the lower left click area while moving the mouse cursor. This is likely a limitation imposed by the older non-clickpad multitouch support within the driver. An unfortunate side effect of all this is plenty of accidental scrolling and I frequently accidentally zoom in or out of web pages when I try to open or close a tab inside Firefox using CTRL-W or CTRL-T.

The HiDPI display is also a source of frustration. Setting the dpi in the fonts section of the KDE application appearance settings panel helps quite a bit, although I find myself fiddling with it more than I should and it doesn't affect all applications. If you actually set the dpi to the real dpi of the display (230 or so), most applications become unusably large. Some applications do not pay any attention to these settings and appear quite small.

The dpi setting above only affects the surrounding UI of either Konqueror or Firefox. Web page rendering is not affected. Firefox has a setting to implement HiDPI support within itself. Unfortunately, this setting is cumulative with the dpi setting mentioned above. This means you can have correctly sized web pages, but the surrounding UI will be too large. I've resorted to zooming every web page as needed.

Thanks for your ongoing work documenting this setup, Abraham! Obviously with a beta and unsupported hardware some of these issues are to be expected, but this thread could be a helpful resource for other users trying something similar.

Thanks for the encouragement! I hope this helps someone!

The following three commands help with accidental scrolling/zooming:
synclient FingerHigh=90
synclient FingerLow=80
synclient PalmDetect=1

The battery capacity bug is fixed upstream in upower 0.9.22 (http://cgit.freedesktop.org/upower/commit/?id=07b95b8e27e7c488828c46a28df96f1c83b185c8). As a quick workaround, I installed upower 0.9.23 and glib2 rpms from Fedora 20.

The keyboard backlight control through KDE Daemon does not seem to work. However, the keyboard backlight upower dbus interface is working from the command line (e.g. dbus-send --print-reply=literal --type=method_call --system --dest=org.freedesktop.UPower /org/freedesktop/UPower/KbdBacklight org.freedesktop.UPower.KbdBacklight.SetBrightness int32:20). Also, the keyboard brightness keys are set correctly in KDE Daemon keybindings. Using dbus-monitor, I see KDE making the screen backlight dbus calls, but I don't see it making the dbus call to orf.freedesktop.UPower.KbdBacklight.SetBrightness. I'm pretty sure this worked out-of-the-box on Fedora 20, so I'll keep digging!

A bug in the KDE "Keyboard settings".

If you select keyboard model "Apple | MacBook/MacBook Pro" under the Hardware tab, then the Advanced tab options are ignored (specifically the ctrl:nocaps xkb option). Keyboard model "Generic | Generic 101-key PC" seems to work fine.

To deal with the high-resolution display, install the firefox plugin nosquint, set the default zoom to 140%. In KDE System Settings, set "Force fonts DPI" to 120 under Application Appearance -> Fonts.

Different UI elements could still use some tweaking, but this is good enough for now.

I'm new to KDE. I chose it because I read that it was better equipped for HiDPI displays. I will eventually try to move back to awesome wm.

Sometimes, under System Settings -> Power Management -> Energy Savings there is an setting for "Keyboard Backlight". If that setting appears, then the keyboard backlight will work. I see the setting sometimes, but the dbus command line always seems to work.

The MacBook is relatively nice after all the above work, but I'm abandoning this effort for now. I recommend sticking to OS X on the MacBook for now.

I plan to purchase the Dell XPS 13 Developer Edition.

For reference (in case anyone finds this discussion the way I did), this solution seems to work for the released version - just hit exactly the same problem on my macbook retina - which only has RH7 partitioning...

Thanks for the confirmation, Graham.

I'd like to say that after many months with the XPS 13 (9333) with the i7-4650U, I do not regret giving the MBP to my mother. (That does not mean that I don't still miss some things about the MBP.)

This might not be the appropriate thread to detail my experience with the XPS 13, but I will say a little. I am happily running RHEL 7. The recent RHEL kernel has good support for the CPU (older pstate driver didn't like my CPU, so performance was terrible). Backporting the HID-RMI driver completes the nice experience by making the touchpad more usable and giving me three-finger middle click. I hope that redhat backports the HID-RMI driver in the official kernel.

I'm glad my struggle with the MBP helped at least one person!

hello,
i recently tried installing rhel 6 along side my OS x, installation went fine but when i try loading the rhea using refind boot manager tool, it keeps saying no bootable image for the rhea 6. please what do i do

I'm sorry, but I don't think I can help you. I've never used refind. I've also never tried to use RHEL 6 on apple hardware.

You might like to try starting a new discussion topic for this issue.