Resolução de problemas do ResourcePackManager

Esta página descreve comportamentos confirmados no código atual do ResourcePackManager.

O primeiro passo mais útil para qualquer problema é:

/rspm status

Apresenta a versão, o modo independente ou backend de rede, a impressão digital curta e não secreta da chave e a sua origem, o estado dos pacotes Java e Bedrock, a via de entrega e URL, o endereço externo resolvido, o IP público detetado e as opções relevantes. Inclui um lembrete de que o proxy usa o mesmo ResourcePackManager.jar e a deteção de Floodgate e Geyser-Spigot. No proxy, o mesmo comando apresenta os dados equivalentes: backends, resultados de obtenção e pacote combinado.

A consola apresenta poucos detalhes por predefinição

O RSPM apresenta uma linha de resultado por inicialização de uma via de entrega:

[ResourcePackManager] Resource pack is live via self-hosting — http://play.example.com:25566/rspm.zip
[ResourcePackManager] Resource pack is live via automatic hosting — https://magmaguy.com/rsp/<uuid>

A preparação de cada pacote, combinação de grupos, verificações de estabilidade e verificações de alojamento ficam ocultas por predefinição. Uma condição da qual o RSPM recupera sozinho não gera um aviso. Uma verificação local falhada seguida de alojamento remoto bem-sucedido é tratada como sucesso.

A linha de resultado confirma que o RSPM selecionou e publicou um URL. Não demonstra que um determinado cliente transferiu ou apresentou o pacote. Entre com um jogador e observe um objeto ou modelo personalizado conhecido. Antes de comunicar um problema de alojamento ou combinação, ative os detalhes:

/rspm verbose on

Depois execute /rspm reload. O comando guarda verboseLogging: true em plugins/ResourcePackManager/config.yml, mantendo a escolha após reinícios. Use /rspm verbose off quando terminar. Editar a chave manualmente tem o mesmo efeito. O conversor Bedrock tem a opção separada bedrockConverterDebug, alterada apenas na configuração.

Os avisos efetivos incluem falhas repetidas de entrega a um jogador, INVALID_URL, impossibilidade de escutar numa porta HTTP, falha de ambas as vias de entrega ou várias consultas do proxy sem conteúdo de nenhum backend.

Os jogadores não recebem o pacote

Verifique primeiro:

• autoHost tem de estar ativo para a entrega automática normal. selfHostForce é a sobreposição explícita para testes.
• O pacote combinado tem de existir e pelo menos uma via de alojamento, própria ou remota, tem de ter sucesso.
• Os jogadores recebem o pacote à entrada. Os jogadores que entraram enquanto não havia pacote publicado recebem-no quando o alojamento fica pronto, incluindo quando o alojamento volta a ser registado mais tarde na sessão (por exemplo, após uma sessão remota expirada).
• Os jogadores Floodgate são ignorados na entrega Java, pois o Geyser gere a sua sessão Bedrock.

Se necessário:

1. Execute /rspm status e consulte a secção de alojamento. Active delivery mostra a via própria, remota ou nenhuma.
2. active delivery: not yet ready indica que a combinação ou envio ainda decorre. Se um jogador entrar cedo, o plugin avisa na consola e envia automaticamente quando ficar pronto.
3. active delivery: none — hosting disabled or failed indica autoHost desativado ou falha tanto do alojamento próprio como remoto. Consulte as secções de verificações e acesso remoto abaixo.
4. Ative verboseLogging: true, execute /rspm reload, observe os resultados e volte a entrar com um jogador de teste. Sem essa opção, só aparece o resultado final.

O envio inicial tem um atraso de cerca de um segundo. FAILED_DOWNLOAD ou DISCARDED provoca novas tentativas, até três por sessão. Uma recusa, INVALID_URL ou FAILED_RELOAD não são repetidos. Esgotar as tentativas repetidamente ou receber um URL inválido gera um erro real nos registos.

FAILED_RELOAD significa que o cliente transferiu o pacote, mas o seu próprio recarregamento de recursos falhou, pelo que transferir novamente o mesmo pacote não ajuda. O RSPM regista Client <name> reported FAILED_RELOAD for the resource pack. Check that client's latest.log for the resource reload error; not retrying. Leia o latest.log do cliente desse jogador para encontrar o recurso ou os metadados do pacote que o cliente rejeitou.

