Notas de lançamento #

A configuração de manutenção do openSUSE Leap 15.3 consiste em três repositórios de atualização principais. São eles: repo-update, repo-backports-update e repo-sle-update. Os dois últimos são novos e são o resultado do reuso dos binários do SUSE Linux Enterprise. Estes repositórios estão disponíveis e marcados durante a instalação online do openSUSE Leap. Recomendamos que você os use. As novas definições de repositórios para o openSUSE Leap 15.3 serão fornecidas adicionalmente através da atualização de manutenção de 0 dia do pacote openSUSE-release. A atualização será entregue pelo canal de manutenção tradicional repo-update. Ele carregará um sinalizador de atualização especial que significa que ele toca a área de gerenciamento de software que é manupilado especialmente pelo zypper. Você deve verificar novamente usando o comando zypper up se todas as atualizações foram processadas. Para mais informações, veja https://bugzilla.opensuse.org/show_bug.cgi?id=1186593.

O repositório repo-update é para as atualizações do openSUSE Leap (OSS). É o menor e contém pacotes de configuração do sistema, incluindo pacotes de versão ("release"), identidade visual e potenciais forks de pacotes do SUSE Linux Enterprise. Este repositório também tem uma variante debug-info.

O repositório repo-backports-update é um repositório de atualização para o openSUSE Backports que contém atualizações da maioria dos pacotes do openSUSE Leap. Este repositório também tem uma variante debug-info.

O terceiro repositório, denominado repo-sle-update, é um repositório de atualização que contém atualizações combinadas de todos os fluxos de atualização ativos do SUSE Linux Enterprise. Este repositório não possui a variante debug-info.

O instalador suporta a função do sistema servidor transacional. Essa função do sistema apresenta um sistema de atualização que aplica as atualizações de maneira automática (como uma única operação) e facilita a reversão, caso isso seja necessário. Esses recursos são baseados nas ferramentas de gerenciamento de pacotes das quais todas as outras distribuições do SUSE e do openSUSE também dependem. Isso significa que a grande maioria dos pacotes RPM que funcionam com outras funções do sistema do openSUSE Leap 15.3 também funcionam com a função do sistema servidor transacional.

Nota: Pacotes incompatíveis

Alguns pacotes modificam o conteúdo do /var ou /srv em seus scripts %post do RPM. Esses pacotes são incompatíveis. Se você encontrar esse pacote, envie um relatório de bug.

Para fornecer esses recursos, este sistema de atualização depende:

Importante: O servidor transacional necessita de pelo menos 12 GB de espaço em disco

A função do sistema servidor transacional necessite de um espaço em disco de pelo menos 12 GB para acomodar os instantâneos do Btrfs.

Importante: O YaST não funciona no modo transacional

Atualmente, o YaST não funciona com as atualizações transacionais. Isto ocorre porque o YaST executa as ações imediatamente e porque ele não consegue editar em um sistema somente leitura.

Para trabalhar com as atualizações transacionais, sempre use o comando transactional-update ao invés do YaST e Zypper para todo o gerenciamento de software:

Quando usar esta função do sistema, por padrão, o sistema irá executar uma atualização diária e reiniciará entre as 03:30 e 05:00. Ambas ações são baseadas no sistema e se necessário podem ser desabilitadas usando o systemctl:

systemctl disable --now transactional-update.timer rebootmgr.service

Para mais informações sobre atualizações transacionais, veja as postagens do blog do openSUSE Kubic https://kubic.opensuse.org/blog/2018-04-04-transactionalupdates/ e https://kubic.opensuse.org/blog/2018-04-20-transactionalupdates2/.

O instalador proporá apenas um esquema de particionamento se o tamanho do disco rígido disponível for maior que 12 GB. Se você deseja configurar, por exemplo, imagens muito pequenas de máquinas virtuais, use o particionador orientado para ajustar os parâmetros de particionamento manualmente.

Antes de instalar o openSUSE em um sistema que inicia usando o UEFI (Unified Extensible Firmware Interface- interface unificada de firmware extensível), você é aconselhado a verificar por qualquer atualização de firmware que o fabricante do hardware recomenda e, se disponível, instalar tal atualização. Um Windows 8 ou mais recente pré-instalado é uma forte indicação que seu sistema inicia usando o UEFI.

Aviso: Alguns firmwares UEFI tem problemas que causam falhas se muitos dados são escritos na área de armazenamento do UEFI. No entanto, não está claro o que seriam “muitos dados”.

