Лига Сисадминов

Всем привет. Делюсь своими изысканиями по запуску виртуальных машин MacOS на процессорах AMD. Возможно кому-то будет полезным:
Предыстория: в наличии несколько виртуалок, с которыми долгое время не было никаких проблем. Версии - от Mojave до Monterey, они даже обновлялись штатно. Далее, при апдейте на Ventura/Sonoma ловим кернел панику - никакие рекомендации из интернета не помогли. Глаз пал в сторону хакинтоша, но как его конфигурировать под вмварь тоже оказалось не совсем понятным, поэтому и напишу этот гайд:
вводные - Ryzen 5950X, Windows 10, VMware Workstation 16.2 (была версия 16.0, пока не столкнулись в проблемой апдейта макоси).

Что понадобится (чем пользовался лично я):
OCAT - графический редактор plist
ProperTree - еще одна редачилка plist'a, мне через нее было удобно копипастить блок с патчем для AMD (удобно открыть patches.plist из репы, и выдернуть оттуда весь блок patch, чтоб вставить его в наш конфиг)
Рекомендация по настройке конфига под амуде
Готовые SSDT для нубасов вроде меня (насколько я понял это таблицы с ID оборудования, которое инициализируется при старте ОС. Что-то подобное можно создавать самому уже на конкретном железе. У меня стоял вопрос - а каким оно должно быть и как его создать на VMware, возможно кто-то из шарящих в теме пояснит в комментах, как это работает, и как это связано с DSDT таблицами)
Гайд по EFI драйверам и кекстам - по кекстам я ниже еще отпишу. А драйвера я оставил все, которые идут с редакцией OpenCore, но не все они обязательны.
Ну и загрузчик OpenCore собственной персоной
Кастомный .vmdk диск, с которого мы будем бутаться. (создаем сами)
Выкладываю свою версию EFI - для ЛЛ, но не факт, что именно с ней у вас все взлетит.

Теперь по OpenCore, что он из себя представляет:
Нас интересует версия X64, внутри есть папка EFI, ее в дальнейшем нужно будет закинуть на наш загрузочный раздел. При включении нашей виртуалки первым делом бутается /EFI/BOOT/BOOTx64.efi, который затем запускает /EFI/OpenCore.efi (если вы будете в firmware виртуалки указывать файл загрузчика, указывайте путь к BOOTx64.efi)
Что еще внутри папки EFI :
EFI/OC/ACPI - тут лежат SSDT/DSDT таблицы оборудования. Если удалять лишнюю, обязательно нужно проверить, чтоб не было ссылок на нее в config.plist иначе будет краш.
EFI/OC/Drivers - тут лежал драйверы .efi. OpenRuntime.efi и HfsPlus.efi обязательны, я не стал удалять лишние драйвера, но ради интереса поигрался и выяснил, что без OpenCanopy.efi, OpenLinuxBoot.efi, OpenLegacyBoot.efi - загрузчик не взлетал. Насколько я понял, эти драйвера не влияют на дальнейшую работу макоси, а сугубо отвечают за работоспособность загрузчика и его возможности.
EFI/OC/Kexts - тут валяются расширения ядра (kext - kernel extension), нужны для успешного запуска самой макоси, а так же для корректной инициализации и работы устройств.
Любой хакинтош начинается с Lilu.kext, затем должен идти фейковый SMC (я заводил тачку с VirtualSMC.kext), потом уже все остальное.
Их последовательность определяется конфигом config.plist, в каком порядке они указаны, в таком они и будут инжектиться при загрузке ОС.
Экспериментальным путем выяснено, что система не бутается без:
AppleMCEReporterDisabler.kext - Required on macOS 12.3 and later on AMD systems, and on macOS 10.15 and later on dual-socket Intel systems. *из доки по OpenCore
CryptexFixup.kext - Я так понял, что это обязательный кекст не только для AMD, но и для Intel до Haswell
NoAVXFSCompressionTypeZlib-AVXpel.kext - возможно избыточно, без него тоже бутается.
На всякий случай оставил:
VoodooHDA.kext - инициализация звука в MacOS
HibernationFixup.kext - на виртуалке проще отключить сон, но если что, возможно это будет фиксить. Дело в том, что под хакинтошами у макоси есть проблемы со сном, вернее с выходом из него)
Whatevergreen.kext - фикс инициализации графики, по идее он не нужен, т.к. есть VMWARE tools

