Toggle sidebar Toggle sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS Ventura (13.x) - Bugs

Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Terraaustralis said:
Hi Guys,
Have been happy with Ventura and unhappy to find later systems offer features which are irrelevant to me, irrespective of what Apple say about security. I reckon complexity adds vulnerability and I use a variety of tools to keep watch.

Migration Assistant no longer working for Ventura 13.7.8 (22H730) Is there a fix?

Introduction
I decided to try Sequoia on my 2019 iMac and found it a very unpleasant experience. Security demands password for opening AND a password for approving application function. Very tedious. Doubles keystroke work. I decided to stay with Ventura.

My iMac uses a 2TB SATA ssd with Sequoia, and a 2TB NVME ssd with Ventura 13.7.6. Normally I would simply erase Sequoia, Use Restore on the NVMe to download Ventura, then use Migration Assistant to restore user account and settings.

Problem 1
Opening the Ventura on NVMe hit a Kernal Panic. Past experience has shown the only solution is erase and reinstall.
Time to think carefully.
We know Apple discourages using earlier systems and forces users to upgrade to latest offerings in the name of security. We also know that the only way I could reinstall an older o/s is by using Restore via Internet which gave the original o/s supplied with my machine; in this case Mojave, then build forward to desired o/s.

I downloaded Mist which allowed me to download Ventura Disk Image and package. I opted for Ventura 13.7.8 as the latest version. Big mistake!

Problem 2
I downloaded Ventura 13.7.8 to a 4TB external ssd using Restore. Once the o/s was installed with Apple ID etc. I attempted to transfer apps and settings. Could not be done! Migration Assistant did not recognise Ventura on the NVMe stating. So Migration Assistant would not migrate data on 13.7.6 to Ventura 13.7.8 backward compatibility issue? I would not have thought the kernal panic - a bootup issue, would effect Migration Assistant but then I know very little.

Reconsideration
I decided to Use CCC to transfer Account settings to Ventura 13.7.8 on 4TB external and returned to Sequoia to export browser settings and passwords onto USB and thense to external 13.7.8. This worked and I had a clean operating system but needed to install apps. I tried Migration Assistant again - no recognition. So I installed 34 apps one a time, activated and registered them as necessary.

Data transfer without Migration Assistant
Now I deleted SATA Sequoia, installed Ventura 13.7.8, via Restore. Migration Assistant would not recognise Ventura 13.7.8 on external drive so I transferred User Account, apps and Settings manually with CCC or USB.

Once this was completed I erased Ventura 13.7.6 on NVMe (and kernal panic) then reinstalled Ventura 13.7.8 via Restore. No more kernal panic, all operating properly. However Migration Assistant still would not recognise either of the other two available drives with Ventura 13.7.8 for migration. The screenshot below shows Migration Assistant still does not recognise either of the other two drives one internal, one external, as accessible for data transfer.

Having encountered obstruction from Migration Assistant at every turn, having spent four days jumping hurdles I have three un-synced OSX 13.7.8 which still cannot use Migration Assistant.

It seems I should have stayed with Ventura 13.7.6 instead of upgrading.

Research
A recent article led to these comments by Mike Bombich https://bombich.com/blog/2024/12/19/bootable-backups-have-been-deprecated-for-several-years

The article confirms the importance of Apple ASR combined with the Recovery mode environment and Migration Assistant, so that makes the Migration Assistant behaviour I experienced even more inexplicable.

I ask, what went wrong? What am I overlooking?

I welcome any contribution which sheds light on this incident.
Click to expand...
A jump of 2 major versions can be tricky. I am pretty sure that there was a firmware change for the 2019 iMac and an APFS upgrade. That may well have made a jump backwards tricky if not impossible.

Migration Assistant: I would not expect Migration Assistant in macOS 13.7.8 to be able to migrate from a significantly future version - e.g. macOS 15.x. And possibly made worse by an on disk upgrade of APFS.

