Testes no Fedora 33 Beta Freeze

FedoraBR

Última Atualização
Dia 31 de agosto de 2020
Horário:19:43 am

OBS: O seguimento dos testes esta nos próximos comentários. Lá na parte inferior.

No dia 25 de agosto entramos no freeze do Fedora 33. E como não poderiamos ficar sem fazer os testes, fizemos a instalação do fedora para inclusive fazer os reports no BugZilla.

O Fedora 33 vem agora como padrão o sistema de arquivo BRTFS.. Quando criamos as partições, o sistema de arquivo utiliza volume onde o / e o /home fica dentro dele. Como padrão o pessoal do projeto passou a utilizar o Zram em vez do Swap.

Para os testes, foi feito o download da última versão que se encontra no servidor do Fedora Project para os testes.
Spins: https://dl.fedoraproject.org/pub/fedora/linux/development/33/Spins/x86_64/iso/

Wokstation: https://dl.fedoraproject.org/pub/fedora/linux/development/33/Workstation/x86_64/iso/

Minimal: https://dl.fedoraproject.org/pub/fedora/linux/development/33/Everything/x86_64/iso/

SilverBlue: https://dl.fedoraproject.org/pub/fedora/linux/development/33/Silverblue/x86_64/iso/

A versão de teste foi o Fedora 33 do dia 31 de agosto, Ambiente Kde Plasma.

Após a Instalação do sistema, foi feito o update sem nenhum repositório de terceiro instalado, como rpmfusion por exemplo. O teste principal foi a transferência entre sistema de arquivos, sendo eles:

• BTRFS
• NTFS
• EXT4

Para esses testes utilizei 2 discos sendo um SSD de 480GB e um Sata de 1tb.

SSD: Kingston model: SA400S37480G size: 447.13 GiB
Sata: Seagate model: ST1000DM010-2EP102 size: 931.51 GiB

O SSD se encontra com o sistema de arquivo BTRFS.

O Sata se encontra com dois sistemas de arquivos sendo, NTFS e EXT4

Para os testes, foi feito a copia de várias isos de um sistema de arquivo para o outro.

NTFS x BTRFS
A transferência demorou exatos 53:66 segundos.

Obs: A transferência entre esses sistemas de arquivos, ainda no momento após mais de 13 testes seguidos, há um congelamento na tela, porém os dados permanecem em cópia. há algum tipo de problema, pelo menos até o momento (dia 31 de agosto de 2020) de um congelamento nessa cópia, mas não trava o computador ao ponto de não retornar as suas funções.

Esse bug ou falha já foi reportado no bugzilla através do ticket: #1872075

Link: https://bugzilla.redhat.com/show_bug.cgi?id=1872075

BTRFS x NTFS
A transferência demorou exatos: 49:91 segundos.

Obs: Não há nenhum tipo de travamento e o funcionamento do ambiente foi perfeito e fluiu muito bem.

BRTFS x EXT4
A transferência demorou exatos: 58:39 segundos.

Obs: Sem travamento, ambiente fluindo perfeitamente. Comparado a transferência dos dados de BTRFS para NTFS, demorou 9 segundos a mais.

BRTFS x BTRFS ( SSD para SSD - Mesma Partição)
A transferência demorou exatos: 0:0 segundos. Isso mesmo ZERO. Isso através do mesmo disco SSD.

BRTFS x BTRFS ( SSD para Disco SATA)
A transferência demorou exatos: 55:80 (cinquenta e cinco segundos). transferência do SSD para o Sata.

BRTFS x BTRFS ( Disco SATA para SSD )
A transferência demorou exatos: 01:06 (um minuto e seis segundos).

EXT4 x NTFS
A transferência demorou exatos: 2:16:53 Segundos (Dois Minutos e 16 segundos). Claro que foi mais lento porque estamos fazendo entra partições do disco sata. Prova-se que não há como retornar mais ao uso de discos Sata. Bem vindo SSD. Porém...

Obs: Não houve em momento algum travamento e nem congelamento do ambiente.