Создаем свой .vmdk:
Для его создания я создавал новую виртуалку, "установлю потом", тип системы other, диск 0.2GB, но вмварь тогда создает диск IDE, поэтому я его удалил, и пересоздал уже как SATA. Размер выбрал с потолка, сам EFI весит около 10-15 МБ. Поэтому можете назначить меньше. Из доп. настроек нужно выбрать store virtual disk as a single file
Далее монтируем этот диск через Daemon Tools. Теперь открываем оснастку управления дисками, для этого жмем WIN+R, вводим diskmgmt.msc и enter, система тут предложит проинициализировать новый диск. Выбираем GPT, жмем ОК. Далее создаем том и форматируем в FAT32, в Label вписываем любой удобный и понятный, я так и назвал OpenCore.
Все, теперь осталось закинуть на диск папку EFI, размонтировать диск и можно с него бутаться.

Несовместимость виртуалки и vmdk диска (если подкидываем к уже готовой машине)

При попытке подсунуть загрузочный vmdk в виртуалку, которая была создана в более старой версии VMware скорее всего вылезет ошибка:

Варианта 2: либо пересоздавать новый vmdk для этой виртуалки, форматить его и засовывать туда EFI
либо конвертнуть виртуалку:
жмем по ней правой кнопкой мыши → manage → Change Hardware Compatibility
Мой первый EFI был создан в версии 16.2.x, поэтому выбираю ее, чтоб версия совпадала с той, в которой он создавался. Далее вмварь спросит, хотите склонировать или конвертировать текущую билд-тачку. Тут уже на ваше усмотрение, у меня с конвертацией проблем не возникло, но я не уверен, что их точно не будет.
После конвертации диск подцепится без ошибок)

Что дальше?
Отныне любая макось, будь то инсталлер или уже установленная версия - должны запускаться только через наш кастомный EFI. Иначе в дальнейшем у них будет паника ядра.
С чистой установкой все просто: (не буду останавливаться на том, как создать новую ВМ, как пропатчить ее unlocker'ом, как создать диск, выделить ресурсы и т.д.)
Добавляем в виртуалку наш EFI, в настройках смотрим на какой порт сата он добавился (можно сделать SATA 0:0, а можно забить - на ваше усмотрение.
В виртуальный CD добавляем .iso образ установщика макоси (можно взять с торрента, либо зашить самому, но для этого нужен отдельный гайд).
Далее в VMware выбрать Power on firmware

После этого у нас будет возможность бутануться с нужного диска, тут нам и понадобиться номер порта SATA

Выбираем диск, жмем Enter.
Далее мы попадаем в меню OpenCore:

Если нажать пробел, появятся дополнительные опции загрузки

Бутаем установщик и далее штатно проходим установку (не забываем запустить дисковую утилиту в установщике и отформатировать наш целевой vmdk в формат APFS).

Для тех, кто хочет обновить свой старенький Monterey
У вас варианта два, либо обновляться штатно, через Software Update, либо обновляться с iso (точно так же, как чистая установка в абзаце выше, но без форматирования целевого диска)
Правило одно в обоих случаях - перед апдейтом, вы должны обязательно бутаться с кастомного загрузчика. Если макось словит Kernel Panic в процессе обновления (она несколько раз рестартится пока идет процесс обновления), то ее попердолит так, что даже с подсунутым EFI она не будет бутаться.
Перед апдейтом можете снять снапшот, откат поможет в случае если что-то пойдет не так.

Какие могут быть проблемы

• Если макось в процессе рестартов установщика загрузится не через OpenCore, а напрямую, и словит панику - ее уже будет не восстановить. (выше уже писал об этом, но лучше задублирую - это важно!)

• Если после успешной загрузки макоси не работает мышь/клава, либо у мыши очень высокая чувствительность, что невозможно ею пользоваться - нужно проверить в настройках виртуалки версию USB контроллера. Должна быть 3.1.
  доп. может понадобиться VoodooPS2Controller.kext

• Проброс Bluetooth лучше убрать (там же, где настройки USB)

• Перед изменением количества ядер, выделенных виртуалке, лучше править патчи в config.plist на EFI разделе. Иначе тачка будет вставать в фриз: Патчи для AMD
  Без них будут проблемы. У меня зависало, если выделял больше 4х ядер.
  "C:\Program Files (x86)\VMware Workstation\vmrun.exe" -T ws stop "путь к виртуалке.vmx"

  • ОБЯЗАТЕЛЬНО ОТКЛЮЧИТЬ TSO https://communities.vmware.com/t5/VMware-Fusion-Discussions/VMware-Fusion-Only-Upload-Internet-Speed-is-Super-Slow-compared/td-p/2955386
    sysctl net.inet.tcp.tso=0 и для того, чтоб работало после рестарта - создать файл /etc/sysctl.conf и вставить «net.inet.tcp.tso=0»
    Если этого не сделать, то не будет работать VNC/SCP/загрузка файлов на самбу, может что-то еще (очень низкая UPLOAD скорость для TCP соединений)
    

• И НЕ ЗАБЫВАЕМ, ЧТО В VMX конфиг нужно прописать
  

  cpuid.0.eax = "0000:0000:0000:0000:0000:0000:0000:1011"
  cpuid.0.ebx = "0111:0101:0110:1110:0110:0101:0100:0111"
  cpuid.0.ecx = "0110:1100:0110:0101:0111:0100:0110:1110"
  cpuid.0.edx = "0100:1001:0110:0101:0110:1110:0110:1001"
  cpuid.1.eax = "0000:0000:0000:0001:0000:0110:0111:0001"
  cpuid.1.ebx = "0000:0010:0000:0001:0000:1000:0000:0000"
  cpuid.1.ecx = "1000:0010:1001:1000:0010:0010:0000:0011"
  cpuid.1.edx = "0000:0111:1000:1011:1111:1011:1111:1111"

  ethernet0.virtualDev = "vmxnet3"

UPD: вынесу отдельно: из непофикшеного есть проблема с рестартами виртуалки. Она успешно останавливает систему и повисает

Прибить ее можно из командной строки (путь до vmrun.exe может отличаться:
"C:\Program Files (x86)\VMware Workstation\vmrun.exe" -T ws stop "путь к виртуалке.vmx"

Первый пост, с почином меня, стало быть)
Решил ответить постом, т.к для комментария будет много текста.

Часть 1. Как устроена обычная техподдержка и как с ней работать. (здесь не пойдет речь про изначальный пост сисадмина, так что кому не интересно можете пропустить)

Я проработал в техподдержке 3 года и еще сколько то месяцев, прошел путь от первой до третьей линии поддержки иностранных клиентов, а затем до системного аналитика. Для тех кто не понял, что за линии - объясню кратко. В техподе есть обычно три линии:
1) первая линия - говорящие скрипты, т.е люди, которые не имеют технических, компьютерных и т.д навыков, разве что "уверенный пользователь ПК". Но они знают продукт, который выпускает компания, во всяком случае должны знать. Задача этих спецов - получить от клиента описание проблемы, предложить решение из списка возможных и составить заявку, чтобы ее, если что можно было передать на более опытных спецов.
И они могут помочь. Да, вы можете сколько угодно смеяться над "перезапустите компьютер", но это помогает в большинстве случаев. И это реально проще чем объяснять неопытному юзеру такую банальную вещь, как перезапустить службу, а при перезапуске компа - служба перезапустится (у служб наших ПО всегда стоял автозапуск если что)

2) вторая линия - это спецы, которые уже не только разбираются в продукте компании, но и обладают некоторыми общими знаниями в айти, своего рода эникейщики, т.е знают например, что такое API и как сделать JSON-запрос, простые SQL-запросы, журнал винды смогут просмотреть и найти там причину, некоторые нетрудные админские вопросы порешать, например сделать проброс портов, настроить RemoteApp для приложухи.