Se outro sistema gerir alojamento e entrega, com autoHost: false, o RSPM não envia o URL. Para um proxy inverso HTTPS à frente do RSPM, mantenha autoHost: true e use selfHostExternalUrl. Assim, preserva a entrega automática e a alternativa de alojamento remoto.

O conteúdo do ItemsAdder não aparece no pacote final

Normalmente, a configuração do ItemsAdder impede o RSPM de ler ou alojar o resultado. Use:

/rspm itemsadder configure

O comando:

• Ativa resource-pack.hosting.no-host.enabled.
• Desativa protection_1, protection_2 e protection_3.
• Define resource-pack.zip.compress-json-files: false.
• Executa /iareload e depois /iazip.
• Aguarda que o RSPM combine a exportação regenerada do ItemsAdder e indica se a combinação teve sucesso.

Não recarrega o ResourcePackManager. Depois da mensagem de combinação, consulte /rspm status para verificar o alojamento.

Se indicar que o ItemsAdder já aloja o próprio pacote, desative esse alojamento manualmente e repita o comando.

O pacote combinado é inválido ou o envio falha

A integração de alojamento remoto trata estes erros do servidor:

• Ficheiros obrigatórios ausentes.
• Ficheiro demasiado grande.
• Formato inválido.
• Sessão ausente.
• Serviço remoto indisponível.

O próprio RSPM verifica o limite de tamanho antes de enviar: um pacote Java com mais de 50 000 KiB (51 200 000 bytes) não é enviado e a consola apresenta Automatic hosting skipped: resource pack is <size> bytes; the limit is 51200000 bytes. O RSPM tenta então o alojamento próprio verificado. Consulte Alojamento próprio.

Se encontrar um deles:

1. Execute /rspm reload para reconstruir.
2. Verifique se um pacote de origem está mal formado, cifrado ou ilegível.
3. Confirme que o pacote final contém pack.mcmeta e pack.png válidos na raiz.

Se um pacote ativo não puder ser extraído ou preparado, a combinação atual termina e a consola identifica-o. Corrija o pacote, remova o ZIP manual ou defina isEnabled: false na integração automática antes de recarregar.

Metadados de sobreposições e estrutura do arquivo

A combinação final preserva as declarações de formato das sobreposições, incluindo formats, min_format, max_format e metadados adicionais. Quando vários pacotes partilham uma pasta de sobreposição, prevalece a entrada de maior prioridade.

É feita uma reescrita. O Minecraft 1.21.9 e posteriores rejeitam todo o pack.mcmeta quando alguma sobreposição da lista chega ao formato de pacote 64 ou inferior e outra sobreposição não declara formats. Dois pacotes válidos individualmente podem violar essa regra quando as suas listas de sobreposições são combinadas. Quando uma lista combinada contém uma sobreposição cujo limite inferior é 64 ou inferior, o RSPM acrescenta um intervalo formats a cada entrada que só declara min_format e max_format. O intervalo abrange os mesmos clientes que os limites da própria entrada, limitado a 64 quando começa em 64 ou menos. O registo de colisões indica Added the formats range to N overlay entries. As entradas que já declaram formats, ou cujos limites não podem ser interpretados, ficam como estão. Fora disso, o RSPM não uniformiza intervalos de diferentes gerações de clientes nem corrige declarações inválidas; corrija os metadados incompatíveis no pacote de origem.

O RSPM verifica se a pasta de sobreposição é um caminho relativo não vazio que permanece dentro da raiz do pacote preparado. Rejeita caminhos absolutos, caminhos que saiam dessa raiz após normalização e caminhos inválidos. Passar esta verificação não garante que o Minecraft aceite o nome ou os metadados de formato da sobreposição.

Um ZIP com Pack Name/assets/ e Pack Name/pack.mcmeta tem uma pasta adicional a envolver o conteúdo. O RSPM avisa: volte a comprimir colocando assets/ e pack.mcmeta na raiz. Os arquivos com conteúdo deduplicado são lidos pelo diretório central, preservando entradas que partilham dados comprimidos, incluindo metadados de animação de texturas.

Texturas do atlas de blocos

