Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

hungerfish · 2013-04-27 12:30:36

I've recently reinstalled archlinux on named machine, and I'm currently at a loss regarding the nvidia-blob.
I'm dualbooting osx and arch, have refind installed to the ESP partition, and boot linux using efistub.
Out of the box, using nouveau, this just works.
Sadly, nouveau doesn't handle the nvidia 320m chip all that well, so I have tearing
and most problematically my system gets really hot quite fast.

So I installed the blob, rebooted, only to find that X/the blob crashes on startup of X.
Hunting around, I now know, that officially, nvidia doesn't support 'pure efi mode' with their drivers. But that info is quite old.
I've also read contradictory claims of the blob working in similar circumstances...

What is the status of this as of 27.04.2013 ?? Anybody with the mbp 7.1 out there?

Now, I've had archlinux with the blob working on this machine before, at the time though I guess I was booting in bios or csm mode,
as I was using syslinux (which was started by refit/refind).

I can't use syslinux again, because I use xfs as my root fs, and syslinux doesn't support it.
Also, as far as I've been able to figure out, the use of syslinux requires an mbr.
Now DiskUtil from osx created a hybrid-mbr for me, because I used it to repartition my disk, but as neither osx nor linux require this,
I would most gladly revert this and have just the gpt on my disk.

So do I need an mbr for syslinux/grub-legacy/other options? for booting into bios/csm-mode?
I fail to understand how exactly this works with apple machines.
Are there other things I could try, kernel args maybe?

I just don't know what to try next, any help greatly appreciated.

Last edited by hungerfish (2015-05-02 11:33:31)

WonderWoofy · 2013-04-27 22:07:30

You should not need the hybrid MBR. Dealing with reverting this back to a protective MBR is pretty easy with gptfdisk. Instead of abandoning a bootloader you like, how about you instead just create a separate /boot partition.

I have no idea about the state of the nvidia binary blob and UEFI. Though from what I have seen on these forums, I cannot say that there are any others who have been wondering about this of late. So my guess would be that this is now working.

Just a side note here, refit is not the same thing as refind. So the use of "refit/refind" in a way that seems to indicate interchangabiliy is not technially correct.

hungerfish · 2013-04-28 16:21:23

I know that refit and refind are not the same thing. I named them both because I actually used them both, first refit, than later refind
Well its quite certain that the blob does not work in pure efi mode, at least for my chipset. I guess most people have moved on to newer apple models with different chipsets/problems...

I guess I could somehow repartition my disk, but I don't really want to do that. Especially when its still not clear to me, how exactly csm-mode is initialized.

JohnWinkerbelt · 2013-04-28 20:30:53

Me too, I also have a macbookpro 7.1, dual boot arch and MacOS, and maybe like you, x64, but unlike you, I use efi-grub to boot from refind (the one after refit) or the other way around, because the efi-grub mess around with the boot order, but nothing seriously and easy to fix thing. And yes, it's pure EFI and I don't really want to change to a semi Bios solution like before with Xubuntu.
With the recent updates of the kernel and nouveau (now as I'm writing this, it's 3.8.10) the system can work a little longer, but nothing special currently, because I also fighting/working on the nvidia(-beta) problem with efi and nvidia.

My grand problem is as followed, current Xorg, current nvidia(-beta), with and without Xorg.conf, the screen remains black. Pitch black.

What do I see? After I logged in to tty1, everything works just fine until I start startx (which does " exec startxfce4"). There are some outputs about loading the modules successfully it seems, but then the screen lights up like a camera shot flash and turns off. That's all I can see.

What can I do in this situation? The onyl thing I can do is to hit the power button, which shuts down the system. All the other keyboard commands doesn't work.

What do my Xorg.log says? Everything seems to load fine, with and without specific Xorg.conf. BUT it'll stop at a very strange spot. Sorry that I don't have a valid Xorg.log to offer, but just think the output like any other system start, until "enable 2D acceleration". The log just stops here, there are no entry after this last command.

How do I my "work around" looks like? I'm currently using nouveau. To prevent the high temperature, I turn up the fanspeed manually to 3000-4000 rpm. It works fine, but naturally not optimal. Me too am waiting for a working nvidia+EFI system OR a way to UNDERclock the GPU as low as possible with nouveau.