EXT4 x BTRFS
A transferência demorou exatos: 01:06 segundos (Um Minuto e seis segundos). Sabemos nós que foi uma cópia de um disco Sata para um disco SSD. Por isso um pouco a demora.

Obs: Não houve também nenhum travamento e nem congelamento.

Considerações. O uso do sistema de arquivo BTRFS tudo indica que veio pra ficar. Como sistema de arquivo esta funcionando muito bem.

Até o momento com base no Kernel 5.8.3-300, temos já no nosso repositório via rpmfusion o driver 450.66. Esse driver já trás suporte para Gsync. Para os usuários das placas Nvidia, você pode usar o Gsync nos monitores Freesync sem problema algum. Meu monitor é um FREESYNC de 144Hz.

A um tempo atrás tivemos problemas sérios do BTRFS com games, principalmente da Steam. O fato é que a Valve deixou clara que a compatibilidade era somente com EXT4. Depois de duas semanas de uso excessivo em games da Steam como Dota 2 e o Famoso CS GO, não houve em momento algum falhas de corrompimento de arquivos como antigamente. Logo, até o momento não esta havendo problemas do uso do sistema de arquivo BTRFS com Steam. Além disso, foi feito também teste com games da Epics através do Lutris. Nenhum problema encontrado.

STEAM

sudo dnf install steam

LUTRIS + EPIC

sudo dnf lutris steam

RETROARCH

sudo dnf lutris retroarch

Joystick
Tenho aqui o Receiver para controles da Microsoft. Modelo abaixo.

Após ligar o controle sem fio e mandar parear, o fedora detectou automaticamente.

Todos os softwares foram abertos e testados. Sendo, abrindo, inserindo algo, salvando.

Audacity
ao abrir um vídeo ou áudio, não fica em recentes.

sudo dnf install audacity

Clementine

sudo dnf install clementine

Report: https://bugzilla.redhat.com/show_bug.cgi?id=1873903

Dragon Player

Gimp

sudo dnf install gimp

Inkscape

sudo dnf install inkscape

LibreOffice

sudo dnf libreoffice-langpack-pt-BR.x86_64 libreoffice

Kde Connect
Não foi detectado nenhum bug. Feito todos os testes de transferência de arquivos, manipular músicas, usar o celular como mouse.

Obs-Studio

sudo dnf install obs-studio

Obs: Houve um problema na hora de abrir o obs 25.0.8 com os templates criados na versão 25.0.5. O erro é decorrente ao não reconhecimento da estrutura criada na versão anterior. Logo, é bem possível que aconteça o mesmo problema com qualquer um que esteja utilizando o obs anterior e migre para essa nova versão.

Vlc

sudo dnf install vlc

Audaticy Freeworld
ao abrir um vídeo ou áudio, não fica em recentes.

sudo dnf install audacity-freeworld.x86_64

Report: https://bugzilla.redhat.com/show_bug.cgi?id=1783737

Kdenlive - Update 01 de Setembro de 2020. Fix

sudo dnf install kdenlive

Feito correção no pacote do Kdenlive. Está funcionando perfeitamente.

Telegram Desktop

sudo dnf install telegram-desktop.x86_64

FLATPAK

Para Instalar no Kde Plasma o Flatpak basta, abrir o konsole e como sudo digitar o comandoabaixo:

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Fonte: https://flatpak.org/setup/Fedora/

Discord

flatpak install com.discordapp.Discord

O discord via flatpak esta funcionando perfeitamente.

Kdenlive
O Kdenlive via Flatplak esta funcionando perfeitamente.

Snap

Para utilizar o repositório Snap no fedora, abra um konsole e como sudo digite o comando:

sudo dnf install snapd

Discord

snap install discord

O discord via snap esta funcionando perfeitamente.

Discord
Versão stable-0.0.11
Download

Kdenlive
Download

Skype
Download

Não estou tendo mensagens de falhas no kernel nem no sistema.

FedoraBR

