rosmaniac

How did you install Mint? I'll have to do some digging to see how an MBR disk would be detected (and it seems like, from you fdisk output, that it is MBR). On my CentOS multi-boot system fdisk sees this: [root@localhost ~]# fdisk -ul /dev/sda WARNING: GPT (GUID Partition Table) detected on '/dev/sda'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sda1 1 1953525167 976762583+ ee GPT Partition 1 does not start on physical sector boundary. [root@localhost ~]# But gdisk sees: GPT fdisk (gdisk) version 0.8.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1953525168 sectors, 931.5 GiB Logical sector size: 512 bytes Disk identifier (GUID): VVVVVVVV-WWWW-ZZZZ-YYY-XXXXXXXXXXXX Partition table holds up to 128 entries First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 8-sector boundaries Total free space is 263990 sectors (128.9 MiB) Number Start (sector) End (sector) Size Code Name 1 40 409639 200.0 MiB EF00 EFI System Partition 2 409640 587833295 280.1 GiB AF00 MixBusM4300 3 588095440 1113159887 250.4 GiB AF00 MixBusSL 4 1113161728 1317961727 97.7 GiB 0700 CentOS6-root 5 1317961728 1334738943 8.0 GiB 8200 CentOS6-swap 6 1334738944 1953525134 295.1 GiB 0700 [root@localhost ~]# I've not done a mult-drive setup like yours, but it should prove to be interesting. It may take me a few days before I can look through the code; someone else might be a bit quicker with seeing what Chameleon expects from the second and third drive, especially when used with MBR partitioning.

Please see the instructions on setting the proper partition type for the linux boot partition in the thread: https://osxlatitude.com/index.php?/topic/5902-dualboot-installing-linux-after-mavericks/ EDIT: And please note that that only applies if Linux is installed to a GPT-formatted disk. If it's MBR, I haven't tried that one, but the correct type for Chameleon to chain boot is in the same source tree that I note in a post in the referenced thread; you'd just have to look through the MBR equivalent to diskScanGPTBootVolumes.

I have seen this with my M4300 as well, when booting the install USB and before installing EDP. But I haven't seen (with the rev 762 EDP and associated bootpack) the keyboard and mouse issue.

On my Precision M4300, very similar to your D830, I had serious audio issues (including the audio not recognizing at all on some boots) until I did the performance optimizations mentioned in the thread https://osxlatitude.com/index.php?/topic/3078-m4300-no-ethernet/ I found that audio would skip and sputter even on those instances when it would load properly; this was with EDP rev 762 on 10.9. And I found it would not load at all (even to the point of not showing the volume control) at least one out of every four boots. Some audio programs triggered worse sputtering than others. When I applied the performance optimizations all of that went away and audio now works well and works consistently. When I reboot into OSX I'll look and see which version of the VoodooHDA I'm using (it's probably the same one as posted above).

Excellent. You're very welcome, glad it worked!

You need to have Ubuntu install the bootloader on the partition containing /boot (either the / partition or the separate /boot). You then need to use a tool like GPT fdisk (gdisk) to change the 'type' of that partition to '0700' See https://osxlatitude.com/index.php?/topic/5902-dualboot-installing-linux-after-mavericks/ for more information and a success story.

Glad that worked, and you're very welcome.

devilotx, can you provide the output of 'sudo gpt show /dev/disk0' please? Here's what I get with a working triple boot, where one of the OS's in CentOS Linux: dhcp-pool132:bin lowen$ sudo gpt show /dev/disk0 Password: start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 6 40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B 409640 587423656 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 587833296 262144 588095440 525064448 3 GPT part - 48465300-0000-11AA-AA11-00306543ECAC 1113159888 1840 1113161728 204800000 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 1317961728 16777216 5 GPT part - 0657FD6D-A4AB-43C4-84E5-0933C84B4F4F 1334738944 618786191 6 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 1953525135 32 Sec GPT table 1953525167 1 Sec GPT header dhcp-pool132:bin lowen$ I've booted into Mav, and am looking at what is available to deal with this.... but it looks like the best solution is going to be installing the OS X version of GPT fdisk ( http://www.rodsbooks.com/gdisk/ ) which can do what you need. Since i have always used the Linux version from a boot USB, I really don't know if gdisk will allow you to edit the boot drive's partition types or not. UPDATE: The author's documentation seems to indicate that only under FreeBSD will you be locked out of editing the partition table of a disk with a mounted volume. YMMV, etc. Hope that helps. The OSX built-in gpt and diskutil commands seem to be pretty weak on making changes to existing partitions, but I would love to be proven wrong.