Somehow I could at least find out, what's NOT working, because, like it being said before, there are many contradictions of nvidia(-beta) (not) working with (u)efi.
Okay (all these doesn't work for me),
1. the "video=efifb" doesn't work, neither "video=efifb:macbook" nor all the variants of it.
2. disable the grub framebuffer also won't work (for me at least).
3. to think that nouveau would intervene into nvidia's working is also a possibility, but won't solve the basic problem, because even after removing EVERY trace of nouveau, nvidia won't work.
4. Turn down the resolution to 1280x800 manually in the Xorg.conf also won't work.
5. Turn on brightness is out of question, because the display doesn't seems to be on at all.

My finding are about, as I read a little into various nvidia dev posts, something like the current nvidia needs some bios specific "display finding functions/commands" to activate the currently using display.
But in other posts there are traces about nvidia working in UEFI, so it's strange.

My believe is that nvidia really doesn't find the right display, even if it claims to found the display. Maybe it's a not working co-op with the current xorg-server. But fact is (for my system), nvidia doesn't find the display and stops at the enabling of the 2D acceleration. It seems the driver just turns off the display and doesn't know to go on.

So yeah, I'm very clueless about what the real problem will be or already is.

Last edited by JohnWinkerbelt (2013-04-28 20:34:30)

hungerfish · 2013-04-29 00:39:42

So I'm not the only one
Yes, I'm also x86_64. As you, I've tried the current beta drivers (319.12-1), also stock nvidia, and nvidia-all. Makes no difference.
I've also played with video=efifb:off and a few other kernel args, but no luck.

But fact is (for my system), nvidia doesn't find the display and stops at the enabling of the 2D acceleration. It seems the driver just turns off the display and doesn't know to go on

Not quite. I can confirm that Xorg.0.log just ends with the line "enable 2D acceleration". But the driver doen't 'just' malfunction, it crashes and takes the xserver with it.
That's why the machine no longer responds to keyboard inputs (the xserver handles keyboard events, no xserver - no keyboard). Pressing the power button still works, because its not bound to the xserver and so can still promt systemd to shutdown the machine.

The following (or very similar) will show up in your log:

Apr 05 12:31:25 NattyNutter kernel: BUG: unable to handle kernel paging request at 00000000000026c0
Apr 05 12:31:25 NattyNutter kernel: IP: [<ffffffffa085ae76>] _nv006050rm+0x27c/0x3bd [nvidia]
Apr 05 12:31:25 NattyNutter kernel: PGD 13257d067 PUD 13970f067 PMD 0 
Apr 05 12:31:25 NattyNutter kernel: Oops: 0000 [#1] PREEMPT SMP 
Apr 05 12:31:25 NattyNutter kernel: Modules linked in: arc4 hid_apple snd_hda_codec_hdmi b43 nvidia(PO) usbhid snd_hda_codec_cirrus hid bcma bcm5974 coretem
Apr 05 12:31:25 NattyNutter kernel: CPU 0 
Apr 05 12:31:25 NattyNutter kernel: Pid: 2217, comm: X Tainted: P           O 3.8.5-1-ARCH #1 Apple Inc. MacBookPro7,1/Mac-F222BEC8
Apr 05 12:31:25 NattyNutter kernel: RIP: 0010:[<ffffffffa085ae76>]  [<ffffffffa085ae76>] _nv006050rm+0x27c/0x3bd [nvidia]
Apr 05 12:31:25 NattyNutter kernel: RSP: 0018:ffff88012cf099e8  EFLAGS: 00010282
Apr 05 12:31:25 NattyNutter kernel: RAX: 0000000000000000 RBX: ffff880138718808 RCX: 0000000000000000
Apr 05 12:31:25 NattyNutter kernel: RDX: 0000000000000000 RSI: 0000000000000015 RDI: 0000000000000000
Apr 05 12:31:25 NattyNutter kernel: RBP: ffff880138795f58 R08: 0000000000001469 R09: ffff880138795f3c
Apr 05 12:31:25 NattyNutter kernel: R10: ffff880138795f54 R11: ffff880138d3c008 R12: ffff880133cefd98
Apr 05 12:31:25 NattyNutter kernel: R13: ffff880138d3c008 R14: ffff880139708008 R15: 000000000000001b
Apr 05 12:31:25 NattyNutter kernel: FS:  00007fe879fea880(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
Apr 05 12:31:25 NattyNutter kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 05 12:31:25 NattyNutter kernel: CR2: 00000000000026c0 CR3: 0000000139b0b000 CR4: 00000000000407f0
Apr 05 12:31:25 NattyNutter kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 05 12:31:25 NattyNutter kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 05 12:31:25 NattyNutter kernel: Process X (pid: 2217, threadinfo ffff88012cf08000, task ffff88012dab8000)
Apr 05 12:31:25 NattyNutter kernel: Stack:
Apr 05 12:31:25 NattyNutter kernel:  ffff880139708008 0000000000000009 ffff880138d3c008 ffff880133cefd08
Apr 05 12:31:25 NattyNutter kernel:  000000000000001b ffffffffa085850a ffff880138d3c008 ffff880138d3c008
Apr 05 12:31:25 NattyNutter kernel:  0000000000000009 ffff880138d3c008 0000000000000000 ffffffffa0901b7b
Apr 05 12:31:25 NattyNutter kernel: Call Trace:
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa085850a>] ? _nv005973rm+0x5e/0x103 [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa0901b7b>] ? _nv003194rm+0x841a/0xb123 [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa08ffbf0>] ? _nv003194rm+0x648f/0xb123 [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa0603ff0>] ? _nv008115rm+0x25/0x40 [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa0abf270>] ? _nv012014rm+0x7d0/0x957 [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa0ac00fc>] ? _nv000780rm+0x483/0x6fc [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa0aba21b>] ? rm_init_adapter+0x73/0xf6 [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffffa0ad7c32>] ? nv_kern_open+0x192/0x800 [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8119158b>] ? chrdev_open+0x9b/0x1c0
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8118b093>] ? do_dentry_open+0x203/0x290
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff811914f0>] ? cdev_put+0x30/0x30
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8118b3d5>] ? finish_open+0x35/0x50
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8119b5ee>] ? do_last+0x31e/0xeb0
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff81198448>] ? link_path_walk+0x78/0x950
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff811979b4>] ? lookup_fast+0x44/0x2e0
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8119c23c>] ? path_openat+0xbc/0x530
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8119ca11>] ? do_filp_open+0x41/0xa0
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff811a9b79>] ? __alloc_fd+0xe9/0x140
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8118c504>] ? do_sys_open+0xf4/0x1e0
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff8118c611>] ? sys_open+0x21/0x30
Apr 05 12:31:25 NattyNutter kernel:  [<ffffffff814da9dd>] ? system_call_fastpath+0x1a/0x1f
Apr 05 12:31:25 NattyNutter kernel: Code: 01 00 00 29 41 ff 96 88 26 00 00 4c 8d a0 90 00 00 00 b9 00 00 00 00 ba 00 00 00 00 be 15 00 00 00 4c 89 ef 41 ff 55 20 48 89 c7 <ff> 90 c0 26 00 00 41 89 c7 48 8d 4d 04 ba 2a 00 00 ff 48 89 de 
Apr 05 12:31:25 NattyNutter kernel: RIP  [<ffffffffa085ae76>] _nv006050rm+0x27c/0x3bd [nvidia]
Apr 05 12:31:25 NattyNutter kernel:  RSP <ffff88012cf099e8>
Apr 05 12:31:25 NattyNutter kernel: CR2: 00000000000026c0
Apr 05 12:31:25 NattyNutter kernel: ---[ end trace c1d4bbf867990ddc ]---

You can look through your logs with journalctl

JohnWinkerbelt · 2013-04-29 17:09:45

Hmm, so it's that Xorg also crashes.. I didn't know.. ^^"
That's the cause of the strange cut off logging.. *acquired new knowledge*

Well, for some, who didn't know immediately (like me), you have to be root to see the entire journalctl entry..
Okay, it's (not really) shocking, but the journalctl is almost like yours (well except all the different adresses of course):

