Hello. Anybody has tried the Migration Assistant? Never worked on my Macbook Pro 17.
Also it´s imposible to boot in Safe Mode.
Also it´s imposible to boot in Safe Mode.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS 10.15 Catalina on Unsupported Macs
- Thread starter 0403979
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
Try a different USB stick. I had one that generated various errors and even failed to install on a supported iMac13,1.
I'm not sure if this question has been posted here before
But could we perhaps enable sleep with Mojave and Catalina this time within the patchers?
sleep is currenty broken on 2011 iMac's using Mojave or Catalina, due to missing sandy bridge kexts for iGPU.
As far as I can remember these kexts are still needed for proper sleep functionality.
Perhaps tools like dosdude1's patcher can integrate these in a future release ?
Which would be awesome !
Thx in advance,
But could we perhaps enable sleep with Mojave and Catalina this time within the patchers?
sleep is currenty broken on 2011 iMac's using Mojave or Catalina, due to missing sandy bridge kexts for iGPU.
As far as I can remember these kexts are still needed for proper sleep functionality.
Perhaps tools like dosdude1's patcher can integrate these in a future release ?
Which would be awesome !
Thx in advance,
Last edited:
Hey, I'm back again with what's hopefully the last Dock-related patch for my SkyLight wrapper. I'm not sure if anybody noticed, but my recent fix for the left-side-Dock-collisions-wack-ness was actually terrible. While it fixed the weird size limiting, it caused apps (no matter the Dock orientation) to sometimes open "under" the Dock... like they did before I wrote any Dock shims, when those functions were just stubs.
Now, I finally understand what's going on, and I've implemented a patch that will fix that regression, while still keeping things working when the Dock's on the left. A new wrapped SkyLight framework and wrapper code is attached. @dosdude1 @0403979
A (not so) quick summary of what's going on here for those who are interested:
The Dock collisions are handled by two functions in SkyLight, SLSSetDockRectWithOrientation and SLSGetDockRectWithOrientation. These are called by the HIServices framework.
SLSSetDockRectWithOrientation is called when the Dock rectangle is changed (either by stretching, changing what side it's on, or opening/closing/adding/removing apps), as well as at some point during the login process. It is supposed to store the Dock rectangle (of type CGRect) as well as what side it's on. The problem, of course, is that Mojave's SkyLight doesn't have this function. But it does have a very similar one, SLSSetDockRectWithReason. So, my wrapper just passes the rectangle through to that function -- a very simple shim, and one that I implemented a couple months ago.
SLSGetDockRectWithOrientation is used, unsurprisingly, to fetch the saved rectangle. I pass that call through to the very similar SLSGetDockRectWithReason in the old framework.
That was enough to get the Dock to "collide" with apps normally, when the Dock was on the bottom. As you can probably see quite quickly (but I didn't!), not saving the orientation is bound to cause issues. Essentially, the weird window-size-limiting that some of you reported? That was because the system thought that the Dock was still on the bottom, but standing on end. And so, of course, it prevented the app from colliding with this monstrosity of a tall vertical Dock that it thought was there. (See the mockup image below -- eww!)
My previous "fix" for this issue was to disable the SLSGetDockRectWithOrientation function, which essentially disabled Dock collisions altogether. That was dumb.
The correct fix is simply to, in SLSGetDockRectWithOrientation, fetch the Dock orientation (using a private HIServices API documented here) and return it correctly. (See my attached code.)
TL;DR: I was dumb, didn't save the Dock orientation in my shim function, caused the system to think the Dock was standing on end, and squished your apps. Then I "fixed" it by disabling the whole shim function. Now I finally fixed it properly. Yay me! (This is a perfect example of why you don't want a first year computer science student to be patching your operating system...)
Now, I finally understand what's going on, and I've implemented a patch that will fix that regression, while still keeping things working when the Dock's on the left. A new wrapped SkyLight framework and wrapper code is attached. @dosdude1 @0403979
A (not so) quick summary of what's going on here for those who are interested:
The Dock collisions are handled by two functions in SkyLight, SLSSetDockRectWithOrientation and SLSGetDockRectWithOrientation. These are called by the HIServices framework.
SLSSetDockRectWithOrientation is called when the Dock rectangle is changed (either by stretching, changing what side it's on, or opening/closing/adding/removing apps), as well as at some point during the login process. It is supposed to store the Dock rectangle (of type CGRect) as well as what side it's on. The problem, of course, is that Mojave's SkyLight doesn't have this function. But it does have a very similar one, SLSSetDockRectWithReason. So, my wrapper just passes the rectangle through to that function -- a very simple shim, and one that I implemented a couple months ago.
SLSGetDockRectWithOrientation is used, unsurprisingly, to fetch the saved rectangle. I pass that call through to the very similar SLSGetDockRectWithReason in the old framework.
That was enough to get the Dock to "collide" with apps normally, when the Dock was on the bottom. As you can probably see quite quickly (but I didn't!), not saving the orientation is bound to cause issues. Essentially, the weird window-size-limiting that some of you reported? That was because the system thought that the Dock was still on the bottom, but standing on end. And so, of course, it prevented the app from colliding with this monstrosity of a tall vertical Dock that it thought was there. (See the mockup image below -- eww!)
My previous "fix" for this issue was to disable the SLSGetDockRectWithOrientation function, which essentially disabled Dock collisions altogether. That was dumb.
The correct fix is simply to, in SLSGetDockRectWithOrientation, fetch the Dock orientation (using a private HIServices API documented here) and return it correctly. (See my attached code.)
TL;DR: I was dumb, didn't save the Dock orientation in my shim function, caused the system to think the Dock was standing on end, and squished your apps. Then I "fixed" it by disabling the whole shim function. Now I finally fixed it properly. Yay me! (This is a perfect example of why you don't want a first year computer science student to be patching your operating system...)
Attachments
From a supported Mac, just checked, new wallpapers added on Catalina b8, I counted at least seven!
They are all in heic format, but not dynamic.
While their stock "Catalina.heic" now contains (only) 8 pictures for the dynamic wallpaper, hey seems apple copied my previous posted! But theirs, have to admit, are nicer!
I remember in Mojave they used 16 pictures into the Mojave.heic for the dynamic wallpaper.
Now just 8.
They are all in heic format, but not dynamic.
While their stock "Catalina.heic" now contains (only) 8 pictures for the dynamic wallpaper, hey seems apple copied my previous posted! But theirs, have to admit, are nicer!
I remember in Mojave they used 16 pictures into the Mojave.heic for the dynamic wallpaper.
Now just 8.
Last edited:
[doublepost=1568155444][/doublepost]The most-current patcher OS download function does NOT download beta 8.
It should... The download is about 8.5GB. If that's the size reported during download, it is downloading the correct version.
[doublepost=1568156062][/doublepost]Tried with 1.10 and got this:
macOS Catalina Dev Beta 8 installed successfully BlueSky patches working nice new desktop pictures as well 
Photos is still working Map only partially to use the updated dynamic Catalina desktop you have to selected automatic in system preferences or it will use the dark or light still pictures
Photos is still working Map only partially to use the updated dynamic Catalina desktop you have to selected automatic in system preferences or it will use the dark or light still pictures Attachments
Last edited:
The current Catalina Patcher 1.1.0 produced a fully usable patched usb installer from the new 15.0.27 Catalina Beta installer on a MacPro 3,1 with GTX 680.
Arrgh. I ALWAYS forget to switch OFF the APFS bootloader when building the USB installer. Could you add a reminder popup for those of us with APFS boot roms?
I would, but unfortunately there's no way for me to check whether or not the ROM patch is applied, and a popup would add confusion for "normal" users.
most likely Apple took into account some sleep for 8 hours so that leaves 16 hours so the dynamic changes every to hours as mine has changed
Attachments
every 2 to 3 beta's I use the partition in disk utility to erase my usb that seem tp prevent issues when creating a new patcher
I am not sure why Apple does not include a dynamic Catalina.heic for those who only use the Dark Mode. Users should be able to have a dynamic wallpaper without having to use the Automatic Mode.
For me I like both light and dark mode and watching the changes during the day maybe it is possible to create a script running in the automator using the 4 dark macOS Catalina Desktop pictures while in dark mode
[doublepost=1568174626][/doublepost]
I don't think are from the link I found on Github but maybe