The "correct" thing to have done would be to have made a TM backup of macOS 13.7.x and physically disconnected it until you were sure to wanted to stay on Sequoia. In that way you would have been able to restore to macOS 13.7.6 from recovery and the TM disk.

Is your current macOS 13.7.8 able to read your data on the other disks? If so, give up on Migration Assistant and use Finder to copy files to the 13.7.8 disk.
 
gilby101 said:
A jump of 2 major versions can be tricky. I am pretty sure that there was a firmware change for the 2019 iMac and an APFS upgrade. That may well have made a jump backwards tricky if not impossible.

Migration Assistant: I would not expect Migration Assistant in macOS 13.7.8 to be able to migrate from a significantly future version - e.g. macOS 15.x. And possibly made worse by an on disk upgrade of APFS.

The "correct" thing to have done would be to have made a TM backup of macOS 13.7.x and physically disconnected it until you were sure to wanted to stay on Sequoia. In that way you would have been able to restore to macOS 13.7.6 from recovery and the TM disk.

Is your current macOS 13.7.8 able to read your data on the other disks? If so, give up on Migration Assistant and use Finder to copy files to the 13.7.8 disk.
Click to expand...
Thank you Gilby,
I may have misled you. My central complaint was not backward transfer from Sequoia. I knew that cannot be easily done. It was the inability to use Migration Assistant to transfer from 13.7.8. to 13.7.8 that drove me nuts. First a dialogue box told me the OSX version I wished to import from was a later version of 13.7.8 and could not be imported; - which it was not. Then I swapped drives and Migration Assistant simply tells me the transfer cannot be done - no explanation. Just greyed out iMac images as per screenshot I attached.

It annoys me that Apple have wiped ALL versions of Ventura from their servers other than 13.7.8. without any notice to users that I am aware of.

Apple are selling Macs with increasingly restricted flexibility citing the necessity to provide security to users. The unnamed Apple Marketing Manager in the Bombich article stated Apple Restore and Migration Assistant were the key tools to be used in future OSX builds. Fair enough. What was not said is that earlier OSX are being deprecated without notice. For example All editions of Ventura have been removed from the servers and ony 13.7.8 remains accessible. Version 13.7.8 is not accesible to Migration Assistant and recognises data transfer by Time Machine ONLY. Whether this was always the case I do not know. It certainly was not the case for 13.7.6. That now is arguably more problematic as Apple demand user use their downloads only.

I like running duplicate systems in parallel on separate drives. I like the assurance that if a problem arises I can quickly switch drives and keep working. Solving the problem (such as Kernal Panic) can wait until time is available. I have worked this way for 25 years. Earlier I would simply erase and clone a complete OSX from one drive to the other using CCC. Mike Bombich has been helping users do this by navigating Apple policy with great attention for decades.

Castration of Migration Assistant to prevent cloning across drives is a real imposition for me. Mike Bombich also stated in December 2024: Apple made it unambiguously clear that "bootable backups" and System cloning are fundamentally incompatible with platform security.

Clearly what is being lost in the race for optimum security is user flexibility. Perhaps my mindset remains locked into the Steve Jobs ambition to produce the most versatile computer for the user. The G4 epitomised that concept. Yes, we live now in a very different world and security may demand a more restricted machine. Yet a part of me believes Jobs would have provided flexibility AND security.

True, I can still download an OSX installer and create a bootable USB and build the o/s I prefer. But the writing on the wall suggests that freedom may not last very long.
 
Last edited:
gilby101 said:
The "correct" thing to have done would be to have made a TM backup of macOS 13.7.x and physically disconnected it until you were sure to wanted to stay on Sequoia. In that way you would have been able to restore to macOS 13.7.6 from recovery and the TM disk.

Is your current macOS 13.7.8 able to read your data on the other disks? If so, give up on Migration Assistant and use Finder to copy files to the 13.7.8 disk.
Click to expand...
"Correct" method was considered. I was driven more by habit. I did have Ventura 13.7.6 on TM external ssd but discounted it in favor of 13.7.8 thinking the later version would be better. Hence ‘Big Mistake’. Your suggestion would have worked.