Apr 20 12:51:31 myPC kernel: BUG: unable to handle kernel paging request at 00000000000026c0
Apr 20 12:51:31 myPC kernel: IP: [<ffffffffa0ab8e76>] _nv006050rm+0x27c/0x3bd [nvidia]
Apr 20 12:51:31 myPC kernel: PGD 1392dd067 PUD 13972a067 PMD 0 
Apr 20 12:51:31 myPC kernel: Oops: 0000 [#1] PREEMPT SMP 
Apr 20 12:51:31 myPC kernel: Modules linked in: nvidia(PO) nls_cp437 vfat fat coretemp kvm_intel kvm snd_hda_codec_hdmi lib80211_crypt_tkip snd_hda_c
Apr 20 12:51:31 myPC kernel: CPU 0 
Apr 20 12:51:31 myPC kernel: Pid: 220, comm: X Tainted: P           O 3.8.7-1-ARCH #1 Apple Inc. MacBookPro7,1/Mac-F222BEC8
Apr 20 12:51:31 myPC kernel: RIP: 0010:[<ffffffffa0ab8e76>]  [<ffffffffa0ab8e76>] _nv006050rm+0x27c/0x3bd [nvidia]
Apr 20 12:51:31 myPC kernel: RSP: 0018:ffff880139265a58  EFLAGS: 00010282
Apr 20 12:51:31 myPC kernel: RAX: 0000000000000000 RBX: ffff880139a55408 RCX: 0000000000000000
Apr 20 12:51:31 myPC kernel: RDX: 0000000000000000 RSI: 0000000000000015 RDI: 0000000000000000
Apr 20 12:51:31 myPC kernel: RBP: ffff88013164df58 R08: 0000000000001469 R09: ffff88013164df3c
Apr 20 12:51:31 myPC kernel: R10: ffffffffa0d3e96d R11: ffff88013346c008 R12: ffff880139370298
Apr 20 12:51:31 myPC kernel: R13: ffff88013346c008 R14: ffff8801385b4008 R15: 000000000000001b
Apr 20 12:51:31 myPC kernel: FS:  00007fca25b5a880(0000) GS:ffff88013fc00000(0000) knlGS:0000000000000000
Apr 20 12:51:31 myPC kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Apr 20 12:51:31 myPC kernel: CR2: 00000000000026c0 CR3: 0000000138eaf000 CR4: 00000000000407f0
Apr 20 12:51:31 myPC kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Apr 20 12:51:31 myPC kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Apr 20 12:51:31 myPC kernel: Process X (pid: 220, threadinfo ffff880139264000, task ffff8801393e7540)
Apr 20 12:51:31 myPC kernel: Stack:
Apr 20 12:51:31 myPC kernel:  ffff8801385b4008 0000000000000009 ffff88013346c008 ffff880139370208
Apr 20 12:51:31 myPC kernel:  000000000000001b ffffffffa0ab650a ffff88013346c008 ffff88013346c008
Apr 20 12:51:31 myPC kernel:  0000000000000009 ffff88013346c008 0000000000000000 ffffffffa0b5fb7b
Apr 20 12:51:31 myPC kernel: Call Trace:
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0ab650a>] ? _nv005973rm+0x5e/0x103 [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0b5fb7b>] ? _nv003194rm+0x841a/0xb123 [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0b5dbf0>] ? _nv003194rm+0x648f/0xb123 [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0861ff0>] ? _nv008115rm+0x25/0x40 [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0d1d270>] ? _nv012014rm+0x7d0/0x957 [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0d1e0fc>] ? _nv000780rm+0x483/0x6fc [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0d1821b>] ? rm_init_adapter+0x73/0xf6 [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffffa0d35c32>] ? nv_kern_open+0x192/0x800 [nvidia]
Apr 20 12:51:31 myPC kernel:  [<ffffffff8118c382>] ? chrdev_open+0x92/0x1e0
Apr 20 12:51:31 myPC kernel:  [<ffffffff81186048>] ? do_dentry_open+0x188/0x2b0
Apr 20 12:51:31 myPC kernel:  [<ffffffff81192e21>] ? __inode_permission+0x41/0xb0
Apr 20 12:51:31 myPC kernel:  [<ffffffff8118c2f0>] ? cdev_put+0x30/0x30
Apr 20 12:51:31 myPC kernel:  [<ffffffff81186481>] ? finish_open+0x31/0x40
Apr 20 12:51:31 myPC kernel:  [<ffffffff811955a3>] ? do_last+0x363/0xe70
Apr 20 12:51:31 myPC kernel:  [<ffffffff81192724>] ? lookup_fast+0x44/0x2c0
Apr 20 12:51:31 myPC kernel:  [<ffffffff81196162>] ? path_openat+0xb2/0x520
Apr 20 12:51:31 myPC kernel:  [<ffffffff8121e1a8>] ? security_capable+0x18/0x20
Apr 20 12:51:31 myPC kernel:  [<ffffffff81062f69>] ? ns_capable+0x29/0x50
Apr 20 12:51:31 myPC kernel:  [<ffffffff81197478>] ? do_filp_open+0x38/0x80
Apr 20 12:51:31 myPC kernel:  [<ffffffff811a3fcf>] ? __alloc_fd+0xaf/0x140
Apr 20 12:51:31 myPC kernel:  [<ffffffff81187529>] ? do_sys_open+0xe9/0x1c0
Apr 20 12:51:31 myPC kernel:  [<ffffffff81187621>] ? sys_open+0x21/0x30
Apr 20 12:51:31 myPC kernel:  [<ffffffff814c72dd>] ? system_call_fastpath+0x1a/0x1f
Apr 20 12:51:31 myPC kernel: Code: 01 00 00 29 41 ff 96 88 26 00 00 4c 8d a0 90 00 00 00 b9 00 00 00 00 ba 00 00 00 00 be 15 00 00 00 4c 89 ef 41 ff 55 
Apr 20 12:51:31 myPC kernel: RIP  [<ffffffffa0ab8e76>] _nv006050rm+0x27c/0x3bd [nvidia]
Apr 20 12:51:31 myPC kernel:  RSP <ffff880139265a58>
Apr 20 12:51:31 myPC kernel: CR2: 00000000000026c0

What can I say, I assume, that somewhere in the vast code of the nvidia driver, there is an evil pointer fault maybe?
Well, I have to clean up the millions journalctl entries, before I can do the experimenting again, but with this, I'm afraid that it won't work unless this BUG will be fixed.

srs5694 · 2013-04-29 17:14:27

Have you tried the older nv driver? On some of my systems, nv has worked better than either nouveau or the proprietary nVidia driver in the past; however, I haven't kept up with the latest developments on this score.

hungerfish · 2013-04-30 09:40:14

Have you tried the older nv driver?

I completely forgot it existed. Sadly it wont work. I start up with both nouveau and nvidia blacklisted, but it (nv) complains in Xorg.0.log with

ignoring device 0x10de08a0 at 04@00:00:0

Although it lists all supported cards/chipsets and, geforce 320m is clearly among them.
Maybe I'm setting it up wrong though, I couldn't find any info in the wiki.

I'm afraid that it won't work unless this BUG will be fixed.

Sadly, I concur. The only other option is to boot the machine in csm-mode. But as stated before, I'm not to clear on how to achieve that.
Do I really need to have a hybrid mbr, so that I can install a 'legacy' bootloader like grub-legacy or syslinux???

srs5694 · 2013-04-30 16:28:11

hungerfish wrote:

Have you tried the older nv driver?
I completely forgot it existed. Sadly it wont work. I start up with both nouveau and nvidia blacklisted, but it (nv) complains in Xorg.0.log with
ignoring device 0x10de08a0 at 04@00:00:0

