Preservando as configurações do OpenWrt durante a atualização do firmware

Ao atualizar o firmware do OpenWrt usando a interface web, você pode utilizar a caixa de seleção “Manter configurações”. Ela realiza o backup do OpenWrt antes da atualização e o restaura após a atualização.

Se você não entender exatamente os casos de uso do botão, desmarque “Manter configurações” sempre que fizer uma nova atualização de sistema do OpenWrt no seu dispositivo, para não preservar as configurações.

• Marque a caixa de seleção “Manter configurações” apenas em pequenas atualizações de correção de bugs que não alteram a estrutura de configuração.
• Use-a apenas para o mesmo canal de firmware (versão → versão, snapshot → snapshot).
• Marcar essa opção preservará vários arquivos de configuração específicos na atualização, mas não toda a partição de sobreposição.

• Se você atualiza seu dispositivo regularmente, de preferência, considere desmarcar “Manter Configurações” sempre que atualizar o roteador e, em vez disso, crie um script personalizado para sua personalização.
• É preciso cautela principalmente com atualizações de versões importantes, por exemplo, da versão 18.06 para a 19.07, ou da 19.07 para a 21.02, etc.
• É possível que as configurações mudem significativamente dentro de uma ramificação de lançamento, mas isso é raro.
• As configurações podem mudar com mais frequência dentro da ramificação principal, o que reflete o desenvolvimento de ponta. Mas mesmo com snapshots da ramificação principal, as configurações mudam raramente.

Veja também: Backup e restauração

A seção a seguir se aplica somente se metadados de imagem forem usados ​​para o processo de atualização.

Nos deparamos regularmente com a situação de dispositivos sujeitos a alterações que os tornam incompatíveis com versões anteriores. Isso geralmente acontece quando a configuração de um dispositivo é alterada de forma que a configuração não pode ser migrada ou alterações no sistema de arquivos não permitem o sysupgrade.

Desde agosto de 2020 (versão 20.xx), um mecanismo adicional garante que os usuários sejam avisados ​​ao atualizar entre versões incompatíveis como essa.

Isso é obtido por meio de um número de versão de compatibilidade armazenado no dispositivo e nas imagens. A versão compat é criada a partir de uma revisão principal x e uma revisão secundária y: x.y

Para todos os dispositivos e imagens anteriores à introdução, o valor padrão “1.0” é assumido.

O valor é atribuído a dispositivos individuais, portanto, não informa nada sobre a revisão geral do OpenWrt.

Se uma alteração incompatível for introduzida, é possível aumentar a versão secundária (1.0→1.1) ou a versão principal (1.0→2.0).

Incremento da versão secundária:

Isso ainda permitirá o sysupgrade, mas exigirá a redefinição da configuração (desmarque “Manter configurações”, execute sysupgrade -n ou SAVE_CONFIG=0). Se o sysupgrade for chamado sem a redefinição, uma mensagem correspondente será exibida. Se o sysupgrade for chamado e as configurações forem redefinidas, ele passará, com os dispositivos suportados sendo verificados como de costume.

Incremento da versão principal:

Isso se destina a casos potenciais (raros) em que o sysupgrade não é possível, pois “quebraria” o dispositivo. Nesse caso, um aviso será exibido e a redefinição da configuração (sysupgrade -n) não ajudará. Você precisará pesquisar instruções sobre como proceder.

Normalmente, além do incremento da versão de compatibilidade, os desenvolvedores também especificam uma mensagem a ser impressa com os avisos acima, dando uma primeira dica sobre o problema.

De qualquer forma, a atualização ainda pode ser forçada (sysupgrade -F) como de costume, mas aí você obviamente encontrará o mesmo problema do qual o mecanismo tenta salvá-lo.

Se fizer isso, observe que a versão de compatibilidade no dispositivo é uma propriedade da configuração, ou seja, o valor é armazenado em uci: system.@system[0].compat_version

Consequentemente, como uma atualização forçada não redefinirá sua configuração, ela também não aumentará sua versão de compatibilidade, e você terá que fazer isso manualmente depois, por exemplo:

uci set system.@system[0].compat_version="1.1"
uci commit system

Conforme mencionado acima, todos os dispositivos e imagens sem a versão compat definida serão tratados como “1.0”.

No entanto, o novo mecanismo de atualização com reconhecimento de versão compat só estará disponível em dispositivos atualizados após esse ponto.

Para dispositivos mais antigos, os metadados em novas imagens foram alterados para fornecer uma experiência semelhante para a versão compat incrementada.

Nesses dispositivos, ao atualizar para uma imagem “incompatível”, avisos de incompatibilidade e mensagens de dica serão exibidos. No entanto, a atualização deve ser forçada em todos os casos (sysupgrade -F -n). Certifique-se de redefinir a configuração, além do parâmetro “force”, caso contrário, você terminará como descrito na seção “Forçando a atualização” acima. A única exceção se aplica aos primeiros usuários do DSA, que podem manter sua configuração. Detalhes podem ser encontrados na seção “Forçar atualização” acima.

Esta seção é focada em desenvolvedores que desejam implementar a versão compatível após introduzir uma alteração incompatível.

A configuração consiste em duas partes:

Para definir a versão de uma imagem, que é verificada em relação à versão de configuração do OpenWrt instalada localmente, as variáveis ​​DEVICE_COMPAT_VERSION e DEVICE_COMPAT_MESSAGE podem ser adicionadas a uma definição de dispositivo:

define Device/somedevice
  ...
  DEVICE_COMPAT_VERSION := 1.1
  DEVICE_COMPAT_MESSAGE := A configuração não pode ser migrada do swconfig para o DSA
endef

A DEVICE_COMPAT_VERSION é obrigatória para qualquer valor diferente de “1.0”. A DEVICE_COMPAT_MESSAGE é opcional e deve ser usada para fornecer uma dica sobre o problema e/ou possíveis medidas para o usuário.

Além dos metadados da imagem, a versão compatível também precisa estar disponível no dispositivo em execução, para que possa ser comparada com quaisquer imagens.

Assim como na configuração de LED/rede, isso será feito por meio do comando “ucidef_set_compat_version” para definir a versão compatível nos arquivos board.d, por exemplo:

  ucidef_set_compat_version "1.1"

Durante firstboot, isso adicionará uma string ao arquivo /etc/board.json, que será traduzida para a configuração do sistema uci.

Dessa forma, a versão compatível, sendo uma versão da configuração, também será exposta ao usuário.

Portanto, a versão compatível no dispositivo é uma propriedade da configuração, não da instalação. Consequentemente, ela será afetada pelo Backup/Restauração, mas também poderá ser ajustada pelo usuário, se necessário.