Jump to content


  • Content count

  • Joined

  • Last visited

About blaatschaap

  • Rank
    InsanelyMac Protégé
  1. When doing these things, I like to make full backups of the whole drive (from a linux live cd with dd - in case I {censored} up and need to roll back completely), as well as backups of individual partitions (with dd too), and note the exact number of blocks they take up on the drive. then, after repartitioning exactly how I like (re-using the noted sizes in blocks, potentially leaving space inbetween two consecutive ones if I want to grow any of them for example) and reloading the partition table, I dd the individual partitions' bits exactly back into their new place. Of course, windows won't like that it will have changed from MBR to GPT or vice versa, not much to be done about that. PS. take care to align blocks to physical sector sizes (the easiest way to do this is to align every partition at 1MB offsets).
  2. Just adding my two cents. I'd definitely avoid any legacy booting altogether (I have legacy boot completely disabled in unlocked 'BIOS') and use UEFI for everything. As for my post about "fixing" the MBR partition table to only have the 0xEE partition, it is specifically aimed at this kind of setup (that is, where you don't need any legacy booting). Of course, linux has no problem booting in legacy mode with gpt partition scheme, but other operating systems aren't so lenient. PS. About the scalability and/or effectiveness of this... I have a quintuple boot set up on my XPS 15 now ;-) custom built ChromiumOS, OS X, Windows, Arch, Ubuntu all in perfect working order.
  3. Holy {censored}, I experienced the quickset hang too, never connected that to anything I read in this thread though, for some reason. It had me worried about faulty RAM or something. Good to know it's just a Dell {censored} up basically.
  4. Mint won't care about UEFI/GPT or legacy BIOS/mbr, for the record, as long as you make sure the bootloader (likely grub) knows how to boot your kernel.
  5. Yeah, I'm well versed in UEFI shell, bcfg, efibootmgr, etc. But it's just not doing what I'm telling it to do. (I have my boot drive not in the caddy, but in under the palm rest assembly, aftermarket SSD). If I, for example, add a bcfg boot entry for my UEFI Shell, which resides on the EFI system partition, it just won't boot into it, no matter what boot order I specify. PS. Today I also noticed that Mac OS X has trouble interpreting complex GPT schemes correctly... Rather pathetic how buggy it is...
  6. I think the XPS 15 UEFI implementation does have some bugs with regard to the boot configuration, can't quite get it to do exactly what I tell it to, not with bcfg in a UEFI SHELL, nor with efibootmgr from my linux installation. Oh well.
  7. Pretty sweet setup dude! Looks like you are ready for Mavericks, once it comes out. I'd be interested in that config.plist, the DSDT (and other) patches encoded in there in particular. Actually, your post is so great, I'd love, say, a zip file with your basic config files (like the keycode profile, etc). I myself would require minimal explanation, just point me to the right places :-) I'm looking to contribute some patches to Clover, relating to configuring other OSes via text files, as the autodetection it has is really unflexible. rEFInd has all this, but I guess both were forked from rEFIt fairly long ago and not many patches are shared between these two projects... Since Clover has some kext patching features, you could probably make a fairly simple patch for giving it an option for autopatching the IOAudioFamily. PS. I've noticed this shutdown issue too... Hardly ideal when you are shutting down your machine before having to leave quickly... You come back and the battery is drained! PPS. Did you dump unpatched DSDT, decompile it and compare to DoiX's to get the exact patches needed, or? Are they exactly the same btw?
  8. The error message he listed states specifically that Windows complains about the presence of the MBR reference to the Windows partition, an error I encountered as well and fixed in this way. This discussion is over as far as I'm concerned. You could have probably fixed it my way too if you knew you could, but you didn't know you could, so you actually physically unplugged your hard drive. That hardly means that is the best way to go about it.
  9. Sigh... I'm sure my instructions will fix his problem. A non-protective (one that includes more than just the 0xEE entry indicating GPT scheme) MBR partition is present, otherwise Windows would not have complained during the UEFI install.
  10. @Air, check your MBR, with fdisk /dev/diskX If it has just one partition with the 0xEE type, it has a simple protective MBR, and Windows will allow installation. If it has various other partitions as well, in particular the Windows partition, Windows will give this error. As long as Clover is set up properly and you don't need the MBR for the other OSes, go ahead and delete the other partitions from the 'legacy' MBR. (Keep the 0xEE partition with number 1!!) Start fdisk in interactive mode on the drive and use d to delete the partitions 2, 3, 4, etc. (Cannot remember the command for interactive mode, should be easy to find out.) Be sure to back the MBR up to a safe location before doing this so you can restore it if this {censored} up your system: dd if=/dev/diskX bs=512 count=1 of=/location/of/backup EDIT: I know for a fact this works, since I ran into this very problem and fixed it like this.
  11. interestingly, trying that Startup disk thing gives an error relating to "bless" (it does not give this error when trying to change the Startup disk after booting from the recovery partition). I don't really care, since I prefer Clover to ask me what I want to boot every time anyway. temps are about 50 degrees celcius when browsing, so that seems to be alright.
  12. Happy to report I'm posting this from a fully installed, fully working (at least, I've checked basically everything and it all works fine) UEFI Clover install of 10.8.4 on my XPS 15! Thanks very much to all contributors for your help. Is there a checklist to see if indeed everything works? 1) audio, works, even after resuming from sleep 2) backlight saving across reboot, works 3) backlight keys, works 4) nvidia card disabled, "works" 5) hwmonitor and sensors, works 6) touchpad, works 7) cpu frequency scaling, works (what are good temps under load?) anything I missed?
  13. You're quite right, of course! Updated the sig now, should show up under this post. Trying to install 10.8.4 from a manually crafted USB stick (which has Clover on it). I put all needed kexts on it inside the BaseSystem.dmg, etc and it's booting up now. I'm now dd'ing the entire hard drive as is to a backup drive, then, for good measure, I will even dd if=/dev/zero it completely, then I'll proceed with a full UEFI, gpt-only repartitioning. I think I got it covered now, since the USB stick boots completely without any flaws (I even put the patched DSDT, SSDT on the usb stick, allowing Clover to load them). After install reboots, it's just a question of copying over potentially missing kexts, actually install Clover onto the hard drive and I should be golden! Could you post exactly which patches you applied to the DSDT, I'm interested in that. Does anyone know what EFI spec version the XPS 15 supports? EDIT: With this setup, the UEFI setup, with Clover, etc. and the minimal kext patching, upgrading to Mavericks shouldn't be too difficult I imagine. (I predict it will go GM within a week, btw. What are your thoughts?)
  14. Strangely, I'm getting kernel panic relating to AppleIntelCPUPowerManagement, even though I've patched it with AICPM patcher... "P-State Stepper error 18 at step 35" EDIT: caused by faulty SSDT in DoiX's package. Fixed using RevoBoot ssdtgen script. Is this a known issue? Makes me wonder about the DSDT.aml and SSDT-*.aml... if those are buggy too.
  15. OK, interesting, because I did find updated ALC kext for 10.8.3+, newer FakeSMC, updated SmartBatteryManager and I believe VoodooPS2 is far superior to the regular Apple kexts. Also, there is a new generic USB3 driver that is supposedly much better than PXHCD. Is the modded DSDT as good as the one from the L702x thread elsewhere? I think I read they have pretty much everything working flawlessly for L702x...