Further note: it appears that gpt might do the same thing as gdisk, under OS X. I have not tried it, and will at my earliest opportunity reboot into OS X to see if that is indeed the case. I'll update this post if a reply isn't posted before..... (Updated to remove pdisk reference, instead it appears gpt is the command to use). Issue 'man gpt' at a terminal command line to get arguments and such, or use the online manpages on the Apple Developer site. EDIT: The technical info: Chameleon (as of SVN 2283 from voodooproject svn) will recognize one of two GUID's for chain booting a foreign OS: BasicData {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} or BasicData2 (reserved partition, {E3C9E316-0B5C-4DB8-817D-F92DF00215AE}) as selected in the function diskScanGPTBootVolumes in i386/libsaio/disk.c in the Chameleon source tree. This corresponds to a gdisk 'type' of 0700. In order to detect a 'native' Linux (8300 type) Chameleon would need to be patched to recognize GUID {0FC63DAF-8483-4772-8E79-3D69D8477DE4} as well. But CentOS 6 at least uses the reserved EFI type of EF00 {C12A7328-F81F-11D2-BA4B-00A0C93EC93B} for the booting partition. You can find the list of gdisk's 'types' to actual GUID's along with comments in the gdisk source tree; through-the-web svn: http://sourceforge.net/p/gptfdisk/code/ci/master/tree/parttypes.cc Hope this is helpful to someone.... it was fun spelunking in the Chameleon source to find it.

devilotx, I'm assuming first that you installed to GPT instead of MBR. If that's not the case, then this probably won't work for you. Also, note that while I dual-boot Linux, I'm using CentOS, not Ubuntu. So, as the saying goes, your mileage may vary (YMMV). You need to change the partition type of the Linux boot partition to '0700' for Chameleon to recognize it, in my experience. This can be done most easily with a program called 'gdisk' which is available for Linux and OSX. By default, CentOS at least will set the boot partition's type to EF00 (as that's correct when booting from a 'normal' EFI). Here's the output of 'gdisk -l /dev/sda' for my triple-boot system: [root@dhcp-pool121 ~]# gdisk -l /dev/sda GPT fdisk (gdisk) version 0.8.8 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1953525168 sectors, 931.5 GiB Logical sector size: 512 bytes Disk identifier (GUID): 195C6419-B7BC-4938-A6EE-123456789012 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 1953525134 Partitions will be aligned on 8-sector boundaries Total free space is 263990 sectors (128.9 MiB) Number Start (sector) End (sector) Size Code Name 1 40 409639 200.0 MiB EF00 EFI System Partition 2 409640 587833295 280.1 GiB AF00 MixBusM4300 3 588095440 1113159887 250.4 GiB AF00 MixBusSL 4 1113161728 1317961727 97.7 GiB 0700 CentOS6-root 5 1317961728 1334738943 8.0 GiB 8200 CentOS6-swap 6 1334738944 1953525134 295.1 GiB 0700 [root@dhcp-pool121 ~]# The way I use it is a bit convoluted. When I go to install a CentOS installation to a system booting with Chameleon, I have a couple of boot USB drives available. One is a boot USB of the installer, and the other is a 'live' USB, both using CentOS. I don't install from the 'live' USB because I don't like the default preferences that brings across, and, well, I like to select lots of packages out of the gate off the install media and go away for a while during the actual install. Anyway, the 'live' USB is set up using the Fedora liveUSB tools to have a persistence overlay; i then add the 'EPEL' repositories to the live USB and install gdisk there. I boot the install media, do the install, shut down, boot the live USB, and change the partition type of the CentOS boot partition with gdisk from the live USB media. With Ubuntu, I know you can do very similar things, including the persistence overlay and custom live USB spins, but since I've not done that with Ubuntu I can't give a step-by-step. Since Ubuntu installs most easily from the live media, a custom spin of the live media with the gdisk package will do what you need. What you'll have to do then is launch a command line terminal and run gdisk on your hard disk, and change the partition type with the 't' command. You can also assign descriptive names within gdisk. When done, use the 'w' (write) command to write the changes back to disk. The '?' at the gdisk prompt with give you help. Do be careful that you have the correct disk, as gdisk, being a disk partitioner, can potentially cause data loss. So, back up your OS X stuff beforehand, if you have anything important to back up. Hope that helps. EDIT: While I'm sure this could be done inside OS X, I am first and foremost a Linux freak, and so I tend to use Linux tools to do things. A 'pure' OSX recipe for doing the same thing would be interesting.