3) третья линия - уже опытные спецы, которые в свободное от техподдержки время, когда задач немного привлекаются для работы в других отделах, ну т.е каждый такой специалист имеет знания в определенной области хотя бы на уровне уверенного джуна. И соответственно привлекается для задач по тестированию или может привлекаться для внедрения, как аналитик и т.д. Т.е это по сути переходная стадия от техподдержки до более узкоспециализированного профессионала (тестировщика, разраба, сисадмина и т.д). Во всяком случае так у нас в компании.

Резюмируя сказанное:
1) Работая с техподдержкой описывайте инфу по возможности баг-репортом (описание, сценарий возникновения, фактический итог, желаемый итог, скрины, версия вашей программы (если знаете))
2) Работайте через эл.почту, я прекрасно понимаю, что "Эй, мы же в 21 веке живем", что мессенджеры или общение голосом удобнее, но по этой причине ваши заявки могут быть не созданы или не отслеживаться руководителем техпода.
Т.е например звонки записываются, но чтобы прослушать звонок, который может идти больше получаса руководителю поддержки придется потратить много времени, имейте в виду, что это и ваше время, т.к чем дольше в вашем вопросе будут разбираться, то тем дольше ваша проблема будет нерешенной. За день специалисту может поступать очень много звонков и он просто может не успеть/забыть создать заявку по звонку, таким образом ваше обращение будет сложнее найти и отдать более опытному специалисту.
С чатами такая же ситуация, их труднее отслеживать чем письма. А вот все письма отрабатываются через HelpDesk, не буду описывать что это, но короче говоря руководитель техпода или любой другой специалист всегда может увидеть заявку другого и самое главное при обращении через почту - заявка ВСЕГДА создается автоматически. А значит, если руководитель техпода/разрабов/фирмы увидит, что заявка не решается или требуется более высокий уровень компетенции, то просто передаст ее на другую линию или другой отдел. Такой вот парадокс, что позвонить или написать в мессенджер удобнее, но именно для решения вопроса удобнее электронная почта.