O openSUSE minimiza o risco não escrevendo mais que o mínimo necessário para iniciar o SO. O mínimo significa dizer ao firmware UEFI sobre a localização do carregador de inicialização do openSUSE. Os recursos do kernel Linux que usam a área de armazenamento UEFI para armazenar informações de falhas e inicializações (pstore) foram desabilitados por padrão. Entretanto, é recomendável instalar qualquer atualização de firmware que o fabricante do hardware recomendar.

Junto com a especificação EFI/UEFI um novo estilo de particionamento chegou: GPT (GUID Partition Table - tabela de partição GUID). Este novo esquema usa identificadores únicos globais (valores de 128-bit exibidos em 32 dígitos hexadecimais) para identificar os dispositivos e tipos de partições.

Adicionalmente, a especificação UEFI também permite partições antigas MBR (MS-DOS). Os carregadores de inicialização do Linux (ELILO ou GRUB2) tentam gerar automaticamente um GUID para estas partições antigas e gravá-los no firmware. Tal GUID pode alterar frequentemente, causando uma reescrita no firmware. Uma reescrita consiste em duas operações diferentes: remover a entrada antiga e criar uma nova entrada que substitui a primeira.

Firmwares modernos têm um coletor de lixo que coleta entradas removidas e libera a memória reservada para entradas antigas. Um problema pode ocorrer quando um firmware problemático não coleta e libera estas entradas. Isto pode resultar em um sistema não inicializável.

Para corrigir este problema, converta a partição antiga MBR para GPT.

Durante a instalação em um notebook, o pacote tlp é instalado (junto com seu subpacote tlp-rdw se a instalação de pacotes recomendados estiver ativa). Este pacote fornece ferramentas adicionais para economia de energia das baterias em notebooks, especialmente nos notebooks Lenovo.

O serviço não é habilitado por padrão porque pode interferir com outras ferramentas especializadas para notebooks como, por exemplo, laptop-mode-tools, rfkill, gnome-power-manager ou kde-power-manager. Para habiltiar e inciar o serviço explicitamente, use o Gerenciador de serviços do YaST ou use o comando systemctl enable --now tlp.service . Se você encontrar qualquer comportamento inesperado, por exemplo, problemas no Wi-Fi ou portas USB não funcionando, desabilite o serviço novamente.

O openSUSE Leap 15.3 foi criado recentemente com base nos RPMs do SUSE Linux Enterprise Server. Esta alteração foi introduzida como parte do esforço "Closing The Leap Gap (CtLG)" para aproximar o openSUSE Leap e o SUSE Linux Enterprise Server ainda mais.

Diferente do 15.2, a instalação padrão do openSUSE Leap 15.3 contém a maioria dos RPMs vindos do SUSE Linux Enterprise Server. Estes RPMs são assinados pela SUSE LLC ao invés da chave do openSUSE. O pacote libzypp versão 12.25.8 introduziu a lista de permissões para SUSE LLC e openSUSE poderem trocar de fornecedor permitindo a migração sem problemas. A lista de permissões removeu a necessidade de especificar --allow-vendor-change apenas para a troca entre os fornecedores openSUSE e SUSE LLC. Você pode ainda precisar especificar --allow-vendor-change durante a migração se estiver utilizando repositórios do OBS assinados com outras chaves.

As versões do openSUSE Leap mais antigas do que a 15.2 não contém este recurso pois elas não são mais suportadas. Todos os usuários são aconselhados a atualizar para o openSUSE Leap 15.2 com as últimas atualizações antes de atualizar para o 15.3. Os parâmetros a seguir podem ser usados como solução alternativa para versões do libzypp mais antigas que 12.25.8 (substitua 15.0 abaixo com sua versão atual do openSUSE):

zypper addrepo --check --refresh --name 'openSUSE-Leap-15.0-Update' http://download.opensuse.org/update/leap/15.0/oss/ repo-update
zypper dup --allow-vendor-change --force-resolution

O openSUSE Leap 15.3 fornece todas as chaves de verificação RPM, incluindo as do SUSE Linux Enterprise Server como parte do pacote openSUSE-build-key. Todas as chaves também estão disponíveis no repositório OSS.

O pacote libzypp versão 17.25.11 deve importar automaticamente as chaves necessárias que são identificadas como confiáveis. Se tiver, você será notificado sobre a importação e nenhuma outra ação será necessária.