O atlas de blocos combinado expande as origens de pastas para recursos PNG exatos do pacote, preservando a ordem das origens e os identificadores das imagens. Texturas cujas dimensões dos fotogramas não sejam seguras para os níveis mip exigidos recebem cópias determinísticas, redimensionadas por vizinho mais próximo, em resourcepackmanager_internal:mip_safe/. Os originais ficam intactos para fontes e outros carregadores.

Não crie conteúdo no espaço de nomes reservado resourcepackmanager_internal: os conflitos são rejeitados. Este processo não é conversão Java para Bedrock nem garante suporte a todos os shaders ou extensões de atlas dos clientes.

Um pacote danificado não bloqueia tudo indefinidamente

Um pacote que falha sempre na preparação impediria a entrega permanentemente. Após três falhas consecutivas do mesmo ficheiro, o RSPM exclui-o para entregar os restantes e apresenta um aviso destacado:

[ResourcePackManager] Resource pack X.zip failed to stage 3 times in a row and has been excluded
from the merge so the remaining packs can be delivered. The merged pack is now INCOMPLETE ...

Isto significa que o pacote publicado não contém o conteúdo desse plugin. A causa habitual é um ZIP corrompido ou parcialmente escrito.

A exclusão é removida automaticamente quando o ficheiro é corrigido ou substituído, pois o registo usa o tamanho e a data de modificação. O pacote volta à combinação seguinte sem comando nem reinício. /rspm reload também limpa todos os registos de exclusão. Contagens inferiores a três são apagadas após qualquer combinação bem-sucedida, impedindo acumular falhas transitórias distantes até excluir um pacote.

Perante SESSION_NOT_FOUND do alojamento remoto, o RSPM limpa o UUID da sessão e reinicializa no ciclo de manutenção seguinte, sem intervenção manual.

Os recursos de um plugin sobrepõem-se aos de outro

Configure priorityOrder em:

plugins/ResourcePackManager/config.yml

As entradas superiores prevalecem. Nos ficheiros não combináveis, substituem o ficheiro de menor prioridade. Os JSON combináveis são:

• sounds.json.
• Ficheiros de idioma.
• Modelos normais em minecraft/models/item: só o array overrides é combinado, sem recursão; os restantes campos usam a maior prioridade.
• Ficheiros de atlas.
• Ficheiros de fontes.
• Definições de objetos 1.21.4 ou posteriores em items/, respeitando a estrutura das árvores de predicados.

pack.mcmeta tem tratamento próprio: prevalece o maior pack_format e combinam-se os intervalos de formato declarados. As entradas de sobreposição mantêm os intervalos e metadados adicionais do autor; nas pastas duplicadas, prevalece a entrada de maior prioridade. A única adição é um intervalo formats nas entradas que precisam dele para que a lista combinada carregue em clientes 1.21.9+ (consulte Metadados de sobreposições). Fora disso, o RSPM não corrige metadados incompatíveis. Preserva os restantes metadados sem conflito. As origens do atlas base também são acrescentadas aos atlas das sobreposições, evitando esconder entradas base.

Para consultar os conflitos da última combinação, abra:

plugins/ResourcePackManager/collision_log.txt

Os textos de menus ou elementos baseados em fontes estão errados

O RSPM combina ficheiros de fontes, mas isso não garante que dois sistemas de fontes funcionem bem em conjunto no Minecraft.

Se um menu ou painel baseado em fontes estiver errado:

1. Coloque o pacote pretendido numa posição superior de priorityOrder.
2. Execute /rspm reload.
3. Consulte collision_log.txt para confirmar os conflitos esperados.

As alterações ao pacote não aparecem imediatamente

O monitor das origens suportadas espera que cada pacote alterado fique 3 segundos sem mudanças. Quando todos estabilizam, a combinação começa imediatamente.

Se outro plugin ainda estiver a regenerar o pacote, espere alguns segundos após terminar a escrita. Em caso de dúvida, execute /rspm reload depois de esse plugin terminar.

O estado mostra alojamento remoto, mas esperava alojamento próprio

Isto pode ocorrer com preferSelfHost: true, predefinido, quando uma verificação de alojamento próprio falha. As verificações de acessibilidade são registadas ao nível de detalhe e ficam ocultas sem verboseLogging: true; algumas mensagens incluem «This is OK.». Se o alojamento remoto funcionar, o resultado é Resource pack is live via automatic hosting — .... Definições inválidas, falhas do serviço HTTP e falhas de comunicação remota podem continuar a gerar avisos.