Извините, что загрузил вас этой информацией, но это необходимо, чтобы вы понимали как организована работа техподдержки и как с ней работать, чтобы всем было комфортно.

Часть 2. Разбор обращения сисадмина с точки зрения специалиста техподдержки.

Так вот теперь я хочу рассказать как со стороны техподдержки могло выглядеть обращение сисадмина, ведь с похожими ситуациями сталкивался и я не раз. Автор пишет, что было "подробное описание проблемы". Зачастую это подробное описание со стороны пользователей, а по факту данных необходимых для анализа проблемы там просто нет, короче для техподдержки подробное описание это баг-репорт.
Т.е не только описание проблемы, но и сценарий при котором она возникла/возникает, что именно происходит (тут как раз скрины будут к месту), что должно было быть вместо этого, версия продукта, а также по возможности логи, бэкапы, профилирование и т.д. Понятно, что от юзера нельзя это все требовать, но если этого не было, то считать это подробным описанием нельзя и техпод будет уточнять информацию. Я сейчас не говорю, что автор врет, когда говорит, что дал подробные данные (я этого не знаю, а раз он сисадмин, то скорее всего действительно дал максимально подробно инфу, вышеизложенное скорее для вас, для понимания, что такое подробное описание).

Техпод ответил, что у них все работает. Да в контексте проблемы это звучит смешно, но ситуации когда проблема на стороне юзера не редкость. Ситуация: есть интернет-магазин, он обновил логотип на сайте, но по факту логотип не обновился, конечно клиент звонит в техпод сайта и матерится, а дело оказывается в том, что он не почистил кэш. Или другой пример, звонит клиент и говорит, у меня сайт стал резко тормозить, че вы там натворили?! Техпод смотрит в мониторинг типа Grafana, но не видит там большой нагрузки, естественно он скажет, что проблема на стороне клиента, а там может быть что угодно, например куча вкладок, грузящих память и т.д.
Техпод отправляет инструкцию, что можно и нужно проверить. Тут автор говорит, что "инструкция = КГ/АМ", но не объясняет подробно почему. Якобы там только два пункта: "1. Обратитесь в техпод. 2. Обратитесь к разрабам". Честно говоря слабо верится. Нет, конечно бывают очень тупые инструкции, но в столь откровенный посыл нахуй мало верится. Да и вообще обычно техподдержка всегда сама контактирует с разрабами, иногда менеджер клиента, но я нигде не видел, чтобы клиент контактировал с разрабами, ну разве что в совсем маленьких фирмах и стартапах, где разрабы сами занимаются техподдержкой.

Затем автор собирает консилиум из админов и они решают вопрос и вот тут странность. Если они решили вопрос сами, то высока вероятность, что проблема была реально на их стороне. Объясню почему:
1) Фирмы зачастую берегут свой софт и полный доступ к исходникам программы не дают, т.е если проблема в коде, то поправить ее самостоятельно юзер, каким бы он продвинутым не был - поправить не сможет.
2) Большинство проблем на стороне поставщика продукта могут решить только сами разрабы/техпод и т.д. Например, если это сайт, то клиент имеет зачастую очень ограниченный доступ на сервер, где этот сайт крутится и единственное, что может - это загружать картинки/файлы в отдельную папку. Это сделано, чтобы юзер по незнанию или злому умыслу не загрузил какой-то зловред.
И еще много причин. Поэтому я склонен не доверять автору.

Ну и затем следует ситуация, когда техпод вымогает от автора отчет о том как он решил. Вот тут вообще подозрительно. Обычно техпод только рады сами закрыть заявку, чтобы она не висела мертвым грузом и не портила статистику, показатели. Требовать описать способ решения проблемы могут лишь в том если автор решил как то не очень законно или подозрительно, например каким-то образом получил доступ к исходному коду и т.д.

Короче, я тоже многое предполагаю и моя аргументация по сути ничего не стоит, т.к фактов я не знаю. Может там реально охреневший от наглости техпод, но я бы хотел, чтобы автор дал более детальное описание. Хотелось бы больше конкретики. Техподдержку часто ругают, и обычные юзеры и такие вот продвинутые, типа "Смотрите какая тупая техподдержка, а я вот админ/разраб с корешами собрался, да программу переписали по-быстренькому", а на самом деле ситуаций, когда пользователь не признает проблему на своей стороне тоже немало.