Yes data can be read on each disk. Using Finder or CCC to copy files does not include Settings. Only Migration Assistant includes Settings. Alternatively, I must rely upon iCloud and Export Settings from browser and certain other apps, which is slow but works. These have to be re-formatted in respective apps. At least I know they are clean.
 
Terraaustralis said:
"Correct" method was considered.
Click to expand...
My use of quotes was a rather tongue in cheek way of being wise after the event. Disasters happen to us all at times.
Terraaustralis said:
Yes data can be read on each disk. Using Finder or CCC to copy files does not include Settings. Only Migration Assistant includes Settings. Alternatively, I must rely upon iCloud and Export Settings from browser and certain other apps, which is slow but works. These have to be re-formatted in respective apps. At least I know they are clean.
Click to expand...
I can feel for your pain. But relieved that you have not lost anything critical (i.e. your data). Settings can be re-established even where export and import fails.
 
Has anyone had trouble with the onboard camera not able to initialize, as access is locked by the T1?
It seems like this thread is for stream-of-consciousness new posts abut Ventura? If I am in the wrong place I apologize.

This happened after I moved to Ventura from Big Sur 2 months ago.
This is the full bug report I sent in.
Any interesting ways to try and fix is using any of the capabilities of the OpenCore Legacy Patcher (OCLP) as 1.1.0 added explicit support for the T1 Security chip?

Note: What I read is that the T1 chip on the 2017 Macbook Pro works differently from T2 — the DFU restore process via Apple Configurator that's documented all over the web applies to T2 Macs, not this T1 Mac.

-----
FaceTime HD Camera non-functional on Mac Pro 2017 (T1) under macOS Ventura — AppleUSBiBridge holds exclusive USB access, blocking VDCAssistant

Product: macOS Ventura 13.7.8 (22H730)
Hardware: Macbook Pro 2017, Apple T1 Security Chip (firmware 14Y910)

Summary:The built-in FaceTime HD Camera is non-functional under all versions of macOS Ventura. The camera worked correctly under macOS Big Sur. The failure occurs in all camera applications (Photo Booth, FaceTime, Zoom). Symptom is: camera green indicator light activates for 15-20 seconds, then turns off, with no video data delivered to any application.


Diagnostics performed and results:
  • Apple Diagnostics: passed, no error codes
  • System Report / SPCameraDataType: camera present and enumerated correctly as UVC Camera VendorID_1452 ProductID_34304, Unique ID 0x1420000005ac8600
  • SPiBridgeDataType: T1 present, firmware 14Y910
  • SIP status: enabled (normal)
  • Third-party system extensions: none camera-related (only Kensington keyboard driver present)
  • TCC reset (tccutil reset Camera): performed, no effect
  • SMC reset: performed, no effect
  • T1 reset (full power disconnect 30+ seconds): performed, no effect
  • NVRAM/PRAM reset: performed, no effect
  • Non-destructive Ventura reinstall: performed, no effect
  • VDCAssistant / AppleCameraAssistant processes: not running at boot; manual killall confirmed no processes to kill

Kernel extension finding:Apple_iSight.kext (com.apple.driver.Apple_iSight v4.0.1) is present on disk but does not load at boot. Manual force-load via sudo kmutil load succeeds, but camera still fails even with kext loaded. This suggests the kext loading failure at boot is a symptom, not the root cause.

Root cause identified in live log capture:
The following kernel errors appear repeatedly during every camera access attempt, captured via log stream during a Photo Booth session:
<span><span>kernel: (IOUSBHostFamily) VDCAssistant@(null): <br></span></span><span>AppleUSBHostUserClient:😱penGated: failed to open <br></span><span>Apple T1 Controller@14200000: provider is already opened <br></span><span>for exclusive access by AppleUSBiBridge</span>