Execute /rspm verbose on ou ative verboseLogging: true, seguido de /rspm reload, para identificar a camada:

1. Camada 1, endereço: o endereço externo é privado RFC1918, loopback ou ligação local. Defina selfHostExternalHost com o nome público real ou permita acesso a api.ipify.org e checkip.amazonaws.com.
2. Camada 2, transferências locais e do URL anunciado: o RSPM transfere até ao primeiro KiB de http://127.0.0.1:<port>/rspm.zip e do URL exato do jogador, comparando ambas as amostras com o pacote local. Exige HTTP 200 ou 206, comprimentos indicados coincidentes e o Content-Range esperado para 206. Redirecionamentos, bytes incorretos, ficheiros em falta e falhas de NAT loopback a partir do servidor rejeitam o alojamento próprio.
3. Camada 3, acesso externo: magmaguy.com tem de indicar que o URL anunciado é acessível com HTTP 200 ou 206. Uma porta HTTP fechada, um pedido falhado ou um serviço de verificação indisponível rejeitam alojamento próprio automático. O estado e qualquer código de motivo aparecem com verboseLogging.

Por ordem de preferência, abra a porta HTTP no router e firewall, defina um endereço público encaminhável ou use preferSelfHost: false para tentar primeiro o alojamento remoto. Se o alojamento próprio nunca puder ser usado como alternativa, defina também selfHostEnabled: false e mantenha selfHostForce: false.

Se o serviço de verificação estiver inacessível, o alojamento próprio fica por verificar e o RSPM tenta alojamento remoto. A alternativa após falha remota tem de passar as mesmas verificações. Só selfHostForce: true ignora a verificação; se ambas as vias automáticas falharem, o RSPM não pode anunciar um novo URL de entrega. Verificações bem-sucedidas também não demonstram uma transferência completa e a aceitação do pacote a partir da rede de cada jogador.

Consulte Alojamento próprio para a decisão completa.

O alojamento automático não alcança o serviço remoto

O serviço remoto usado pelo RSPM é:

https://magmaguy.com/rsp/

Se a ligação falhar, o plugin regista avisos de comunicação e não pode usar a alternativa remota até restabelecer o acesso.

Pode:

1. Corrigir a conectividade HTTPS de saída do servidor.
2. Esperar que o serviço remoto volte a estar acessível.
3. Desativar autoHost e alojar o ZIP gerado através do seu sistema.
4. Abrir a porta HTTP, definir selfHostExternalHost com o nome público e manter preferSelfHost: true. O nome explícito ignora a deteção de IP público, mas as verificações local, do URL anunciado e externa têm de continuar a passar. Um serviço de verificação inacessível impede a seleção automática de alojamento próprio.

Quero alojar o pacote no meu próprio servidor web

A configuração suportada é:

1. Defina autoHost: false.
2. Defina resourcePackRerouting se quiser uma cópia adicional numa pasta existente.
3. Aloje ResourcePackManager_RSP.zip através do seu servidor.

resourcePackRerouting é relativo a plugins, e a pasta de destino tem de existir.

Para usar o servidor HTTP integrado na mesma JVM do plugin, consulte Alojamento próprio.

Preciso de consultar os dados remotos guardados para o servidor

Execute:

/rspm data_compliance_request

Com uma sessão remota ativa, a resposta é transferida para:

plugins/ResourcePackManager/data_compliance/data.zip

O RSPM também escreve ReadMe.md em data_compliance. Sem sessão remota, por exemplo com alojamento próprio, informa que não existem dados remotos para pedir.

O pacote Bedrock não é gerado

bedrockConversionEnabled é true por predefinição. Consulte primeiro a secção Bedrock de /rspm status:

• Sem destino Bedrock detetado: não há Geyser-Spigot local, Floodgate local nem modo de rede. A conversão é ignorada deliberadamente. Instale Floodgate para a configuração com proxy ou Geyser-Spigot para um servidor independente e execute /rspm reload.
• Modo de rede ativo, mas ficheiro Bedrock ausente: normalmente, a primeira combinação ainda não terminou, pelo que deve esperar cerca de 30 segundos após o arranque; não foram encontrados mapeamentos convertíveis nem entidades permitidas; ou ocorreu um erro. Procure avisos [BedrockConverter] na consola. Com bedrockConverterDebug: true, o leitor também regista Generic scanner: discovered N item definitions; uma contagem de 0 significa que o pacote combinado não tem definições de objetos convertíveis. (O diagnóstico de estado cita esta linha como discovered 0 items definition files.)