Última Atualização
Dia 01 de setembro de 2020
Horário:10:12 am

Update do dia 01 de setembro de 2020 em anexo.

Foi efetuado os testes de transferência do sistema de arquivo NTFS para BTRFS e apesar de não travar tanto dessa vez, ainda continua havendo uma pequena lentidão. Como informado, os dados continuam sendo copiados, mas com o ambiente parado por alguns segundo. veja no vídeo.

https://youtu.be/kvsOL4y2OKM

Como foi perguntado no twitter, estou com o Selinux no modo Permissive.

pandatitan

ANÁLISE DE MÚLTIPLAS DISTROS EM BTRFS:

No mesmo período fiz extensivos testes no intuito de poder instalar sobre BIOS UEFI duas distros usando o mesmo padrão BTRFS de volumes de partição na mesma unidade, visto que em EXT4 em modo UEFI vc consegue instalar quantas distros necessárias. O resultado foi o seguinte...

MAIS DE UM FEDORA USANDO BTRFS:

Nesse cenário você consegue instalar a primeira mas a segunda distro dá um erro indeterminado no anaconda (ESTE ERRO JÁ FOI CORRIGIDO COM A ISO DE INSTALAÇÃO DO FEDORA DO DIA 06/09/20) sobre o /boot e depois gera um erro interno dele mesmo interrompendo a instalação do segundo sistema em BTRFS.

UM SISTEMA EM EXT4 e o SEGUNDO SISTEMA EM BTRFS:

Nesse cenário você até consegue instalar o segundo sistema mas poderá ocorrer as instabilidades mencionadas por Cristiano acima se ouver troca de dados entre os volumes BTRFS e EXT4 das outras distros previamente instaladas antes da instalação da última BTRFS.

DISTROS DIFERENTES USANDO BTRFS:

Acontece o mesmo relatado no primeiro cenário acima.

---

SEGUE ABAIXO OS MAIS NOVOS RESULTADOS DE COMPATIBILIDADE DE INSTALAÇÃO DO FEDORA 33 EM BTRFS COM OUTROS CENÁRIOS...

Caso mesmo assim vc ainda não consiga fazer lado a lado sua instalação do Fedora 33 com outra distro você pode tentar o método abaixo...

https://fedoraproject.org/wiki/User:Sumantrom/Draft/dualboot_f33_btrfs

pandatitan

NÃO CONSIGO LOGAR NO DESKTOP DO LXDE PARA PRÉ-TESTES ANTES DA INSTALAÇÃO...

Esse problema (JÁ RESOLVIDO A PARTIR DA ISO LANÇADA NO DIA 09/08/20), apesar de ter sido reportado várias vezes, se dá pelo fato do LXSESSION ainda estar sendo corrigido/adaptado para o LXDE. Então existe esta solução temporária até o lançamento do LXDE 33 para quem quiser logar na Live-ISO e fazer pré-testes...

Nesse caso quem quiser logar na Live do LXDE 33 para testes segue o procedimento abaixo modificado por mim...

1. Carregue sua Live-ISO do LXDE 33 até chegar na tela de Login.

2. Altere para o Ambiente para OpenBox puro e nele abra o Navegador MIDORI.

3. Acesse o endereço...

   https://koji.fedoraproject.org/koji/buildinfo?buildID=1601782
   

4. Baixe os pacotes rpms do LXSESSION de acordo com sua arquitetura de sua ISO-Live.

5. Depois abra o lx-terminal e instale todos os pacotes baixados com ...

   sudo rpm -Fvh *.rpm
   

6. Depois retorne a tela de Login fazendo um Logout no OpenBox e tente logar no liveuser sem a senha.

7. Deste ponto em diante você já poderá testar e instalar o LXDE 33.

---

Não esqueça de depois de instalado o LXDE você terá que repetir os procedimentos acima para poder fazer logon pelo LXSESSION do ambiente Desktop LXDE normalmente.

geraldossk