This error occurs at every point VDCAssistant attempts to open the camera USB controller. AppleUSBiBridge holds the T1 USB controller open exclusively and does not yield access to VDCAssistant.

Following this, the iBridge-side ISP errors appear:
<span><span>kernel: (AppleM8CameraInterface) [iBridge]: <br></span></span><span>ISPCPU: ERR: FlowIC00: Frame done timeout! frameCount = -1. mipi 0<br></span><span><br></span><span>kernel: (AppleM8CameraInterface) [iBridge]: <br></span><span>ISPCPU: ERR: FlowIC00: Perform error recovery (1), fc(0).<br></span><span><br></span><span>AppleUVCCamera: [iBridge]: Streaming have not started in 1 sec, aborting<br></span><span>AppleUVCCamera: [iBridge]: Aborting Streaming</span>

The ISP times out waiting for frames that never arrive because the USB path was never successfully opened.


Conclusion:AppleUSBiBridge exclusively locks the Apple T1 Controller@14200000 USB device at boot and does not release it, preventing VDCAssistant from ever opening the camera. This behavior was not present under Big Sur. This appears to be a regression in how Ventura's iBridge driver manages the T1 chip's USB controller on 2017 Mac Pro hardware, rendering the built-in camera permanently non-functional on an otherwise fully supported machine running the latest available OS.
 
Last edited:
toomanyhandles said:
Hardware: Mac Pro 2017, Apple T1 Security Chip (firmware 14Y910)
Click to expand...
Can you confirm that you mean a MacBook Pro 2017? (there is no Mac Pro 2017).

Wondering aloud: 14Y910 is the correct firmware version for embeddedOS from macOS 12.1 to 13.7.8 https://theapplewiki.com/wiki/Firmware/embeddedOS so would not have been updated by a macOS update from 12.1 or later. But I wonder if it is in some way corrupted.

As I think you are aware there is no DFU mode, and T1 updates are performed by the macOs install or update. I can't find any reference to forcing a reinstall of embeddedOS.

You should boot in safe mode to exclude conflicts with software you may have installed. If it works in safe mode (unlikely I know) then T1 firmware is not the issue.

At some point 🙁 you are going to have to install a clean macOS (possibly with a disk erase) to see if the problem persists. Maybe install to external SSD.
 
Last edited:
oh.
Yes, MacBook Pro 2017.

I left it out of the summary, oop! The onboard camera fails to work in safe mode. IT is just a silent fail though in that the green light doesn't turn on for any length of time. Facetime says no camera detected, I'm not sure if safe mode is supposed to enable those kernal ext etc. I didn't try to load them by hand as I did for real and I didn't scrape safe-mode logs, but I can.

I did find one other post someplace about this issue and the hassle of a wiped drive/ clean install didn't solve it for that user.
 
I am now out of suggestions. Even more not very well informed ones. Just hope someone with more expertise chimes in.
 
toomanyhandles said:
Has anyone had trouble with the onboard camera not able to initialize, as access is locked by the T1?
It seems like this thread is for stream-of-consciousness new posts abut Ventura? If I am in the wrong place I apologize.

This happened after I moved to Ventura from Big Sur 2 months ago.
This is the full bug report I sent in.
Any interesting ways to try and fix is using any of the capabilities of the OpenCore Legacy Patcher (OCLP) as 1.1.0 added explicit support for the T1 Security chip?

Note: What I read is that the T1 chip on the 2017 Macbook Pro works differently from T2 — the DFU restore process via Apple Configurator that's documented all over the web applies to T2 Macs, not this T1 Mac.

-----
FaceTime HD Camera non-functional on Mac Pro 2017 (T1) under macOS Ventura — AppleUSBiBridge holds exclusive USB access, blocking VDCAssistant

Product: macOS Ventura 13.7.8 (22H730)
Hardware: Macbook Pro 2017, Apple T1 Security Chip (firmware 14Y910)