There might be a comment before or after that one that describes why it's being ignored. If so, you might be able to find a workaround based on the information provided.

The only other option is to boot the machine in csm-mode. But as stated before, I'm not to clear on how to achieve that.
Do I really need to have a hybrid mbr, so that I can install a 'legacy' bootloader like grub-legacy or syslinux???

My understanding is that Macs require a hybrid MBR with at least one partition marked as active in order to boot in BIOS/CSM/legacy mode. You'll then need to install a BIOS-mode boot loader -- GRUB Legacy, GRUB 2 (BIOS version), SYSLINUX, or whatever. If you're using rEFInd, you should then either comment out the "scanfor" line or ensure that "hdbios" is listed on that line so that rEFInd can detect your BIOS-mode boot loader.

hungerfish · 2013-04-30 16:52:05

My understanding is that Macs require a hybrid MBR with at least one partition marked as active in order to boot in BIOS/CSM/legacy mode. You'll then need to install a BIOS-mode boot loader -- GRUB Legacy, GRUB 2 (BIOS version), SYSLINUX, or whatever. If you're using rEFInd, you should then either comment out the "scanfor" line or ensure that "hdbios" is listed on that line so that rEFInd can detect your BIOS-mode boot loader.

I've posted to the nvidia forums, maybe I'll get an answer to when efi-mode will finally be supported by them. If not, I'll have to attempt what you suggest.
The comment was along the lines, 'unsopported chipset', sorry, forgot to mention that. Anyway, as I mentioned, geforece 320m is listed as supported by the driver in the very same log file. Maybe this is also down to efi-mode being unsupported. As I don't understand 'why' the driver relies on bios functionality, so I couldn't say if this is also the case with nv...

JohnWinkerbelt · 2013-04-30 19:27:58

Well, I just know about nv, but to be truth, I only want the proprietary nvidia to run, because it has at least a stable clocking, so that I can downclock it without worry AND, the killer feature for me, vdpau. It allows me to watch videos efficiently through the GPU.

I'm thankful for the suggestion with nv, but it has a meaning for me (maybe for us too), that I want nvidia to run. All in all, it consumes the least power of all the driver.

Now about the CSM-mode it were mentioned several times. Not that I know, that this CSM-mode is the same as the BIOS compatibility mode, that is what I tried before I made Arch to an EFI pure system. Well, I failed to install GRUB into the "semi"-MBR section because of several errors, so I decided to stay with EFI.
Unfortunately, it's officially mentioned in the forum of nvidia dev, that EFI isn't supported. But this was a post from 2012..
https://devtalk.nvidia.com/default/topi … -support-/

By the way, this mode is standard in (X/L/Ed/whatever)Ubuntu, if you install it per CD. This is a sure-fire way to let most of the driver works with Linux. But the downside is, as you know, that you can only have four primary partitions (just like the BIOS). But if this is the only downside.. awww duh.. there are too many benefits to make it in this CSM-mode..

It was a fight to install Arch at all, because most of the wiki entries are somehow old (mostly because of systemd and co.) and therefore mostly not reliable.

Well, I think the CSM-mode will be unavoidable I afraid (and the rereading of the GRUB2 wiki too..).

Last edited by JohnWinkerbelt (2013-04-30 19:33:08)

srs5694 · 2013-04-30 21:58:11

JohnWinkerbelt wrote:

Now about the CSM-mode it were mentioned several times. Not that I know, that this CSM-mode is the same as the BIOS compatibility mode

I'm not sure what you mean by this, but "CSM mode," "BIOS mode," "BIOS compatibility mode," "legacy mode," and several other variants on these phrases all refer to the same thing, at least on a computer with EFI firmware.

Incidentally, on some computers it's possible to enable CSM/BIOS/legacy mode but not use it to boot Linux. This seems to affect video card support, at least in the EFI, and perhaps in Linux. For instance, on one of my systems with an ASUS P8H77-I motherboard, if I plug in an older nVidia video card, I must enable CSM/BIOS/legacy support in the firmware to use that video card. On this system, I ran the nVidia proprietary drivers in Linux without problems, but I don't know if that success was related to the firmware-level CSM support or video card initialization in CSM/BIOS/legacy mode. I don't know if attempting something similar on a Mac would help. If so, I'd suggest creating a hybrid MBR and setting at least one partition bootable, then booting in EFI mode. This should cause the Mac to initialize its CSM/BIOS support, but I don't know if that would be sufficient to get the Linux proprietary nVidia driver working.

Well, I failed to install GRUB into the "semi"-MBR section because of several errors, so I decided to stay with EFI.

I suspect you mean that GRUB failed to install to the MBR. With GPT partitioning, there is an MBR; it's just called the "protective MBR," which means that it holds a single type-0xEE partition that spans the entire disk. This protective partition isn't a "real" partition, though; its purpose, and the purpose of the protective MBR more generally, is to keep GPT-unaware utilities from messing with the disk.

The MBR, though, holds more than a partition table; it also holds boot code for BIOS-based computers. If you boot Linux in BIOS mode from a GPT disk, you'll need a GPT-aware boot loader in this MBR boot code area. Most BIOS boot loaders for Linux have GPT-aware code that can go in this space.

By the way, this mode is standard in (X/L/Ed/whatever)Ubuntu, if you install it per CD. This is a sure-fire way to let most of the driver works with Linux. But the downside is, as you know, that you can only have four primary partitions (just like the BIOS). But if this is the only downside.. awww duh.. there are too many benefits to make it in this CSM-mode..

If you're dual-booting Linux and OS X on a Mac, the hard disk will almost certainly use GPT, albeit with a hybrid MBR if you're booting Linux in BIOS/CSM/legacy mode (and maybe even if not). Neither OS X nor Linux uses the MBR side on a hybrid MBR, though; for such a configuration, the hybrid MBR is necessary only to activate the CSM/BIOS support in the firmware. In any event, GPT can have up to 128 partitions by default, with no primary/logical distinction. The fact that you can have just three of these duplicated in the MBR is irrelevant to both OSes. (The MBR holds four partitions, but in a hybrid MBR, one of these is the 0xEE protective partition, which is not useful for holding data.)

JohnWinkerbelt · 2013-05-01 07:19:45

This GPT and CMS aka BIOS compatible mode is still somehow mysterious for me, because it came across me since I changed from Ubuntu to Arch not long ago. I'm sorry for my little knowledge about GPT and BIOS, and especially the CSM-mode. I guess, I'll work in this a little bit more..

