-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hdiutil failures when creating DMGs on macOS 13 runner #7522
Comments
Hello @wkiefer, we will take a look, however, please remember macOS 13 is still in beta version. |
Hi @wkiefer. I didn't succeed reproducing the issue. Both hdiutil and create-dmg work flawlessly for me. Could you provide more detailed repro steps or share a link to the failing workflow? |
I think we have hit the same issue.
|
Hey @geoffthemedio, @wkiefer. Looks like the issue is gone as an image version 20230509.4 have been rolled out. Could you try to run your workflow again? |
I reran the action and it completed successfully. I'm not sure that nothing else changed and that it's doing the exact same thing, but at least I can reproduce the issue now. |
I think I'm hitting similar issues or at least issues with hdiutil: Runner image:
|
Hi @Neverous. It looks similar indeed. But I suppose you might get this error because of the failure on the previous step:
Could you ensure that it doesn't affect packaging? |
I get the same thing in macos 12: https://github.com/Neverous/efibooteditor/actions/runs/4908677336/jobs/8925056030#step:12:232 and 11: https://github.com/Neverous/efibooteditor/actions/runs/4908677336/jobs/8925056236#step:12:232 and they go through fine so I would guess that it doesn't, but Ill see If I can do anything about it maybe it will help. |
Yeah, the rpath error is just that both macdeployqt and CPack generator that I use to make the final package are trying to adjust rpaths, and both have no option to skip it from what I can tell... I think its harmless, at least for hdiutil. Anyway, I got to very simple reproduction steps I think: https://github.com/Neverous/efibooteditor/actions/runs/4997753556/jobs/8952437874 (the issue seems to be somewhat random as just restarting the job sometimes succeeds and sometimes not 🤔 https://github.com/Neverous/efibooteditor/actions/runs/4997791581) |
Hey. I finally realized what causes this issue. Looks like it's Another option may be shutting aforementioned service down (or just killing the process). You may use something like this: echo killing...; sudo pkill -9 XProtect >/dev/null || true;
echo waiting...; while pgrep XProtect; do sleep 3; done; I can't recommend doing that because it may cause issues in the future that we can't predict and avoid. Also it may have security related consequences. Use it on your own risk. |
Tried both, neither works for me, I must be hitting something slightly different then 🤔 ( |
You a right, Maciej, this is something different. Killing XProtect only helps when you get "Resource busy". I still suspect that previous error may somehow cause failure of hdiutil. I understand that it didn't matter on macOS 11 & 12, but something else may have changed so now it's important. Could you try to get rid of "install_name_tool" error? Just to be sure that it's really nothing. |
Ah should've mentioned that with macdeployqt vs CPack comment, did that (disabled macdeployqt for tests, leaving only cpack dmg generation): Neverous/efibooteditor@e7ec720#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aL410 , https://github.com/Neverous/efibooteditor/actions/runs/4997683758/jobs/8952293026#step:12:234 |
Did you try enabling debug output for hdiutil? |
Don't see anything interesting unfortunately, just that
|
Hey @Neverous. Looks like your issue may be resolved by running hdiutil using sudo. I added this line to
|
Yes, thank you! It works indeed. Interesting, some permissions changed with macOS 13?, not sure why it would now require elevated access 🤔 but it packages successfully now with sudo 🙇 . |
Glad to hear! Well, looks like problems have been solved so i'm closing this issue for now. Feel free to reopen it if problems return. To sum up:
|
…hread regarding this problem: actions/runner-images#7522 apparently running the process as root is one path to a fix. Reverted from e9f03d2 to HEAD.
…nd an issue thread regarding this problem: actions/runner-images#7522 apparently running the process as root is one path to a fix. Reverted from e9f03d2 to HEAD." This reverts commit bd268a1.
<!-- Thank you for your contribution! --> ## What ## Why actions/runner-images#7522 ## How to test your changes?
Same here. Unfortunately, macos-12 seems to be deprecated now. |
I'm still having issues with that. Did anyone find a solution for macOS-13? |
|
If anyone curious, our solution was to keep trying until it works (max 10 times), it seems to work eventually: |
I was curious and tried your retry fix: fredowski/osxbundler@67d668c |
@guihkx (commit) @nuttyartist (comment) , @fredowski (commit), @The-Compiler (commit) thanks for the workaround shares. A bash retry loop is preferable to (e.g.) killing a system daemon with (edit: added links + @guihlx's workaround) |
The macos-13 runner suffers from a bug that causes frequent failures during the DMG build stage. actions/runner-images#7522 We're stuck with the macos-13 runner for the moment because: 1. We need an Intel runner for universal builds and while macos-14-large is Intel, macos-14 is arm. 2. The macos-14-large runner is not free and we keep hitting spending limits (probably because of other repos under the Arelle org). 3. macos-12 is deprecated.
The macos-13 runner suffers from a bug that causes frequent failures during the DMG build stage. actions/runner-images#7522 We're stuck with the macos-13 runner for the moment because: 1. We need an Intel runner for universal builds and while macos-14-large is Intel, macos-14 is arm. 2. The macos-14-large runner is not free and we keep hitting spending limits (probably because of other repos under the Arelle org). 3. macos-12 is deprecated.
Prior to this change, the GHA runs would fail with errors like the following: > CPack: Create package > CPack Error: Error executing: /usr/bin/hdiutil create -ov -srcfolder "/Users/runner/work/etterna/etterna/main/build/_CPack_Packages/Darwin/DragNDrop/Etterna-0.74.0-Darwin/ALL_IN_ONE" -volname "Etterna" -fs "HFS+" -format UDZO "/Users/runner/work/etterna/etterna/main/build/_CPack_Packages/Darwin/DragNDrop/temp.dmg" > CPack Error: Error generating temporary disk image. > hdiutil: create failed - Resource busy Per actions/runner-images#7522 (comment), it seems that this particular failure mode might be caused by the new XProtect service introduced by macOS, and disabling said service can bypass the problem. This is probably not a good long-term fix...
macos-13 runner 固有の問題らしく、何回かリトライ掛けるしかないらしい… (macos-14 arm runner を使っている arm64 ビルドでは問題になっていない) ref: actions/runner-images#7522
Description
We use https://github.com/create-dmg/create-dmg as a small script wrapper around
hdiutil
to create and notarize DMG files from our macOS applications.However, when switching to the
macos-13
runner, we get the following error when callinghdiutil create
Platforms affected
Runner images affected
Image version and build link
Is it regression?
https://github.com/actions/runner-images/releases/tag/macOS-12%2F20230425.1
Expected behavior
hdiutil create
should not return error 49168, resource busyActual behavior
hdiutil create
consistently returns error 49168, resource busyRepro steps
I will try to make a public repo sample repro — right now steps are to build with Xcode 14.3 on the macOS 13 image, then run
Or simply try to run any
hdiutil create
command in the context of a macOS 13 runnerThe text was updated successfully, but these errors were encountered: