Notas de lançamento #

The installer supports the system role Transactional Server. This system role features an update system that applies updates atomically (as a single operation) and makes them easy to revert should that become necessary. These features are based on the package management tools that all other SUSE and openSUSE distributions also rely on. This means that the vast majority of RPM packages that work with other system roles of openSUSE Leap 15.5 also work with the system role Transactional Server.

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: 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.

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.

Iniciando com o openSUSE Leap 15.2 a verificação de assinatura do módulo do kernel para drivers de terceiros ( CONFIG_MODULE_SIG=y) agora é habilitada. Essa é uma medida de segurança importante para evitar que códigos não confiáveis sejam executados 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.

Inicializando a imagem de instalação via rede de um pendrive USB no Raspberry Pi 4 trava no boot. Para resolver o problema, adicione o parâmetro de boot console=tty. Veja os detalhes na seção problemas conhecidos na nossa Lista de compatibilidade de hardware do Raspberry Pi 4.

KDE 4 packages will not be part of openSUSE Leap 15.4. Please update your system to Plasma 5 and Qt 5. Some of Qt 4 packages might still remain for compatibility reasons. https://bugzilla.opensuse.org/show_bug.cgi?id=1179613.

The nouveau driver is still considered experimental for Nvidia Turing and Ampere GPUs. Therefore it has been disabled by default on systems with these GPUs.

Instead of using the nouveau driver we recommend using Nvidia's new openGPU driver. Install this driver by installing these following packages:

Then uncomment the options nvidia line in the /etc/modprobe.d/50-nvidia-default.conf file so that it looks like the following afterwards:

### Enable support on *all* Turing/Ampere GPUs: Alpha Quality!
options nvidia NVreg_OpenRmEnableUnsupportedGpus=1

If you prefer using nouveau driver anyway, add nouveau.force_probe=1 to your kernel boot parameters, and do not install the above openGPU package.

ibus does not start automatically under KDE Plasma. This can be fixed by adding the appropriate command to the autostart section. To do that, go to System Settings, Startup and Shutdown, Autostart and there click on the Add… button, and then click on Add Application…. In the opened dialog window type ibus-daemon -x into the text box and click OK. For more information see https://bugzilla.suse.com/show_bug.cgi?id=1211977.

O iotop não mostra valores para SWAPIN e IO %.

Desde o kernel Linux 5.14, ou o parâmetro de boot delayacct precisa ser especificado ou o sysctl kernel.task_delayacct precisa estar habilitado.

We switched the RPM and repository signing key of openSUSE Leap 15.5 from 2048 bit RSA to a 4096 bit RSA key. This key was previously introduced to openSUSE Leap 15.4 users in a maintenance update. Users upgrading from older releases will need to import the new key manually as described in https://en.opensuse.org/SDB:System_upgrade#0._New_4096_bit_RSA_signing_key.