I can imagine that on some (U)EFI computers, you can/must enable CSM/BIOS/legacy mode for installing anything to this very mode and not into (U)EFI-mode, I guess. But for Macbooks with their unique firmware, they (fortunately) have this enabled by default, hopefully I didn't got this wrong.

srs5694 wrote:

This seems to affect video card support, at least in the EFI, and perhaps in Linux. For instance, on one of my systems with an ASUS P8H77-I motherboard, if I plug in an older nVidia video card, I must enable CSM/BIOS/legacy support in the firmware to use that video card.

This somehow make this case really pointing out the incompatibility of nvidia with (U)EFI, well no surprise I guess.

By the way, this is the problem I came across not only one time if I do this:

# modprobe dm-mod
# grub-install --recheck --debug /dev/sda

leads for me to:

/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. 
                        However, blocklists are UNRELIABLE and their use is discouraged.

I'm sure this is because I don't know how to setup the partition properly. (the wiki's are well written, but old and nowadays not fully true anymore..)

Well, this was my attempt for an alternative way besides the pure EFI configuration to run the nvidia driver properly. (Yes, it's still a fight to make the nvidia driver working!)

srs5694 · 2013-05-01 16:32:12

JohnWinkerbelt wrote:

I can imagine that on some (U)EFI computers, you can/must enable CSM/BIOS/legacy mode for installing anything to this very mode and not into (U)EFI-mode, I guess. But for Macbooks with their unique firmware, they (fortunately) have this enabled by default

Well, yes and no. It's my understanding that Apple's firmware leaves CSM/BIOS support disabled by default; it will enable it only if the hard disk contains a hybrid MBR (or pure MBR) with at least one active partition. Thus, you can't boot Linux in BIOS mode on a Mac with a pure-GPT disk, although you can do this on most computers with plain BIOSes (that is, firmware without EFI support).

# modprobe dm-mod
# grub-install --recheck --debug /dev/sda

leads for me to:

/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. 
                        However, blocklists are UNRELIABLE and their use is discouraged.

I'm not exactly a GRUB expert -- my thinking on GRUB started turning negative two or three years ago, and I've stopped trying to remember every little quirk it has. I found it easier to continue development of rEFIt as rEFInd!

That said, if you're attemping to install the BIOS-mode GRUB on a GPT disk, it works best if you create a BIOS Boot Partition. The second warning you describe almost certainly relates to an omission of this partition. I'm not sure about the first one; it sounds like GRUB doesn't recognize the disk's partition table. This could be a sign of a damaged partition table, or it could be that GRUB is flaking out because of a hybrid MBR or some other harmless quirk. Running "gdisk" on the disk and using its "v" ("verify") option might tell you if there are real problems with the disk.

JohnWinkerbelt · 2013-05-01 19:03:13

First:

srs5694 wrote:

I found it easier to continue development of rEFIt as rEFInd!

Do you mean rEFit is still better than rEFInd or the other way around?

And it seems that it would be a good time to ask, what are the benefits of EFI-mode instead of the CSM-mode? Or why could CSM-mode be better than EFI-mode? I've searched several pages, but it wasn't that clear to me somehow.
With the CSM-mode, this nvidia BUG should be theoretically no problem at all. (Still, it wouldn't solve the pure EFI + nvidia problem obviously).

I'll maybe try to reinstall Arch into the CSM-mode and if it runs smooth, then I'll post a detailed way to achieve this point.

Update,
maybe not, CSM-mode makes me sad and it doesn't work (there are almost no documentation for this and I'm too dumb in this matter), will stay with pure EFI, futher down in this topic, I explain why.

Update 2
See below for more information, CSM-mode works fine now.

Last edited by JohnWinkerbelt (2013-05-09 11:17:20)

srs5694 · 2013-05-02 00:14:23

JohnWinkerbelt wrote:

First:
srs5694 wrote:
I found it easier to continue development of rEFIt as rEFInd!
Do you mean rEFit is still better than rEFInd or the other way around?

rEFInd contains numerous bug fixes, new features, and improvements compared to rEFInd. See the rEFInd features page for details. OTOH, rEFIt has a somewhat simpler installation procedure on Macs, and many Mac users continue to use it because it's adequate for their needs, or perhaps because they're following old documentation that points to rEFIt rather than to rEFInd.

And it seems that it would be a good time to ask, what are the benefits of EFI-mode instead of the CSM-mode? Or why could CSM-mode be better than EFI-mode?

THEORETICALLY, EFI-mode booting is superior because it can be a bit faster and because it gives you access to EFI runtime services. The latter let you set boot-time options like what boot loader to use, to store data in the firmware for later retrieval (the kernel can use this to store data about a kernel panic, for instance), and for other reasons. At the moment, runtime services offer few real benefits to users, but this could change in time.

IN PRACTICE, BIOS/CSM-mode booting can sometimes work better because on some computers it can result in hardware being initialized in ways that drivers expect, whereas EFI-mode booting may not do this, resulting in drivers that don't work. This thread is about one example of this type of problem.

hungerfish · 2013-05-02 09:31:18

It's my understanding that Apple's firmware leaves CSM/BIOS support disabled by default; it will enable it only if the hard disk contains a hybrid MBR (or pure MBR) with at least one active partition.

I've checked, and I currently have a hybrid mbr on my disk. I guess it got created by the apple partitioner tool which I initially used to resize my singe mac partition, making room for more.
I then used gdisk to have the hybrid mbr correctly map my 3 gpt partitons, resulting in a mbr with 4 entries, the first being tiny and mapping the area wich is deemed 'unusable' by gpt.
Still, my the machine is not booting in csm mode, which from my understanding should actually be expected, because I'm not booting via a legacy bootloader/manager, but via efistub from refind.
If so, does this mean I need both hybrid-mbr + legacy bootloader?

srs5694 · 2013-05-02 16:13:08

hungerfish wrote:

I've checked, and I currently have a hybrid mbr on my disk. I guess it got created by the apple partitioner tool which I initially used to resize my singe mac partition, making room for more.
I then used gdisk to have the hybrid mbr correctly map my 3 gpt partitons, resulting in a mbr with 4 entries, the first being tiny and mapping the area wich is deemed 'unusable' by gpt.
Still, my the machine is not booting in csm mode, which from my understanding should actually be expected, because I'm not booting via a legacy bootloader/manager, but via efistub from refind.
If so, does this mean I need both hybrid-mbr + legacy bootloader?

If you're dual-booting OS X and Linux on a Mac, and if Linux is booting in EFI mode, then no, you don't need a hybrid MBR. In fact, because hybrid MBRs are flaky and dangerous, I recommend replacing the hybrid MBR with a conventional protective MBR in that case.

OTOH, since the problem under discussion in this thread is that the nVidia proprietary drivers aren't working on some Macs booted in EFI mode, reconfiguring to boot Linux in BIOS/CSM/legacy mode makes sense, that that does require a hybrid MBR, AFAIK.

JohnWinkerbelt · 2013-05-02 20:00:48

Even if the chances are small, a new nvidia-beta (319.17) was recently (02. May 2013) released as Phoronix reports.
Right after this version get's into the Arch repository (of course the AUR repos), I'll try this out.

I think, I'll stay with EFI, because it's more secure and simpler and not dangerous like CSM, especially because for this CSM there are no standards, so it can easily break or even do ugly stuffs on the partitions, well, the introduction text of this page about gdisk and hybrid mbr just scared me too much.
It really hard to make a hybrid mbr, where grub can be installed on, just tried it and failed on it again. With pure EFI, MacOS won't complain about anything at least and the GPT partition table stays clean. It's also much easier to it on this way.

If you installed Arch after MacOS and refit (the old one) or refind (the new one), then just reinstall refit/refind to set the boot order before the grub-efi again. If someone has problems with the boot order.

I would be really happy, if nvidia is finally be able to make this working. This may make the CSM-mode way obsolet.

By the way srs5694, I forgot to ask, but what bootloader do you use instead of grub then?

Last edited by JohnWinkerbelt (2013-05-02 20:16:23)

srs5694 · 2013-05-02 22:02:44

JohnWinkerbelt wrote:

By the way srs5694, I forgot to ask, but what bootloader do you use instead of grub then?

I maintain rEFInd, so naturally, I use it (with the EFI stub loader) on most of my systems. I've got installs of others on various computers, but I seldom use them -- I sometimes try one out when I need to do so for my writing or to help debug a problem.

JohnWinkerbelt · 2013-05-04 22:07:42

Even with the newest nvidia-beta 319.17, still no luck..
I scanned through the journal, Xorg and dmesg, the cause are always a bug or two, but I don't really know, which it's really related to nvidia

with -- dmesg | egrep -i "efi|nvidia" --, I get

...
[ 0.000000] efi: mem00: type=7, attr=0xf, range=[0x0000000000000000-0x000000000008f000) (0MB)
...
and so on
...
[ 0.468087] efifb: dmi detected MacBookPro7,1 - framebuffer at 0xc0010000 (1280x800, stride 8192)
[ 0.468118] efifb: probing for efifb
[ 0.469116] efifb: framebuffer at 0xc0010000, mapped to 0xffffc90001180000, using 6400k, total 6400k
[ 0.469118] efifb: mode is 1280x800x32, linelength=8192, pages=1
[ 0.469119] efifb: scrolling: redraw
[ 0.469121] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 0.477052] fb0: EFI VGA frame buffer device
[ 1.511224] tsc: Refined TSC clocksource calibration: 2389.242 MHz
[ 1.512536] EFI Variables Facility v0.08 2004-May-17
[ 1.935721] ehci-pci 0000:00:04.1: disable ppcd for nvidia mcp89
[ 1.943713] ehci-pci 0000:00:06.1: disable ppcd for nvidia mcp89
[ 7.181950] [Firmware Bug]: ACPI(IGPU) defines _DOD but not _DOS
[ 8.244546] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver
[ 10.673449] parse error at position 4 in video mode 'efifb'
[ 10.673451] parse error at position 4 in video mode 'efifb'
[ 10.903487] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:08.0/sound/card0/input10
...

with journalctl, it's the same story like in the beginning,

...
Mai 04 23:14:48 myPC kernel: BUG: unable to handle kernel paging request at 0000000000002788
Mai 04 23:14:48 myPC kernel: IP: [<ffffffffa0aae5b6>] _nv006328rm+0x27c/0x3bd [nvidia]
...

the "firmware bug" and the other bugs are also listed here, but some may be unrelated to the "nvidia black screen" problem, because it also listed, even if I successfully running nouveau.

By the way, I tried to append "acpi=off" to the kernel command and got a kernel panic, somehow funny, but not helpful at all.
Didn't try "nomodeset", but would expect the same black screen like normal.

I was curious and looked over there about the status of efi at nvidia dev, and found the post of nE0sIghT interesting, because he stated that his system runs smooth, but it's not a MacbookPro, because the EFI version is somewhat different. Maybe even the version of EFI is important, because, as I could gather the information, the EFI of apple is old. Maybe it's even a little different from the UEFI in PCs?
But he's using the kernel 3.9, which catched my interest. Maybe it'll work with the newest kernel, which can be found in the testing repository of arch.

Yeah, I don't want to spam too much information, but well, all I can do is to search for the real problem in this mess and inform you.

Maybe it's unrelated to this topic again, but what exactly is different in efi-mode and cms-mode? What deamon or modules makes the differents in runtime? Are there some significant process or hints in the system, which let me know "ah, I am currently running.. uh.. csm-mode?" ?

And the last question, which is related to this is, "what exactly can nvidia do in csm/bios-mode, which it can't do in efi-mode"? I know, the last question is unfair, because only the nvidia developer would know this.. and I don't even know, if they are allowed to reveal this..

Last edited by JohnWinkerbelt (2013-05-05 07:43:06)

hungerfish · 2013-05-05 11:51:16

because the EFI version is somewhat different. Maybe even the version of EFI is important, because, as I could gather the information, the EFI of apple is old. Maybe it's even a little different from the UEFI in PCs?

I'm also starting to believe that is is probably the cause of the problem. Its also a clue as to why one finds so much conflicting information on this topic, ie. that it works for some and not for others.
If the fault lies with apple's firmware, we're screwed, at least with this 'old' model.

what exactly is different in efi-mode and cms-mode?

Well, generally speaking not so much. I guess the one big difference is the disk mode. With efi, ahci is used, but with csm, as far as I can tell, ide-mode gets forced, which 'could' result in slower I/O, but I have no numbers to back that up.
Regarding the nvidia driver, I guess it relies on some funtion or lookup table or something which it fails to get from efi, but I'm just guessing.

My solution as of today:
I give up
I'm now using the ESP as a separate boot partition (thus sidestepping the xfs support problem with syslinux) and can now select to either boot via efistub or syslinux from my refind menu.
Choosing the latter, boots the system in csm-mode, and enables the blob to work. The nice thing about this solution is, I can in a way 'triple boot', linux-legacy, linux-csm,osx

Sidenote: At first this did not work, with the kernel complaining about not being able to find my root partition. The solution was to rebuild my initramfs.img, making sure I it included the module for libata.
Ironically, I knew csm-mode was working now, because of this error...

Some final questions:
my gpt table contains 3 partitons, sda1-3 , sda1 is the esp, which was marked bootable through the syslinux installer.
the (hybrid)mbr contains 4 partitons, 2-4 being my actual partitons. 3 is marked bootable there, that is my osx partitons.

Why is this? Also, how could I change the bootable flag in the mbr? By just using a gpt-unaware tool?
Is it worth a try to get rid of this whole hybrid-mbr thing, and see if my setup still works. Because as it stands, my bootloaders are all gpt aware and all ignore the mbr.
turns out that this is not correct. syslinux relies on the hybrid mbr for booting my setup.
Of course this in theory should mean that csm-mode shouldn't work, but I guess this would be the way to finally find out..
How would I get rid of the hybrid mbr?
By just creating a new protective mbr spanning the entire disk with gdisk?

Last edited by hungerfish (2013-05-11 11:07:14)

srs5694 · 2013-05-05 12:41:32

JohnWinkerbelt wrote:

as I could gather the information, the EFI of apple is old. Maybe it's even a little different from the UEFI in PCs?

Yes. Apple uses a heavily-modified EFI 1.x in their systems, whereas the vast majority of EFI-based PCs use EFI 2.x (aka UEFI). There are some significant differences between EFI 1.x and 2.x, and Apple throws in non-standard stuff of its own to further complicate things. Whether this has anything to do with the nVidia problems under discussion in this thread I do not know.

Maybe it's unrelated to this topic again, but what exactly is different in efi-mode and cms-mode? What deamon or modules makes the differents in runtime?

I don't know of anything in userland that's different, except for follow-on effects from lower levels. In the kernel, there's low-level stuff related to memory management and firmware interfaces that are different, but I don't know the details of that. The biggest differences come before the kernel takes control, though; in EFI mode, the boot process follows the EFI model, with a boot loader stored as a file on the ESP (or an OS X partition, on Macs) and written in 32- or 64-bit mode, etc. In BIOS/CSM mode, the boot process follows the BIOS model, with a 16-bit boot loader stored on the hard disk's MBR and/or the boot partition's PBR. Furthermore, when the CSM takes control, it does whatever hardware initialization is included in the CSM. This could well be the source of the problem, since the CSM is likely to include nVidia-specific initialization code that might not be done in the EFI boot path. This in turn could have follow-on effects all the way down the line to the nVidia driver. Unfortunately, this knowledge doesn't do you any good, since both the firmware and the nVidia driver are binary blobs -- you couldn't change anything about either of them, or even study the code to figure out how to work around the problem (say, with an EFI driver to do the CSM-style initialization in EFI mode).

Are there some significant process or hints in the system, which let me know "ah, I am currently running.. uh.. csm-mode?" ?

Look for a directory called /sys/firmware/efi. If it's present, you've booted in EFI mode. If not, you've probably booted in BIOS/CSM mode (although there are ways to suppress that directory in BIOS/CSM mode, so the absence of the directory isn't a 100% perfect diagnostic). You can also check your kernel ring buffer ("dmesg") for output related to EFI. In EFI mode, there will be dozens or hundreds of lines of such output. In BIOS/CSM mode, there will be no such lines, or maybe just one or two that refer to the firmware version or some such. The problem with this test is that the kernel ring buffer is size-limited, so early messages tend to scroll out of it after the system has been booted for a while.

