Eu encontrei isso de acordo com o meu problema neste tópico: A
inicialização trava na tela cinza (mesmo ao inicializar a partir da unidade USB com uma nova instalação do OS X)
Meu MacBook Pro 15 "No início de 2011, com o AMD Radeon HD 6750M, exibiu corrupção de tela e falhas / redefinições do sistema associadas por um período de duas semanas antes de falhar completamente na inicialização. A inicialização progredia na tela cinza com o logotipo e o botão rotativo da Apple, apenas quando parece que deveria ter mudado para a tela de login, o logotipo e o botão giratório da Apple desapareciam e ficavam pendurados em uma tela cinza em branco.
Inicialmente, suspeitei de corrupção no disco rígido e tentei remediá-lo. Sem sucesso, tentei o seguinte, com cada um continuando travado, conforme descrito acima:
Inicialização segura Inicialize na recuperação (incluindo a Recuperação da Internet)
Inicialize a partir da mídia de instalação na unidade USB
Inicialize na instalação do OS X na unidade USB
Limpar NVRAM
Redefinir SMC
Também executei o Apple Hardware Test muitas vezes sem encontrar nenhum problema.
A inicialização segura e detalhada (Cmd + Shift + V) produz tudo o que eu esperaria ver, mas que seria interrompido conforme descrito acima.
Depois de encontrar mais posts on-line nos fóruns de discussão da Apple sobre problemas relacionados à GPU, revisei isso como a causa:
2011 MacBook Pro e placa gráfica discreta ou 2011 MacBook Pro e placa gráfica discreta
Tentando inicializar o Ubuntu a partir de uma unidade flash USB, eu só conseguia chegar ao GRUB. Ao tentar inicializar o Ubuntu Desktop ou executar o teste gráfico no GRUB, o sistema trava.
Nesse ponto, a execução do Apple Hardware Test estava suspensa pouco antes do final do teste padrão, possivelmente [suposição] ao fazer um teste de vídeo.
Com base nos conselhos das postagens de discussão da Apple acima, fiz o seguinte:
Inicializar no modo de usuário único
Execute os seguintes comandos:
/sbin/fsck -fy /
/sbin/mount -uw /
mkdir /Disabled_System_Library_Extensions
cd /Disabled_System_Library_Extensions
mv /System/Library/Extensions/ATI* .
mv /System/Library/Extensions/AMD* .
touch /System/Library/Extensions
exit
Desta vez, a máquina inicializou completamente. No entanto, os gráficos são extremamente lentos, mesmo transições ao minimizar janelas. Vou levar meu MBP para a Apple para exigir uma substituição, pois o grande número de relatórios de outras pessoas que enfrentam problemas semelhantes faz com que pareça uma recorrência de uma falha semelhante relacionada à GPU que resultou em uma recuperação.
Mas quando eu uso o comando "mv", os arquivos não são movidos (nem excluídos) e isso me mostra:
Sandbox deny (01) file-write-unlinkink…
Qualquer solução ?
Respostas:
Antecedentes e explicações
Leia toda esta postagem pelo menos uma vez do início ao fim antes de executar qualquer ação.
Todos os profissionais MacBook de 2011 têm um sério defeito de design . O gerenciamento térmico e o calor gerado, juntamente com a robustez dos chips gráficos discretos da AMD, não combinam muito bem. A Apple sabia disso e agia como um típico Smith e sabão , só reagindo a isso depois de um ultraje. Esse escândalo assumiu o nome de RadeonGate. Somente com uma ação judicial ameaçada, a Apple finalmente foi pressionada a oferecer o chamado "Programa de Extensão de Reparo" .
O programa Apple Repair Extension não está mais disponível . A única maneira real de corrigir esse problema é substituir o chip AMD sozinho. Não é a placa lógica. Não é "re-balling", não "reflowing", não "baking". A Apple substituiu um chip com falha por um chip com falha. E outra vez. Apenas substituir o chip gráfico ainda é um procedimento de hardware caro para um laptop tão antigo.
A única maneira conhecida - ou seja: apenas com software - para obter um MacBook Pro 2011 (8,2) com 'only' um chip gráfico AMD com falha, para ligar quase de forma confiável novamente, inicializar no macOS e ser bastante utilizável com uma GUI acelerada é este guia ou uma variação dele. A maioria das dicas anteriores acabou de remover todos os AMD-kexts e isso resulta em uma experiência horrível para o usuário, sem nenhuma aceleração da GUI.
É necessário conhecer sua versão exata do sistema operacional. O guia a seguir será mais simples para Yosemite, mas assume El Capitan ou mais recente. El Capitan, Sierra e High Sierra precisam do SIP (System Integrity Protection) desativado. Nos sistemas anteriores (10.6-10.10), essas etapas são desnecessárias.
Importante: Este guia assume ainda que todos os kexts ainda estão em seu local padrão / Sistema / Biblioteca / Extensões. Ter todos os AMD-kexts lá, exceto um, é benéfico para a operação 'adequada'. Os hacks anteriores nessa direção podem ter instruído você a se mover, ou pior: remova todas as extensões de kernel AMD * / ATI *. Se for esse o caso: mova os kexts de volta para o local padrão ou reinstale o sistema de sua escolha. A maioria dos kexts da AMD e o X3000-kext carregado com um atraso permitirão o gerenciamento de energia da GPU, que de outra forma queimará eletricidade por nada (e pode acelerar a morte final por calor do chip). Para reiterar: Apenas o arquivo
AMDRadeonX3000.kext
realmente está ausente na inicialização para permitir uma inicialização bem-sucedida, mas todos os outros drivers AMD (necessários) devem estar em seu local padrão e o X3000-kext carregado posteriormente / atrasado para retornar a um domínio de gerenciamento de energia e temperatura quase sensato.Ignorando o chip gráfico discreto
Para recuperar a aceleração da tela, será necessário forçar a máquina a não inicializar em gráficos discretos (dGPU), mas diretamente nos gráficos integrados (iGPU) e permanecer nesse modo.
Inicializar no modo dGPU é o padrão em Macs com duas placas gráficas selecionáveis. O procedimento abaixo definirá uma variável NVRAM que desativa a dGPU e força o sistema a usar apenas os gráficos integrados da Intel, mesmo durante a inicialização.
A variável NVRAM não é documentada, mas parece ser universalmente aplicável a todos os Macs com duas placas gráficas comutáveis. Isso significa que ele deve funcionar em iMacs e MacBook Pros. Se eles têm chips AMD ou NVIDIA. As especificidades sobre os drivers que podem ser necessários para mover apenas abrangem a AMD neste guia. Mas a variável NVRAM ignorará o chip gráfico discreto em qualquer caso.
Isso devolverá sua máquina - mas você perderá alguns recursos: por exemplo, a capacidade de direcionar um monitor externo a partir do DisplayPort, um pouco de desempenho 3D. As conexões de dados Thunderbolt devem funcionar.
Caso este guia falhe ou não seja mais desejado: esse procedimento é pura configuração de software e, portanto, totalmente reversível a qualquer momento, com simples redefinição da NVRAM .
O procedimento inicial:
Parte 1: Desabilite o SIP, desative o dGPU, mova uma extensão do kernel
Para começar de uma forma limpa: redefina o SMC e a NVRAM:
desligamento, desconecte tudo, exceto a energia, agora segure
leftShift+ Ctrl+ Opt+ Power
e libere tudo ao mesmo tempo;
Agora ligue novamente e segure
Cmd+ Opt+ p+ r
ao mesmo tempo até ouvir o toque de inicialização duas vezes.
Inicialize na recuperação de usuário único, mantendo
Cmd+ r+s
Desativar SIP: digite:
csrutil disable
desative o dGPU na inicialização definindo a seguinte variável:
nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
ative o modo de inicialização detalhado:
nvram boot-args="-v"
reinicie no modo de usuário único, mantendo pressionado
Cmd+ s
na inicialização
montar partição raiz gravável
/sbin/mount -uw /
crie um diretório kext-backup
mkdir -p /System/Library/Extensions-off
mova apenas UM kext ofensivo para fora do caminho:
mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/
informe o sistema para atualizar seu kextcache:
touch /System/Library/Extensions/
reinicie normalmente:
Agora você deve ter uma tela acelerada de iGPU, mas o sistema não sabe como gerenciar a energia do chip AMD com falha. (Nesse estado, a GPU sempre fica ociosa com energia relativamente alta, consumindo bastante bateria quando desconectada e levando a temperaturas da GPU de 60 ° C para cima [em média 60-85 ° C], apesar de não ser usada para nada pelo sistema .)
Parte 2: melhorar o gerenciamento térmico e de energia
Para melhorar o gerenciamento de energia da GPU desativada, você deve carregar manualmente o único kext crucial após a inicialização:
Se você possui um aplicativo de sensor de temperatura, convém abri-lo antes de emitir o comando acima e observar a temperatura cair…
Automatize isso com o seguinte LoginHook que será executado após a próxima reinicialização:
com o seguinte conteúdo:
então torne-o * 1 executável e ativo:
* 1: O uso não documentado desse comando pmset parece melhorar o comportamento de suspensão / ativação / desligamento. Caso contrário, experimente deixá-lo de fora.
Veja Isenção de responsabilidade abaixo. O que se segue é apenas especulação: dormir / acordar / desligar pode permanecer problemático. A teoria aqui é que "algo corrompe lentamente" o que é salvo no SMC. Portanto, redefinir o SMC e reaplicar a variável hack parece aliviar a situação por um tempo. (Soluções permanentes para essa bem-vinda!) Como soluções alternativas em pouco tempo, você pode tentar evitar o "sono de fechamento da tampa", que parece causar mais problemas do que outros métodos (Apple-Menu, Keyboard-Shorcut). As trocas aparentes no desligamento geralmente são atrasos muito longos que serão encerrados, eventualmente, de maneira limpa e bem-sucedida.
Amostras não científicas sugerem que Yosemite é pior para isso e El Capitan e Sierra se comportam muito melhor nesse sentido.
O carregamento atrasado manual ou de outra maneira dessa extensão crucial do kernel permite que o sistema lide com o gerenciamento de energia um pouco melhor. A bateria será menos usada e as temperaturas emanadas da GPU não utilizada cairão para uma faixa significativamente abaixo de 50 ° C (em média entre 15-50 ° C).
Para um gerenciamento de energia adequado, o conjunto mínimo de kexts carregados está na inicialização (versões para 10.12.6, verifique com
kextstat | grep AMD
):E se o método de carregamento acima for bem-sucedido, isso deverá aparecer adicionado à lista:
Uma etapa final é reiniciar novamente no SingleUserRecovery
Faça isso com Cmd+ r+ s
após a linha de comando se tornar ativa, digite:
e reinicie normalmente.
Isso esfriará o dGPU um pouco mais.
É imperativo emitir esse comando do SingleUserRecovery, pois o sistema com o SIP ativado bloqueará suas tentativas de definir essa variável quando inicializado a partir do volume de inicialização normal, seja no modo de inicialização completa normal ou no SingleUser comum. É importante observar que essa etapa não pode ser facilmente integrada ao script force-iGPU.sh (que você criará em um minuto) e deve ser repetida por si própria após uma redefinição da NVRAM.
Esta última etapa pressupõe que SystemIntegretyProtection foi reativado. Mas se o SIP for intencional e permanentemente impedido, essa etapa poderá ser integrada no script force-iGPU.sh acima.
Mas como, de alguma forma, eu pretendia manter o SIP desativado permanentemente e ele foi ativado novamente sem que eu notasse, a dependência de o SIP permanecer "desligado" pode não ser a melhor abordagem. A limpeza da NVRAM, onde as configurações do SIP são armazenadas, pode ser um desses distúrbios imprevistos.
Medidas preventivas para uso futuro
Há mais duas advertências a saber: Isso é reversível quando o SMC / NVRAM é redefinido. Se isso acontecer, a variável NVRAM da GPU-power-pref pode ou deve ser definida novamente para forçar o uso da iGPU desde o momento da inicialização.
Como isso pode acontecer com bastante facilidade (e muitas vezes é recomendado erroneamente muitas vezes do que é realmente útil), você provavelmente deve se preparar para esse cenário e criar um script simples para acelerar bastante o processo e também fazer com que a variável necessária seja muito menos propenso a erros:
- Digite o seguinte conteúdo para este arquivo:
- Agora torne esse executável:
No futuro, quando o SMC / PRAM / NVRAM for redefinido para os valores padrão, agora é possível inicializar no SingleUser com:
Cmd+s
- E depois de montar a leitura e gravação do volume de inicialização para executar apenas esta linha:
Lembre-se de que a variável agc agora também é limpa. (Veja acima)
Além disso, certifique-se de definir o volume de inicialização padrão novamente em Preferências do sistema> Disco de inicialização.
Parte 3: Manipulando atualizações da Apple
Essa configuração agora possui um kext em um local que os instaladores da Apple não esperam. É por isso que neste guia o SIP não foi reativado. Se uma atualização que contém alterações nos drivers da AMD estiver prestes a ocorrer, é recomendável voltar o AMDRadeonX3000.kext para o local padrão antes do processo de atualização. Caso contrário, o atualizador grava pelo menos outro kext de uma versão diferente em seu local padrão ou, na pior das hipóteses, você acaba com um estado indefinido de drivers parcialmente não correspondentes.
Após qualquer atualização do sistema, a pasta / Sistema / Biblioteca / Extensões deve ser verificada quanto ao kext incorreto. Sua presença lá levará, por exemplo, a uma trava de inicialização em Yosemite e Sierra, um loop de superaquecimento em High Sierra.
A atualização para o High Sierra 10.13: com esse hack no local é quase direta: apesar de aplicar uma atualização de firmware, o processo de instalação não deve tocar na variável NVRAM. O processo de instalação também não usa um chip AMD totalmente acelerado, mas a aceleração básica que não é problemática em relação a esse hack. No entanto, conforme observado no parágrafo acima, a primeira inicialização em um sistema que terminou de instalar, mas está prestes a iniciar o processo de instalação, produzirá um loop de inicialização induzido por aquecimento / falha. A extensão ofensiva do kernel deve ser movida novamente como descrito acima. (Começando na Etapa 3) Depois de mover o kext, tudo ficará bem.
Atualizações recentes da Apple: Não atualize antes de ler o seguinte.
Até novo aviso:
atualizações recentes quebram a máquina novamente. Ele atualiza o firmware, RecoveryPartition, parece desativar a possibilidade de inicializar no SingleUserRecoveryMode
e, ainda por cima, instala - mesmo com o DeltaUpdate - um AMDRadeonX3000.kext funcional!
Sem preparação e com apenas a máquina em mãos, você ficará um pouco preso.
Caso o SingleUserRecoveryMode acabe definitivamente, use RecoveryMode regular. Os resultados são os mesmos, é um pouco mais lento para inicializar: o procedimento acima ainda é válido e mais rápido para todas as versões anteriores do Mac OS X / macOS.
Mas se você atualizar para 10.13.6 ou posterior:
precisará substituir as instruções para SingleUserRecoveryMode ( Command+ r+ s) por RecoveryMode regular ( Command+ r) e desativar o SIP via Terminal ( exemplo para este caso de uso preciso ).
Caso você pertença àqueles em que mesmo o RecoveryMode regular não funcione conforme o esperado:
Soluções alternativas para a incapacidade de desativar o SIP com o SingleUserRecovery:
Primeiro, inicialize no modo de recuperação de usuário único. As edições do csrutil não são permitidas neste modo, mas podem definir a propriedade nvram gpu-power-prefs. Isso ajudará a reiniciar a máquina no modo de recuperação. Em seguida, você deve substituir as instruções do SingleUserRecoveryMode ( Command+ r+ s) pelo RecoveryMode regular ( Command+ r) e desativar o SIP via Terminal ( exemplo para este caso de uso preciso ).
Antes de atualizar, prepare um volume inicializável. Isso pode ser um disco externo ou um stick. Qualquer versão que inicialize a máquina ficará bem. Essa unidade pode ser criada em outro Mac.
Lembre-se de que na unidade externa o AMDRadeonX3000.kext também precisa ser (re) movido. Tente inicializar a partir dessa unidade. Somente se isso funcionar conforme o esperado e você puder montar sua unidade interna: reinicie a partir da unidade interna e continue com a atualização da unidade / sistema interno para 10.13.6.
Depois que a atualização estiver quase concluída, uma reinicialização será interrompida. Force um desligamento e reinicie a partir de sua unidade externa. Monte a unidade interna e mova o Radeon.kext. O SIP protege apenas o sistema inicializado.
Sugerido em algum lugar on-line, mas realmente um palpite desesperado e não testado: em vez de SingleUserRecoveryMode, Cmdrsvocê pode tentar InternetRecoverySingleUserMode CmdOptrs. Como alternativa, pode valer a pena tentar ver se o SafeRecoveryMode funciona CmdShiftr.
As teclas de brilho da tela não estão funcionando no High Sierra?
A Apple mudou a maneira como os eventos do teclado para alterar o brilho da tela são tratados no High Sierra. Com este hack ou os mods de hardware abaixo, as chaves ficarão sem função. Mais um motivo para ficar com a Sierra. Mas com esse truque, você também pode recorrer ao uso de outra solução de software. Além de invadir sua própria solução AppleScript, você pode experimentar aplicativos ou aplicativos prontos.
Por exemplo, o controle deslizante de brilho na AppStore oferece atalhos de teclado personalizáveis.
Para evitar essas falhas / travamentos / loops de inicialização - que nunca são uma boa idéia para o seu sistema de arquivos - em uma nova instalação ou atualização: certifique-se de cuidar do processo de instalação e sempre inicialize no SafeMode (mantenha Shiftpressionado durante as inicializações até o O kext é movido para um local seguro - a instalação deve prosseguir perfeitamente no SafeMode.
Comentários finais e recomendações
Além disso: este laptop está superaquecendo, não importa o que você faça. O sistema de refrigeração é inadequado e o grande número de chips AMD com falha é apenas uma prova disso.
Para prolongar a vida útil desta máquina agora hackeada, é aconselhável abster-se de um trabalho realmente pesado por longos períodos de tempo. Siga rigorosamente as recomendações usuais para laptops: use em superfícies duras, mantenha os ventiladores e as barbatanas dentro dele limpos. O uso de qualquer software de controle de ventilador com configurações relativamente agressivas também deve ajudar: como smcFanControl , MacsFanControl ou TGPro (ambos comerciais).
Isenção de responsabilidade: todo este procedimento não é uma bala mágica. O estado de falha desses chips não é 100% previsível. Pouquíssimos usuários têm problemas mesmo com esse hack: pode haver problemas com a reinicialização, a suspensão ou o despertar adequado, a maioria deles provenientes de usuários com Yosemite, o menor problema parece estar no Sierra. Nesses casos, às vezes parece necessário não usar o AMDRadeonX3000.kext e, portanto, também não o LoginHook da Parte 3. (Mas veja a nota adicional em * 1 acima.) Um número desproporcional de usuários no High Sierra relata problemas com seus monitores ajuste da luz de fundo. Portanto, atualmente, o ponto ideal para a escolha do sistema operacional está na minha opinião 10.12 Sierra.
Em alguns casos, mesmo com todas essas medidas em vigor, parece que a porta Thunderbolt ainda em funcionamento causará alguns problemas se algum periférico estiver conectado e ativo quando a máquina entrar em suspensão. Depois que isso acontecer, qualquer ciclo de suspensão subseqüente poderá ser afetado e será necessário reiniciar a NVRAM com a subseqüente configuração de dança descrita acima. Parece aconselhável nesses casos impedir a suspensão da máquina ou desconectar qualquer hardware na porta Thunderbolt antes de deixar a máquina dormir.
Dentro das restrições descritas no início desta resposta: A maioria dos usuários relatam sucesso completo.
Mods / hacks de hardware
Várias maneiras disponíveis agora, algumas ruins, outras boas.
Solução ruim: Uma modificação de hardware muito barata está disponível em / de RealMacMods: Embora eles usem uma maneira relativamente complicada de definir a variável EFI necessária com o linux, a seguir tem a vantagem de reduzir completamente a tensão de núcleo do dGPU removendo apenas um pequeno resistor ! (Fotos no link)
Eu não testei isso, mas ele deve eliminar qualquer necessidade de cuidar dos kexts e também resolver problemas relacionados ao sono, ativação, hibernação, reinicialização etc.
Uma ressalva para considerar esse método: já que também parece depender de ter essa variável NVRAM definida parece que é absolutamente essencial ter um método totalmente automatizado para definir essa variável sem nenhuma intervenção do usuário. (Como um stick Linux que faz as alterações necessárias) Caso contrário, uma redefinição da NVRAM pode praticamente bloquear a máquina. O fornecedor alega não ter dados sobre isso!
(Depois de ler a história de um usuário picado por esse método, terminando com apenas uma tela preta: parece possível acessar remotamente a máquina com VNC ou ssh, portanto, se essas configurações forem feitas com antecedência, pode ser uma opção não tão ruim assim. tudo, como a variável nvram pode ser definida dessa maneira. Lembre-se: história da Internet não testada.)
Solução de hardware permanente, confiável e barata!
Aparentemente, o Dosdude1 encontrou uma solução que parece ser o Santo Graal para esse problema: Desativar permanentemente 2011 GPU dedicada do MacBook Pro de 15 "/ 17" de 2011 "- gMux IC Bypass
Isso é quase fácil. Tudo o que é necessário são vários comprimentos de fio . Para ter uma idéia: Também no youtube!
A 'solução ruim' de cima agora é transformada em uma solução de hardware pré-fabricada e quase profissional, eliminando a 'falha' anterior dessa abordagem:
Atualização para uma solução de software completa
O procedimento acima parece ter sido convertido em um aplicativo relacionado ao hardware hack! Bem, pelo menos partes disso. Mas, por outro lado, esse aplicativo é mais universal do que a versão acima, pois parece lidar também com placas NVidia, ou seja: serve para desativar todas as CPUs discretas em todos os Macs.
Infelizmente, este aplicativo feito por dosdude1 e não está bem documentado. A tela leia-me diz que definiria a variável NVRAM, moveria todos os drivers de aceleração gráfica e, em seguida, instalaria um daemon de inicialização para manipular atualizações e garantir que a variável permaneça definida.
Não testado por mim e não aprovado por mim se você já seguiu o procedimento descrito acima!
Mas se o procedimento não funcionou em algum momento para você ou parece assustador, para começar, você pode tentar o seguinte:
dosdude1: Outros softwares não documentados que escrevi estão armazenados aqui: MacBook Pro dGPU Disabler.zip
Talvez você precise analisar o procedimento acima novamente, pois o aplicativo parece perder a parte de gerenciamento térmico (se você modificar o hardware removendo o transistor, isso se tornará humor: misture e combine).
Se alguém testar isso, dê um feedback aqui por meio de comentários ou uma edição.
Atualização de Páscoa 2019: solução de 20 $ que usa um computador Windows de 64 bits e um programador FPGA Lattice HW-USBN-2A ICSP para aplicar um firmware personalizado ao gMux IC. O Dosdude1 afirma que essa é uma solução 'perfeita', o que significa que, mesmo com a duração da bateria HighSierra e Mojave, a temperatura, o controle de brilho e o acordar / dormir funcionam conforme o esperado. Usar essa solução é permanente e torna tudo acima obsoleto.
Mas essa nova solução não é gratuita e requer hardware na forma de um PC com Windows e do programador); e atualmente solda alguns fios temporariamente na placa lógica.)
fonte
agc
não é catastrófico, eu executei o Mac por um mês sem ele antes de encontrar esse truque. A melhoria varia apenas de 'um pouco' para 'OK, quase ótimo'). Radical chic seria usar um stick Linux e definir a variável de there…reboot
após a desativação inicial do SIPcsrutil disable
e após as alterações no gpu nvram Eu não tinha certeza de como reiniciar a partir do terminal de recuperação e tentei desligar o equipamento com força, mas a alteração do SIP não persistiu dessa maneira.Se o problema é que você não consegue mover esses arquivos, provavelmente é a Proteção de Integridade do Sistema que está impedindo você. Suponho que você esteja em El Capitan ou Sierra.
csrutil disable
e pressione Enter.mv
comandar.Se isso funcionou, reative o SIP:
fonte
Graças a esta resposta https://apple.stackexchange.com/a/295805/300460 de https://apple.stackexchange.com/users/251859/langlangc . Eu o segui quando tive esse problema no último setembro de 2018. No entanto, lutei um pouco para descobrir as etapas exatas do delta a serem executadas pela segunda vez, quando me deparei com o mesmo problema ontem novamente quando fiz a atualização de segurança OSX 2019-003. Então, pensei em colocar exatamente essas etapas pensando naqueles usuários que podem encontrar esse problema pela segunda vez. Mais uma vez, muito obrigado a langlangc pelo original.
Eu estava no OSX 10.13.6 no momento em que fiz a atualização.
langlangc
exibindo a tela branca. Na verdade, havia me pedido para confirmar isso em setembro de 2018; mas não pude responder, pois não tenho permissão para Comente)sh /force-iGPU-boot.sh
csrutil disable nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00 nvram boot-args="-v"
/System/Library/Extensions-off
pasta existente foi removida depois de fazer um backup/sbin/mount -uw / mkdir -p /System/Library/Extensions-off mv /System/Library/Extensions/AMDRadeonX3000.kext /System/Library/Extensions-off/ touch /System/Library/Extensions/
nvram boot-args="agc=0"
reboot
para inicializá-lo normalmente.Todo o resto deve estar funcionando conforme o esperado, como você executaria todas as outras etapas necessárias quando o colocou trabalhando pela primeira vez. Muito bem sucedida.
Atualização 12 de agosto de 2019
Eu costumava depender da solução baseada em software sugerida por @LangLangC. No entanto, a recente atualização de agosto constatou que a inicialização normal estava na barra de progresso. No entanto, posso entrar no modo de inicialização segura, mas a tela pisca bastante.
Atualização 14 de agosto de 2019
Inicializado com êxito quando desabilitei o SIP no modo de recuperação. Não me lembro se já fiz no passado - mas agora acho que sim.
Perdi muito tempo suspeitando de vários motivos diferentes - incluindo o problema da GPU piorando ou possíveis erros com a atualização de segurança 10.13.6 2019-004.
No entanto, agora notei que ele inicializou desta vez, mesmo com a problemática
/System/Library/Extensions/AMDRadeonX3000.kext
em vigor !!!Atualização 11 de novembro de 2019
O
AMD6000Controller.kext
é necessário para obter a volta controle de brilho ao trabalho como de costume. Esse kext deve estar presente em/System/Library/Extensions/
.fonte
/force-iGPU-boot.sh
roteiro não? e meuExtensions-off
diretório já estava no lugar, eu apenas mudei o novoAMDRadeonX3000.kext
e o chameiAMDRadeonX3000v2.kext
. Parece melhor manter e carregar o original como indicado no guia @LangLangC, eu acho.