Ok, can do. And, yes, the 690 is on my list. That will need a complete set of new model data, and will be a fun project. Separate threads; I would assume posting results and such in the R&D section......

Bronxtech, I'll do what I can. I understand the time issues, since I've been involved in some open source projects before, including one stint over a period of five years that, when I did step down, a number of people expressed surprise that I had done it all as a volunteer. I also have several children and a full time job, and I understand the pressures, particularly in terms of support (it's amazing to me how pushy people can get for support of a free-to-them nature! I still get e-mail 'demands' for fixes, and I haven't maintained that one package for several years!). Within the four unique systems I have (all listed in my sig), what do you think needs the most attention? I'm going to put forth the most effort into just looking and seeing what set of modules, within the normal EDP framework, produces the best out-of-the-box performance on M4300, and I'm working towards that first by setting up a multiinstall rig over the next few weeks. I'll record my selections as I go, and then update my local edp.sqlite3 database and make sure the default on my system then matches what works. Anyway, I'll find it fun to learn some of this that is new to me, and I hope I'm able to provide some positive contributions back to the project.

Hervé, I appreciate the additional information and your great work in these forums. I've only put in the details that I have in order to support my initial assertion: the M4300 with Mavericks felt sluggish with the out of the box EDP build (as of SVN rev 762). It felt slower than my previous D820. And that's the bottom line. It's great that there are customizations that can be done outside EDP, and I thank you for the pre-baked M4300 files. But it does mean I've left EDP behind for anything in the future, as an EDP model build will wipe out what is working so wonderfully right now. (Yeah, I know how to put it back....). But the ordinary EDP user is not getting the performance that they could get; and, yeah, I see the difficulties with how to go about implementing that on the developer side, especially in light of the rapid updates to FakeSMC. And I thoroughly understand the stability question (that's why my choice of Linux is CentOS, based on RHEL). Please understand that I'm not complaining for myself by any means; I'm just trying to advocate for the newbie; even the seasoned PC user, Windows or Linux or other, is going to find OS X to be a bit arcane for a while (I certainly did, and I've been using, administering, and programming Unix systems for 26 years). I'd like to help solve this in some way, and one thing I can do is set up a testbed for regression testing the default EDP builds for M4300 for each supported version of Mac OS. Because, as you mentioned, testing is critical. Much of the infrastructure for doing the customizations is already in place; EDP is already database-driven and highly configurable (I'm looking forward to seeing the latest developments, too, particularly any changes made in edp.sqlite3). If you know what you need to modify and have the values for the appropriate places in FakeSMC and smbios.plist those can be database-driven. No, that's not a small task. Barring the customizations, there has to be something else going on; it just doesn't make any sense that the substantially faster M4300 would feel slower than the D820, with both systems running the 'stock' EDP builds, and both on Lion (which is where I started with the M4300). But I reserve the right to be wrong. And if you and the rest of the OSXL crew just want me to shut up about it, well, I can do that too. But I'd like to help improve the performance situation for the user who just uses the stock EDP build for M4300, if I can.

The point is to illustrate that the EDP default is pretty poorly tuned, at least for M4300. And I'm glad to see change in that on the horizon, and I want to be able to confirm improved performance in the default EDP. After all, one of the draws of EDP over the rest is that there is model data that is supposed to be somewhat tuned for each supported model, no? Incidentally, this isn't meant as a criticism of the project, just a desire to make it better. And when I have my test rig built and in hand, I will be able to hopefully help confirm that what EDP builds for each model really is tuned. Perhaps I'm odd, but I tend to think that a newer model with a faster processor should perform better in real world tasks than the older model with a slower processor. I'll go the next step and state that I think it's a bug in the current model data that the performance isn't at least somewhat tuned. I am willing to help check out different combinations, too, to try to find sane default model data for at least the M4300 (and maybe the D820, too, since it may not be running optimally). And I'll again be looking forward to seeing the SVN commits come down. EDIT. Upon reading that, I see that I really didn't explain what I consider to be a 'default' EDP setup. I consider a default EDP setup to be what an EDP build made by just selecting the model the normal way, and then doing the build without any customizations of any kind. I'm not talking about bootpacks, here.