hungerfish wrote:

my gpt table contains 3 partitons, sda1-3 , sda1 is the esp, which was marked bootable through the syslinux installer.
the (hybrid)mbr contains 4 partitons, 2-4 being my actual partitons. 3 is marked bootable there, that is my osx partitons.
Why is this?

A hybrid MBR necessarily contains one type-0xEE partition (the "protective partition"), which is a shrunken version of the protective partition on a standard GPT disk. Beyond that, it can contain up to three partitions from the GPT side. Since you've got just three GPT partitions, including all of them results in a disk with three GPT partitions and four MBR partitions -- but the type-0xEE MBR partition isn't really a partition; it's just a placeholder and signal that the disk is a hybrid MBR/GPT disk.

As a side note, most hybrid MBRs do not include the ESP; instead, its disk space is covered by the 0xEE partition. Thus, many people mistakenly believe that the 0xEE partition is the MBR-side version of the ESP. I don't know why yours is different.

hungerfish wrote:

Also, how could I change the bootable flag in the mbr? By just using a gpt-unaware tool?
Is it worth a try to get rid of this whole hybrid-mbr thing, and see if my setup still works. Because as it stands, my bootloaders are all gpt aware and all ignore the mbr.

The OS X partition is marked as bootable because of some detail of how you set it up. Most tools, like Boot Camp and gptsync, use an algorithm to set one partition as bootable, since Apple's firmware requires one MBR partition to be bootable in order to activate the CSM. rEFIt and rEFInd also contain code to set an MBR partition bootable if none is so marked when booting a BIOS-mode OS. Most BIOS boot loaders don't even care about this detail any more (certainly GRUB doesn't), so from a BIOS software point of view, you could remove or change the boot flag; but as Apple's CSM does care (or so I've heard), removing the boot flag is inadvisable. (Of course, you could always experiment, and restore it when you're done.) If you decide to try this, about the only tool available in Linux is fdisk, which is GPT-unaware and will therefore adjust the MBR side.

hungerfish wrote:

How would I get rid of the hybrid mbr?
By just creating a new protective mbr spanning the entire disk with gdisk?

Precisely. Making any changes to the disk with a libparted-based tool will also do the job.

JohnWinkerbelt · 2013-05-09 10:59:26

CSM-mode works.

Eve if the "pure-efi" way won't be solved by the nvidia developer in a foreseeable future, the CSM-mode works very fine and that's good.
This would solve this thread HALFway, not fully but in a reasonable way.

But the cause is as clear as daylight, the Apple EFI is way too old (version 1.x), and it's API is somewhat different from the UEFI of nowadays (version 2.x). I went around and asked some fellow students who also have a Linux installed in pure EFI and they stated it works with their UEFI board on various other Laptops or PCs, with nvidia.
It's frustrating, but somehow I can't blame nvidia alone for this, now I also blame Apple for it's incompatibility in their old EFI. Something like a firmware update is out of question I afraid.. (okay, Intel based Macs are using EFI, not the Open Firmware by Power based PC of Apple)

== Short Howto to CMS ==

So, if anyone is interested in the way I do or would do, here some descriptions,

First, I made my system just like the one of Ubuntu (before I know about a separated BIOS partition). Yeah, some of you would think "no, that's no good", but that makes no harm to me, since I won't change anything on it after the installation anymore.

Well then, I have an EFI partition with 200MB, an MacOS partition with approximately 70GB and the rest with Linux.

I assume you have already partitioned your harddisk as you wish. In my case I reinstalled Arch after the following step one. Maybe you don't want to sacrifice your Arch installation, then try the following:

1. Remove the link to the EFI partition in the fstab by deleting the line with the EFI partition.
2. Delete the arch-grub or grub folder inside the EFI folder on the EFI partition. (any way is fine)
3. Do the "Step one" (hybrid MBR)
4. uninstall the efi-grub and install bios-grub
5. Do the "Step two" without installing Arch (write GRUB into partition)

I THINK this should do the same, but I'm not sure.

Whatever you do, be sure to make a complete backup of your system before you do this steps, because I won't be responsible for the mess, if something is going wrong. The steps I'll describe did it for me.

Step one, to have a hybrid MBR partition, you should start the system with an arch cd or USB and make a hybrid table with gdisk

# gdisk /dev/sda

Follow this Wiki from gdisk and you'll obtain your hybrid mbr. Now I'm going into detail.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 2 3

I choose 2 and 3, because 2 is my MacOS partition and 3 Linux. No need more. You can even just do 3, as srs5694 said, it's only for us to enable BIOS-mode booting on the particular partition.

Place EFI GPT (0xEE) partition first in MBR (good for GRUB)? (Y/N): y

Be sure to choose "yes", because if not, the EFI will be listed at last and the Macbook will have to search for it, which takes almost half a minute EVERY start.

Then it will ask you for every partition, which MBR code you want and if there should be a bootable flag to set. Choose the default MBR for all the partitions, but for the linux partition, set the bootflag with "y".

Unused partition space(s) found. Use one to protect more partitions? (Y/N):

Do as you want, I choosed "n" no, but that shouldn't be that relevant for a successful boot of the bios-grub.

After that, type "o" again to see, what it looks like, and with "w" you get a warning, if you really want to do this, which you actually want with "y".

With this, you should have a "clean" hybrid MBR.

Step two, now boot again with an Arch cd or USB.
If not already done this, follow the How do I install Arch on Mac? guide.

At the point of GRUB install boot files, you can choose between the way to install in on a separated BIOS-GRUB partition or on the linux partition. Of course it's not recommened, but it works, but well, do what you like.

For the chance you really want to install in into the partition as I did, don't be irritated by the error and warnings, as long as you can see this in the last line:

Installation finished. No error reported.

Then, even if it looks nasty, it's fine.

== Short Howto to nvidia and powersave stuffs ==

Well then, if you get here, then you did it (hopefully)!
You can start with installing your favourite Window Manager, mine was and still is XFCE. Pacman or Yaourt will ask you, which driver you want to install, like mesa, nvidia-304 or nvidia. Of course we choose nvidia.

Make sure you have the xorg-server and int utils installed, and xorg-server-devel, this prevents the "no screen found" error of nvidia.

Then it's done, your system should last about 30%-60% longer with batteries than with nouveau. I recommend you to stick with nvidia, because the nvidie-beta still drains too much batterie as I tested both of them.

For more power saving I suggest you have a look at Laptop, power saving.
For my part, I have powertop and the Laptop Mode Tools installed.

Since then, if I want to get the maximum power saving by reducing the brightness to one and let it idle for a while, I can see a consumption of ~7,4 W, that result for me in 6-7 hours batterie life. For normal work it'll last ~4 hours.

But it's important that the system won't heat up too much anymore. It's stays cool for the most time like now as I write this while listening to music and browse some website.

== Maybe some hints to correct errors ==

There are chances that GRUB won't find the /dev/sdaX by label or UUID, in this situation you have to redo the "hybrid MBR" step, then it should work again.
If this won't work, then you maybe did something wrong about fstab or the generating of grub.

Since I use nvidia (currently 313.something), the brightness steps to dim and lighten up is too wide. As we know the brightness do not rise in a linear manner, but it's exponential. That's the cause why the steps can be really large, if the brightness is near zero, but is small at almost full brightness. by the way, the power manager are making 10 steps for brightness.

The brightness panel doesn't work for me too, it'll crash if I want to add it to the xfce panel.

I had the problem, that 0 is too dark (obviously), but 10 is still to bright.
That's because there are still 8 steps betwee 0 and 10.

For this, just use xbacklight,

xbacklight -set <something between 1-100, 0 means black screen or just off>

For mor information, look for xbacklight, I made extra shortcuts, so that I can dim it in -+1 steps.

I heard, with xfce 4.12, this problem will be solved. So stay alert.

Hope this will help anyone out there and hopefully this doesn't miss the main topic of this thread (I afraid it does ^^")

Last edited by JohnWinkerbelt (2013-05-09 16:44:41)

srs5694 · 2013-05-09 14:28:38

JohnWinkerbelt wrote:

the CSM-mode works very fine and that's good.
This would solve this thread HALFway, not fully but in a reasonable way.

This thread is already so long that it might be worthwhile to remind us of what's not working.

now I also blame Apple for it's incompatibility in their "open firmware", which is not open at all.

Actually, Apple used Open Firmware in its PowerPC-based Macs. Intel-based Macs use EFI. The two are not the same.

Type from one to three GPT partition numbers, separated by spaces, to be
added to the hybrid MBR, in sequence: 2 3
I choose 2 and 3, because 2 is my MacOS partition and 3 Linux. No need more.

Actually, the only purpose that the hybrid MBR serves for you is to enable BIOS-mode booting. Both Linux and OS X ignore the MBR entries. Thus, it's possible to enter just one partition in the list -- ideally the last one on the disk, so that the 0xEE partition covers as much of the disk as possible.

That said, there's little real advantage to re-doing your setup now that it's working, and there's always the risk of doing damage. ("If it ain't broke, don't fix it.")

Arch Linux

#1 2013-04-27 12:30:36

Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#2 2013-04-27 22:07:30

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#3 2013-04-28 16:21:23

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#4 2013-04-28 20:30:53

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#5 2013-04-29 00:39:42

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#6 2013-04-29 17:09:45

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#7 2013-04-29 17:14:27

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#8 2013-04-30 09:40:14

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#9 2013-04-30 16:28:11

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#10 2013-04-30 16:52:05

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#11 2013-04-30 19:27:58

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#12 2013-04-30 21:58:11

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#13 2013-05-01 07:19:45

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#14 2013-05-01 16:32:12

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#15 2013-05-01 19:03:13

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#16 2013-05-02 00:14:23

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#17 2013-05-02 09:31:18

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#18 2013-05-02 16:13:08

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#19 2013-05-02 20:00:48

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#20 2013-05-02 22:02:44

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#21 2013-05-04 22:07:42

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#22 2013-05-05 11:51:16

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#23 2013-05-05 12:41:32

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#24 2013-05-09 10:59:26

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#25 2013-05-09 14:28:38

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

Board footer