o bug do audacity-freeworld é esse aqui: https://bugzilla.rpmfusion.org/show_bug.cgi?id=5731
o outro que foi apontado no post era o bug do audacity do repositório oficial do fedora.

geraldossk

Aparentemente o bug do kdenlive do rpm fusion foi corrigido, já tem observação disso no report:
https://download1.rpmfusion.org/free/fedora/updates/testing/33/x86_64/repoview/kdenlive.html

FedoraBR

Última Atualização
Dia 02 de setembro de 2020
Horário: 11:36 am
Update do dia 02 de setembro de 2020 em anexo.

Houve update no plasma para a versão 5.19.5-1, onde segundo informações, será a última atualização para essa versão. Será a morte e início do plasma 5.20? Não sei.

A transferência entre NTFS e BTRFS continua ainda com um congelamento rápido, porém com as cópias normais. Com o dstat rodando, dá para ver o exato momento que há o pico.

Após alguns testes, desabilitamos o zram com o comando abaixo:

sudo systemctl stop swap-create@zram0

Dessa forma não houve nenhuma mensagem de uso de paginação "OUT" e o sistema fluiu perfeitamente. Fizemos vários testes até a conclusão que, com o uso do zram e swap, ambos tiveram um travamento quando passou a utilizar a saida de paginação.

Testes:
Sem Zram e Swap Habilitado:

Com Zram ou Swap Habilitado:

Obs: Caso queira desabilitar o Zram, use os comandos abaixo:

Permanentemente:

sudo touch /etc/systemd/zram-generator.conf

ou

sudo dnf remove zram-generator-defaults

Fonte: https://fedoraproject.org/wiki/Changes/SwapOnZRAM

FedoraBR

Última Atualização
Dia 03 de setembro de 2020
Horário: 12:11 am
Update do dia 03 de setembro de 2020 em anexo.

Mais uma atualização do systemd sendo agora a versão 246.4-1.fc33.

FedoraBR

Última Atualização
Dia 17 de setembro de 2020
Horário: 09:28 am
Update do dia 17 de setembro de 2020 em anexo.

Após essa atualização, foi feito a cópia de NTFS para BTRFS com o Zram habilitado. Foi feito 5 copias dos mesmos arquivos citados no post. Houve somente uma pequena trava muito rapida, diferente das outras vezes.

Como pode ser visto, da pra ver o exato momento stravés do dstat --vmstat

O kernel que estamos utilizando nesse momento é o Linux localhost.localdomain 5.8.9-301.fc33.x86_64 #1 SMP Mon Sep 14 19:30:07 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Irei utilizar o Zram esses dias para ver o comportamento da maquina no uso diário.

FedoraBR

Última Atualização
Dia 21 de setembro de 2020
Horário: 09:25 am
Update do dia 21 de setembro de 2020 em anexo.

O Fedora 33 encontra-se com o Kernel Linux localhost.localdomain 5.8.10-300.fc33.x86_64

A versão do Audacity-freeworld no plasma esta funcionando muito bem e sem erro de fragmentação.

Houve atualização no anaconda e pelo que da pra ver, eles estão trabalhando bastante sobre os dual-boots do fedora 33 com outras distros e inclusive com o próprio windows em EFI.
Versão do anaconda: 33.25.2-4.fc33

Houve também um update no f33-backgrounds-kde, mas nada que tenha tanto impacto no momento.

Houve também um update na versão do python3 para 3.9.0~rc2-1.fc33.

A cópia dos dados entre NTFS e BTRFS estão resolvidos. a partir do kernel 5.8.10-300.fc33.x86_64. Não houve o travamento após 7 tentativas na cópia.

FedoraBR

Última Atualização
Dia 23 de setembro de 2020
Horário: 10:48 am
Update do dia 23 de setembro de 2020 em anexo.

Novas atualizações de pacotes do qt5. Existe um problema com o telegram-desktop em relação a esses pacotes.

Houve também atualização do kwin indo para a versão 5.19.5-2.

Fiz os testes com o Latte-dock mais atual e com o wallpaper animado.