Ok, in the thread https://osxlatitude.com/index.php?/topic/3078-m4300-no-ethernet/ a set of files are posted, and a bit of discussion occurred about M4300 performance relative to D820 with default EDP, and the extreme performance boost presented by the use of the MBP5,1 SMC and SMBios, along with some other kext changes. Please see that thread for the files, context, and such. Also see the article on performance tuning with FakeSMC and SMBios, http://www.osxlatitude.com/tuning-performance-with-fakesmc-smbios-plist/ Now, I'm getting ready to build my second M4300 into a benchmarking rig, but before I put out the effort to do so I wanted to see if it was worth it to get a completely apples-to-apples comparison. So I ran XBench 1.3 in three different scenarios: 1.) On my D820 at home running Lion; 2.) On my M4300 running ML and the default EDP kext set/SMBios setting (MBP3,1) 3.) On that same M4300 running Mav and the MBP5,1 SMBios and kext set with native speedstep. Now, I know that those benchmarks are not exactly apples-to-apples, but they give me enough information that I'll post the composite numbers here, and then I'm going to build my benchmarking rig over the next weeks. I have a spare Seagate Momentus 7200RPM 500GB drive, and I'm going to either create seven or nine partitions: 1.) MavE (EDP default) 2.) MavC (MBP5,1 custom Extra) 3.) MLE (EDP default) 4.) MLC (MBP5,1 custom Extra if I can make that work with ML) 5.) LionE (EDP default) 6.) LionC (MBP5,1 custom Extra if possible) 7.) SLE (EDP default) (if doing this with 10.6 is even important) 8.) SLC (Custom MBP5,1 if at all possible) 9.) Data. Yep, either a sextuple or octuple-booting system. It will be interesting to see how Chameleon handles that. Of course, I will have to be exceedingly careful doing the installs in the right order, and I've also gotta figure out that order..... And I may only do quad boot, with just Mav and Lion, but I haven't decided. I do have hardware that works only up to 10.6.8, and I have other hardware that only works up to ML (Tascam US-224 and 428 up to 10.6.8; Tascam US-144 for up to ML, although Tascam might possibly release for Mav, since their entire US-xxx line is out of commission on Mav right now (32-bit kexts.....)). Anyway, the numbers that to me make this worthwhile to get true apples-to-apples (and the reason that I want Lion on the M4300, both EDP default and the MBP5,1 custom) is the comparison between the D820 (limited to Lion unless you want to go to great lengths and do odd things) with a T7400 CPU and the M4300 with the much much faster T9300 CPU. Xbench produces a composite result of 51.32 on the D820, with a CPU composite of 69.44, a Quartz composite of 94.21, an OpenGL composite of 28.25 (35.83 FPS), and a User Interface composite of 57.05 (261.83 refreshes/second). Ok, on ML on the M4300 with a 2.5GHz T9300 and the default EDP, Xbench composite is 86.71, CPU 158.37, Quartz 191.03, OpenGL 87.25, but a User Interface composite of 43.26 (198.53 refreshes per second). That last number exposes just how slow the system feels, which for many things is noticeably slower than the D820 at a 433MHz slower clock and a Merom CPU versus the Penryn. It's impressive that even when held back a bit the Penryn manages over twice the performance of the not-that-much-slower-clocked Merom. On the tuned Mav install (MBP5,1) the M4300 really shows its speed potential, with a composite of nearly twice that of the default EDP on ML of 166.9, a CPU of 180.05, a Quartz test of 187.94, an OpenGL of 111.89, and a User Interface Test of a blistering 240.67 (1K refreshes per second). Now that's more like it, with the Penryn really shining at 2.5 times the speed of the Merom and the interface responsiveness clocking at a nearly five times the speed of the ML with default EDP on the same M4300 hardware, and four times the speed of the D820 (and it really is that noticeable in real use). And I agree that perceived performance under real world use is more important than artificial benchmark numbers, but in this case the almost totally unusable performance (with programs that I use daily) of ML or Mav with the default EDP contrasted with the several times more responsive Mav with the MBP5,1 mod is a real eye-opener where the true magnitude of the difference is completely reflected by the benchmarks. While I don't have the Mav with EDP default numbers (and I really don't want to change anything with my main M4300 to test that!) at least the merit of having such a benchmarking/test rig is apparent. Now, I use the ML numbers for the default EDP on the M4300, but Mav with the EDP default install felt slower than the ML with default EDP. At least I'm not using the Win7 in a VM on OSX on a PC numbers.....