msfconsole fails to start due to circular symlink in /usr/lib/llvm-18/build/

[S3ntinelSec]

Environment: MacBook Air M4 (Tahoe 26.3), Docker version 29.2.1, build a5c7197

Symptom: Attempting to run msfconsole -q produces the following output:

/usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/path_scanner.rb:91:in `scan_dir': Too many levels of symbolic links - opendir @ /usr/lib/llvm-18/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/Debug+Asserts/build/include/llvm-c (Errno::ELOOP)
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/path_scanner.rb:91:in `native_call'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/path.rb:76:in `entries'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/cache.rb:170:in `block (2 levels) in unshift_paths_locked'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/cache.rb:163:in `reverse_each'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/cache.rb:163:in `block in unshift_paths_locked'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/store.rb:53:in `block in transaction'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/store.rb:52:in `synchronize'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/store.rb:52:in `transaction'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/cache.rb:162:in `unshift_paths_locked'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/cache.rb:113:in `block in unshift_paths'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/cache.rb:113:in `synchronize'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/cache.rb:113:in `unshift_paths'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/change_observer.rb:22:in `unshift'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/railties-7.2.3/lib/rails/application.rb:405:in `add_lib_to_load_path!'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/railties-7.2.3/lib/rails/application.rb:75:in `inherited'
	from /usr/share/metasploit-framework/config/application.rb:38:in `<module:Framework>'
	from /usr/share/metasploit-framework/config/application.rb:37:in `<module:Metasploit>'
	from /usr/share/metasploit-framework/config/application.rb:36:in `<top (required)>'
	from /usr/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
	from /usr/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in `require'
	from /usr/share/metasploit-framework/config/environment.rb:2:in `<top (required)>'
	from /usr/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
	from /usr/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in `require'
	from /usr/share/metasploit-framework/lib/msfenv.rb:28:in `<top (required)>'
	from /usr/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
	from /usr/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
	from /usr/share/metasploit-framework/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.22.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:33:in `require'
	from /usr/bin/msfconsole:21:in `<main>'

Workaround: Purge the LLVM build directory rm -rf /usr/lib/llvm-18/build then open msfconsole

[PalinuroSec]

@danterolle we noticed strange things going on with the arm64 builds where some system files did get somehow corrupted while the build process unpacked their packages. for instance golang was unable to compile because some of its files were corrupted, and the solution was to force-reinstall a couple of go dependencies.

my plan to solve this is to cross-build the arm images on a different hardware

[danterolle]

Hello @S3ntinelSec! Thank you for this report. I will look into it. For next issues, if any, concerns Docker containers, please post them here -> https://gitlab.com/parrotsec/build/containers

[danterolle]

Hello @S3ntinelSec, based on the latest updates, the issue on UTM does not seem to have reoccurred. If it happens again, please open another issue regarding it. Thank you!