Se a deteção Geyser falhar:

1. Defina bedrockGeyserFolder em config.yml com o caminho da pasta de dados, por exemplo Geyser-Spigot.
2. Os caminhos absolutos funcionam diretamente. Os relativos são tentados primeiro a partir da pasta de trabalho do servidor e depois de plugins.

A deteção procura plugins/Geyser-Spigot/, qualquer variante plugins/Geyser-*/ e config/Geyser-*/ em instalações Fabric/NeoForge.

Para registos por objeto e osso, ative bedrockConverterDebug: true e recarregue.

Bedrock: entrega por sessão ignorada devido a um pacote antigo

Legacy RSPM Bedrock pack detected indica que o Geyser já leu um ResourcePackManager_Bedrock.zip antigo na pasta de pacotes durante o arranque. Apagá-lo em execução deixaria um codec em memória para um caminho inexistente. Por isso, o RSPM não ativa o fornecedor de pacotes por sessão nesse arranque.

Pare completamente o servidor, apague apenas o ficheiro antigo no caminho exato apresentado e volte a iniciar. Não use /reload nesta migração. O pacote atual permanece em plugins/ResourcePackManager/output/ e é entregue por sessão; não pertence à pasta packs/ do Geyser.

Os objetos na mão aparecem na posição errada em Bedrock

Primeiro confirme que foram carregados o modelo pretendido e o pacote mais recente: volte a ligar o cliente Bedrock para que receba o pacote atual. O RSPM obtém a pose na mão das transformações display.firstperson_righthand e display.thirdperson_righthand do modelo Java, pelo que uma pose que também esteja errada no Java corrige-se no modelo Java. Se o Java estiver correto e o Bedrock não, comunique o problema com o ficheiro do modelo.

bedrock_display_offsets.yml e as suas definições de desvio foram removidos e já não são lidos; editar uma cópia antiga não tem efeito. Consulte Poses dos objetos na mão.

As armaduras personalizadas não mostram texturas em Bedrock

As armaduras combinam a geometria normal Bedrock com a textura Java. O pacote de origem precisa de assets/<namespace>/equipment/<material>.json juntamente com a definição do objeto. Se o registo mostrar o objeto convertido, mas a armadura não tiver textura no jogo, confirme que esse ficheiro existe no pacote combinado.

Proxy: um backend não tem chave de rede

O estado mostra Network key source: not set — the proxy sends one when a player next connects here, e a consola repete que o backend está atrás de um proxy mas ainda não tem chave.

A ausência de plugins/floodgate/key.pem não é a causa: esse ficheiro é opcional. O proxy carrega network-key, deriva uma chave do Floodgate uma única vez se existir, ou gera uma nova. Depois envia-a quando um jogador se liga ao backend.

Verifique por ordem:

1. Entrou algum jogador nesse backend desde o arranque do proxy? A atribuição usa uma ligação de jogador.
2. O proxy tem ResourcePackManager.jar? O backend prepara uma cópia em plugins/ResourcePackManager/proxy-extension/ResourcePackManager.jar. Copie-a para plugins/ do proxy e reinicie-o.
3. No Velocity moderno, os segredos de encaminhamento coincidem? O backend rejeita atribuições sem assinatura ou com assinatura errada e indica o motivo. Corrija ambos os lados; a ligação seguinte volta a tentar.
4. Compare Network key fingerprint nos dois lados. Valores iguais indicam a mesma identidade de rede; verifique os resultados de obtenção para confirmar a conectividade. A chave nunca é apresentada.

Consulte a sequência completa em Redes com proxy.

Se aparecer NetworkSync isn't running com uma sugestão de key.pem ausente, consulte o erro anterior do arranque. Essa pista está desatualizada: o proxy atual pode gerar e guardar a sua chave sem Floodgate. O erro de inicialização, as permissões dos ficheiros e a conectividade dos backends determinam a ação necessária. Se o comando /rspm do proxy não existir de todo, procure no registo de arranque uma falha de identidade de rede.

Reposição incompleta após publicação