Summary:The built-in FaceTime HD Camera is non-functional under all versions of macOS Ventura. The camera worked correctly under macOS Big Sur. The failure occurs in all camera applications (Photo Booth, FaceTime, Zoom). Symptom is: camera green indicator light activates for 15-20 seconds, then turns off, with no video data delivered to any application.


Diagnostics performed and results:
  • Apple Diagnostics: passed, no error codes
  • System Report / SPCameraDataType: camera present and enumerated correctly as UVC Camera VendorID_1452 ProductID_34304, Unique ID 0x1420000005ac8600
  • SPiBridgeDataType: T1 present, firmware 14Y910
  • SIP status: enabled (normal)
  • Third-party system extensions: none camera-related (only Kensington keyboard driver present)
  • TCC reset (tccutil reset Camera): performed, no effect
  • SMC reset: performed, no effect
  • T1 reset (full power disconnect 30+ seconds): performed, no effect
  • NVRAM/PRAM reset: performed, no effect
  • Non-destructive Ventura reinstall: performed, no effect
  • VDCAssistant / AppleCameraAssistant processes: not running at boot; manual killall confirmed no processes to kill

Kernel extension finding:Apple_iSight.kext (com.apple.driver.Apple_iSight v4.0.1) is present on disk but does not load at boot. Manual force-load via sudo kmutil load succeeds, but camera still fails even with kext loaded. This suggests the kext loading failure at boot is a symptom, not the root cause.

Root cause identified in live log capture:
The following kernel errors appear repeatedly during every camera access attempt, captured via log stream during a Photo Booth session:
<span><span>kernel: (IOUSBHostFamily) VDCAssistant@(null): <br></span></span><span>AppleUSBHostUserClient:😱penGated: failed to open <br></span><span>Apple T1 Controller@14200000: provider is already opened <br></span><span>for exclusive access by AppleUSBiBridge</span>

This error occurs at every point VDCAssistant attempts to open the camera USB controller. AppleUSBiBridge holds the T1 USB controller open exclusively and does not yield access to VDCAssistant.

Following this, the iBridge-side ISP errors appear:
<span><span>kernel: (AppleM8CameraInterface) [iBridge]: <br></span></span><span>ISPCPU: ERR: FlowIC00: Frame done timeout! frameCount = -1. mipi 0<br></span><span><br></span><span>kernel: (AppleM8CameraInterface) [iBridge]: <br></span><span>ISPCPU: ERR: FlowIC00: Perform error recovery (1), fc(0).<br></span><span><br></span><span>AppleUVCCamera: [iBridge]: Streaming have not started in 1 sec, aborting<br></span><span>AppleUVCCamera: [iBridge]: Aborting Streaming</span>

The ISP times out waiting for frames that never arrive because the USB path was never successfully opened.


Conclusion:AppleUSBiBridge exclusively locks the Apple T1 Controller@14200000 USB device at boot and does not release it, preventing VDCAssistant from ever opening the camera. This behavior was not present under Big Sur. This appears to be a regression in how Ventura's iBridge driver manages the T1 chip's USB controller on 2017 Mac Pro hardware, rendering the built-in camera permanently non-functional on an otherwise fully supported machine running the latest available OS.
Click to expand...
I can offer little other than to ask whether upgrading to Sonoma improves the situation given there will be security improvements which may replace T1 chip instruction? Give it a try?
 
Terraaustralis said:
I can offer little other than to ask whether upgrading to Sonoma improves the situation given there will be security improvements which may replace T1 chip instruction? Give it a try?
Click to expand...
Unfortunately Sonoma is not supported on this hardware platform, and while it (Sonoma) supports the T2 macs without requiring the T2- it removes support for the T1 completely, causing a few things to stop working on T1 macs: (Touch Bar, Touch ID, Apple Pay, and password settings. While OpenCore Legacy Patcher (OCLP) offers partial fixes, Sonoma's lack of T1 communication capability means certain encrypted functions may not function correctly).

So even if I managed to find a way to sideload it (I haven't looked at all due to the above) it would result in a pretty crippled laptop. darn!
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back