Se o sistema não importou a chave que foi usada para assinar o repodata, você precisará importá-la manualmente. Você pode verificar executando o seguinte comando:

rpm -qa gpg-pubkey

A saída deve incluir uma linha começando com o seguinte texto: gpg-pubkey-39db7c82-* Se não tiver, faça a importação da chave manualmente:

Veja https://bugzilla.opensuse.org/show_bug.cgi?id=1184326 para mais informações.

No openSUSE Leap, o kernel padrão foi dividido em três subpacotes: kernel-default, kernel-default-extra e kernel-default-optional. Similarmente, kernel-preempt também foi dividido em kernel-preempt, kernel-preempt-extra e kernel-preempt-optional. O pacote -optional contém módulos opcionais apenas para o openSUSE Leap. O pacote -extra contém módulos não suportados. O modo de preempção do kernel pode ser controlado configurando o parâmetro do kernel preempt=voluntary na linha de comando. Este parâmetro funciona com o kernel-default.

Se você usa esta variante do kernel, certifique-se de que todos os RPMs necessários para o seu uso estão instalados.

Os pacotes descontinuados ainda são disponibilizados como parte da distribuição mas estão agendados para serem removidos na próxima versão do openSUSE Leap. Estes pacotes existem para ajudar na migração, mas seu uso é desencorajado e eles podem não receber atualizações.

Para verificar se os pacotes instalados não são mais mantidos: certifique-se de que o pacote lifecycle-data-openSUSE está instalado e então use o comando:

zypper lifecycle

Os pacotes removidos não são mais enviados como parte da distribuição.

O pacote recém introduzido openSUSE-signkey-cert é necessário para os KMPs do openSUSE KMPs como virtualbox, mas apenas no modo de inicialização segura. O pacote inclui o certificado da chave de assinatura do openSUSE para assinar os arquivos de módulo do kernel (.ko) no KMP do openSUSE e chama o mokutil para ajudar o usuário a inscrever o certificado no MOK. Desta forma, o KMP do openSUSE pode ser verificado pelo kernel.

Se você não tem o padrão base instalado e está usando qualquer um destes KMPs, recomendamos que instale o pacote openSUSE-signkey-cert manualmente. Uma reinicialização do sistema é necessária. Mais informação sobre este processo e sobre a inscrição manual pode ser encontrado em https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

O openSUSE Leap 15.2 e posterior habilita uma verificação de assinatura do módulo do kernel para drivers de terceiros ( CONFIG_MODULE_SIG=y). Esta é uma medida de segurança importante para evitar a execução de código não confiável no kernel.

Isso pode impedir que módulos de kernel de terceiros sejam carregados se a inicialização segura UEFI estiver ativada. Os pacotes de módulos do kernel (KMPs) dos repositórios oficiais do openSUSE não são afetados, porque os módulos que eles contêm são assinados com a chave do openSUSE. A verificação de assinatura tem o seguinte comportamento:

É possível gerar um certificado personalizado, registrá-lo no banco de dados de chave do proprietário da máquina (MOK) do sistema e assinar módulos de kernel compilados localmente com a chave desse certificado. Os módulos assinados dessa maneira não serão bloqueados nem causarão avisos. Consulte https://en.opensuse.org/openSUSE:UEFI.

Como isto também afeta os drivers gráficos da NVIDIA, abordamos isto em nossos pacotes oficiais para o openSUSE. No entanto, você precisa registrar uma nova chave MOK após a instalação para fazer os pacotes funcionarem. Para instruções sobre como instalar os drivers e registrar a chave MOK, veja https://en.opensuse.org/SDB:NVIDIA_drivers#Secureboot.

Os pacotes do KDE 4 não fazem mais parte do openSUSE Leap 15.3. Atualize seu sistema para Plasma 5 e Qt 5. Alguns pacotes do Qt 4 ainda podem permanecer por razões de compatibilidade. Para mais informações, veja https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.

Desde que a versão 1.5.23 do IBus renomeou alguns layouts de teclado, ele não pode carregar a configuração que contém estes layouts renomeados após a atualização. Assim, ele pode redefinir o layout para o dos EUA. Os layouts dos idiomas a seguir foram afetados: alemão, belga, eslovaco, grego e romeno. Veja https://bugzilla.opensuse.org/show_bug.cgi?id=1177545 para mais informação.

Os usuários precisam migrar a configuração manualmente. Abra as Configurações do GNOME e escolha um layout apropriado. Para outras áreas de trabalho que não o GNOME, executem ibus-setup ao invés.