Se a publicação de um pacote Bedrock, de uma contribuição recebida pelo proxy ou de um pacote combinado falhar e os ficheiros anteriores não puderem ser totalmente restaurados, o RSPM mantém cópias de recuperação e regista a pasta e os destinos afetados. Também tenta retirar de utilização o conjunto incompleto. Preserve a pasta indicada, resolva os erros do sistema de ficheiros e verifique a consistência do pacote e dos mapeamentos antes de tentar novamente. Uma reposição falhada não é uma publicação bem-sucedida.

Proxy: "Could not establish persistent RSPM network identity"

As versões atuais não funcionam com uma chave por guardar. Se o proxy não conseguir guardar em network-key uma chave obtida de novo, ou não conseguir ler um ficheiro network-key existente, a função de proxy para durante o arranque com Could not establish persistent RSPM network identity: ... ou Cannot read established RSPM network identity. A sincronização de rede, a entrega Bedrock e o comando /rspm do proxy não arrancam, pelo que os backends mantêm as chaves existentes em vez de ficarem associados a uma chave que poderia mudar no próximo reinício.

Corrija as permissões da pasta de dados do plugin no proxy (plugins/resourcepackmanager/ no Velocity, plugins/ResourcePackManager/ no BungeeCord) e depois reinicie o proxy. Um ficheiro network-key mal formado mas legível é substituído automaticamente.

Proxy: ausência de pacote combinado após várias consultas

Comece por verificar o número de participantes RSPM confirmados em /rspm status. Um proxy novo sem participantes confirmados continua a descoberta de backends, sem tratar cada servidor registado como um backend RSPM em falha. Os servidores não confirmados não atrasam a sincronização dos pacotes.

Após quatro ciclos de consulta vazios consecutivos com participantes confirmados, o RSPM apresenta um diagnóstico com os participantes, os URL HTTP tentados e os resultados. O intervalo predefinido é de cinco segundos, mas as operações de rede podem prolongar o tempo decorrido. O diagnóstico explica as correções mais comuns:

• CONNECT_FAILED em todos: o proxy não alcança as portas HTTP. Confirme que os endereços de velocity.toml ou config.yml são acessíveis, sem depender de nomes internos Docker não resolvidos na rede do proxy, e que a porta anunciada está aberta. O aviso mostra o URL exato. Antes do anúncio, é usada mcPort + network-http-offset-v2, pelo que uma falha inicial pode afetar essa porta de recurso.
• NOT_FOUND_404 em todos: os backends estão acessíveis, mas não produzem pacote Bedrock. Execute /rspm status em cada um e consulte o motivo na secção Bedrock.

O aviso aparece uma vez por período sem progresso. NetworkSync: recovered indica que algum backend voltou a fornecer conteúdo. Consulte Redes com proxy.

Proxy: modelos Bedrock ausentes no primeiro arranque

O Geyser regista os objetos personalizados apenas no arranque. Se o proxy arrancar antes de algum backend produzir um pacote, a tabela de mapeamentos fica vazia durante essa execução.

Reinicie o proxy depois de este registar Merged Bedrock pack published at .... Nos arranques seguintes, o RSPM coloca antecipadamente os mapeamentos guardados para registo no Geyser. Identificadores novos introduzidos após o arranque podem voltar a exigir reinício.

Backend: falha ao escutar na porta HTTP

Em modo de rede, o backend fornece os resultados Bedrock por HTTP. Se a porta estiver ocupada ou indisponível, aparece um bloco [ERROR] na consola. Pode:

• Definir selfHostPort com outro valor positivo em config.yml.
• Alterar networkHttpOffset-v2 para evitar a colisão. Por exemplo, com RCON em mcPort + 1, use 2 ou 3. Não precisa de alterar o proxy para coincidir: depois de conseguir escutar, o backend anuncia a porta real. O desvio do proxy só serve como estimativa anterior ao anúncio.

Enquanto o servidor HTTP estiver indisponível, a obtenção direta do pacote Bedrock falha. A alternativa de retransmissão em magmaguy.com continua a funcionar: o backend envia os ficheiros e o proxy obtém-nos por essa via.

Limpar uma configuração antiga v1

Ao atualizar da v1, pode permanecer networkHttpOffset, sem -v2, em config.yml. O RSPM v2 não lê essa chave. Escreve automaticamente a predefinição v2, 1, no arranque seguinte. A chave antiga é inofensiva e pode ser removida manualmente.