Translate

quarta-feira, 23 de abril de 2025

Fedora 42 KDE - instalação e configuração

Fedora 42 com algumas configurações “herdadas” do Plasma 5 (de outra distro)

Eu já tinha o Fedora. — Instalei a versão 31, no início de 2020, e vim atualizando para 32, 33, 34, 35, 36, 37, 38, 39, 40, 41 — mas esses upgrades nem sempre incorporam certas novidades, que só são vistas em uma instalação nova.

Esta semana, um colega novato em “Linux” instalou o Fedora 42, pediu ajuda em um Fórum, e ao longo da conversa percebi o quanto eu estava alheio às novidades dessa distro. — A revisão do Jesse Smith no Distrowatch atiçou ainda mais a minha curiosidade — e decidi fazer uma instalação nova, para ver como andam as coisas atualmente.

Porém, sem deletar a instalação antiga. O Fedora 41 está configurado do meu jeito, com os aplicativos de que preciso — e pretendo fazer upgrade dentro de 2 ou 3 semanas. — Nenhum motivo para jogar fora.

Optei por fazer a instalação nova em outra partição — afinal, tenho 12 partições para isso, rotuladas de “Linux1” a “Linux12” — e 4 delas estavam vagas. — Escolhi a partição “Linux8”.

Fedora 42 na partição “Linux8” — e o 41 em “Linux4”

A instalação nova ocupou 7,4 GiB em disco — e depois de instalar alguns softwares (total: 2.327 pacotes), chegou a 8,84 GiB — enquanto a instalação de 2020 já ocupa 19,3 GiB (total: 3.081 pacotes).

Reutilizei a partição “Home8” (de uma distro que usava Plasma 5), e o Fedora 42 “herdou” suas configurações — inclusive o applet Quick Launcher (junto ao Menu), que não consigo obter (nem povoar) no Plasma 6. — Até hoje, consegui apenas mantê-lo, nas distros que tinham o Plasma 5 e migraram para o Plasma 6.

Índice

  • Download
  • Hardware
  • Sessão Live
  • Instalação
  • Partições EFI e bootloaders
    • Um bug amplamente benigno
    • Testando os “bootloaders”
  • Configuração

xxx

Download

Verificação da imagem ISO do Fedora 42 KDE pela soma sha256sum

Baixei a imagem Fedora-KDE-Desktop-Live-42-1.1.x86_64.iso (2,6 GiB), datada de 2025-04-09 12:34, além do arquivo de verificação. — Conferi pelo sha256 — e “queimei” no Pendrive pelo comando dd:

$ lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda       8:0    0 447.1G  0 disk
├─sda1    8:1    0     2G  0 part /boot/efi
.........
sdc       8:32   1   7.5G  0 disk
└─sdc1    8:33   1   7.5G  0 part /run/media/flavio/PENDRIVE2

$ sudo dd bs=4M if=/PATH/Fedora-KDE-Desktop-Live-42-1.1.x86_64.iso of=/dev/sdc conv=fsync oflag=direct status=progress

2839543808 bytes (2.8 GB, 2.6 GiB) copied, 297 s, 9.6 MB/s2844538880 bytes (2.8 GB, 2.6 GiB) copied, 297.61 s, 9.6 MB/s

678+1 records in
678+1 records out
2844538880 bytes (2.8 GB, 2.6 GiB) copied, 297.697 s, 9.6 MB/s

Reiniciei o computador, entrei no UEFI Bios Utility, selecionei boot pelo Pendrive, e apareceu o Grub da ISO. — Carreguei a sessão Live Fedora 42 KDE sem perder tempo verificando (de novo) sua integridade.

Hardware

  MoBo: TUF B360M-PLUS GAMING/BR - ASUSTeK
   CPU: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (800 ~ 4100 MHz)
  iGPU: Intel UHD Graphics 630 (Desktop)
   RAM: 15.5 GiB of RAM
   SSD: Kingston   SA400S37480G      480 GB
   SSD: WD         WD Green 2.5      480 GB

Sessão Live

Uso de Memória RAM na sessão Live Fedora 42 KDE

A sessão Live do Fedora 42 KDE começou usando 1,86 ~ 1,88 GiB de Memória RAM (1.909 ~ 1.921 MiB), segundo o top, executado em console virtual (tty4) para não abrir o Konsole (GUI) — pois isso aumentaria o uso de RAM. — Abrir o Plasma System Monitor (GUI) elevou o uso de RAM para 2,0 GiB.

Uso de Memória RAM durante a sessão Live Fedora 42 KDE

Com Dolphin, KWrite, Gwenview, Konsole, System Settings, Welcome Center, Firefox, System Monitor abertos ao mesmo tempo, este último indicou uso de 4,0 a 4,3 GiB de Memória RAM, em diferentes momentos da sessão Live — e depois de abrir também o instalador Anaconda (versão tradicional), o uso de RAM subiu para 5,0 GiB. — Ao fechar o Anaconda, no final, o uso de RAM voltou a 4,3 GiB.

  • Vale lembrar que o Pendrive contém um sistema operacional compactado — e a sessão Live precisa descompactá-lo para a Memória. — Por isso, é normal uma sessão Live usar mais RAM do que o mesmo sistema instalado em disco.

Não percebi qualquer lentidão, em nenhum momento — e não vejo como poderia ocorrer qualquer troca de dados entre RAM e Swap, pois o Fedora Live não montou minha partição Swap — e não utilizou o Swap de 8 GiB que criou em zRAM.

Seção ilegível do Instalador, com tema Dark

Talvez eu tenha cometido algum erro, ao aplicar o tema global Breeze Dark, pois mais tarde me deparei com telas ilegíveis (letras pretas sobre fundo escuro) na seção de particionamento personalizado do instalador. — Reverti para um tema claro, mas só fez efeito depois de fechar o instalador, reabrir, e começar tudo de novo.

Instalação

O instalador do Fedora 42 KDE Live ainda era o Anaconda “tradicional”

A ISO do Fedora 42 KDE Live veio com o instalador Anaconda “tradicional” — ao contrário da ISO “Workstation” (Gnome), que agora vem com um “Anaconda Web UI” — uma nova interface gráfica, utilizando o navegador Firefox (1, 2, 3).

O Anaconda “tradicional” segue o formato básico “hub and spoke” (concentrador e raios), para acesso a várias seções — Teclado, Data & Hora, Rede & Nome de Host, conta Root, Criação de Usuário, e Destino da Instalação. — Você pode percorrer esses “raios” em qualquer ordem, quantas vezes quiser, mudando e tornando a mudar as configurações em cada uma das seções que irradiam do “centro” — mas só pode prosseguir quando todas as 6 seções estiverem adequadamente configuradas (desaparecem o triângulo e os alertas em vermelho, de todas elas).

  • Não percebi diferença em relação ao que registrei em meados de 2019, ao instalar o Fedora 30 no meu antigo computador (Bios / MBR) — ou em 2020, ao instalar o Fedora 31 no meu PC atual (UEFI / GPT). — Agora, senti mais dificuldade, talvez pelo choque de encontrar uma página ilegível, reverter o tema dark, e ter de fechar o instalador e começar tudo de novo.

Desta vez, a escolha do layout de Teclado não foi tão óbvia, para mim. — Minha primeira opção mostrou-se totalmente errada, mais tarde, quando fui preencher algum outro campo, e apareceu uma sopa de letrinhas absurdas. — Voltei à seleção do Teclado, e dessa vez tratei de testar (do lado direito da tela), para ter certeza de que escolhi o layout certo.

Mudando do particionamento Automático para o Personalizado

Na seção de particionamento, selecionei meu 2º SSD (WD Green) — que tinha apenas 3 distros instaladas.

Eu sempre opto pelo particionamento Personalizado — pois preparo minhas partições com antecedência, e quero apenas escolher quais pretendo usar para /, /home, EFI, Swap.

Troquei BtrFS pelo particionamento padrão (tradicional)

A criação de pontos de montagem do Fedora 42 veio configurada para usar esquema BtrFS — mas já tenho isso no openSUSE (desde 2017, sem qualquer problema) — e prefiro manter todas as outras distros com o esquema padrão de particionamento.

  • Uso qualquer distro para olhar ou editar alguma coisa nos arquivos de sistema de qualquer outra — mas é difícil (e perigoso) lidar com a árvore de arquivos do BtrFS a partir de outra distro.

O instalador “agrupa” as partições que pertencem a alguma distro já instalada. — Notei que detectou o Mageia e o MX Linux (identificado como Debian) — mas não o Void Linux, que também estava neste SSD.

Concluídas as opções do particionamento, um alerta do que será formatado

Após selecionar as partições /, /home e EFI a serem usadas na instalação do Fedora 42, o instalador Anaconda ainda não permitia seguir adiante. — É preciso marcar a partição de sistema para ser formatada, mesmo que já esteja pronta e vazia.

As partições /home e Swap são opcionais — e esqueci da Swap.

Para /home, selecionei minha partição “Home8”, de uma distro já deletada, que usava Plasma 5. — Optei por não formatar, para reaproveitar as configurações de usuário existentes nela.

Escolhi minha 2ª partição EFI, localizada no 2º SSD

Selecionei minha 2ª partição EFI (sdb16). — Ela tem rótulo (label) “EFI2" — mas isso é irrelevante, e não aparece. — Dependendo da ferramenta utilizada, ela pode ser identificada como “WD Green”, ou como “HD(16,GPT,bae...” etc.

  • Cuidado para não formatar a partição EFI, que contém os bootloaders de outras distros instaladas antes. — De qualquer modo, ao tentar prosseguir, o instalador Anaconda “tradicional” ainda mostra um resumo das partições que serão formatadas. — É possível voltar atrás, para corrigir. — O instalador “novo” não dá essa chance. É um destruidor instantâneo.

A etapa seguinte, de cópia de arquivos (Pendrive para SSD) e instalação efetiva, se completou em 8 minutos.

Partições EFI e bootloaders

Bootloaders vistos pelo efibootmgr ao terminar a instalação do Fedora 42 KDE

Ao terminar a instalação do Fedora 42 KDE, o comando efibootmgr indicava que o boot tinha sido feito pelo “bootloader” do Pendrive, identificado naquele momento pelo nº hexadecimal 11 — e que, agora, a prioridade de boot era do “bootloader” nº 02 “Fedora”, instalado na 2ª partição EFI — “HD(16,GPT,bae...” etc. (sdb16, ou “WD Green”).

Nenhum sinal do “bootloader” do Fedora 41 — que antes era o nº 02.

Lista (virtual) dos bootloaders, antes e depois de instalar o Fedora 42 KDE

Ao reiniciar o computador (sem o Pendrive) e acessar o UEFI Bios Utility, o firmware já tinha feito nova leitura das partições EFI e apresentou um inventário aumentado de 9 para 10 “bootloaders” — com o Fedora 41 no final (abaixo do Fedora 42) — e os demais deslocado para cima.

Isso não tem nada a ver com a época em que foram criados, nem com a ordem de prioridade de boot. — Esse “inventário” exibido pelo UEFI Bios Utility da minha placa-mãe serve apenas para escolher qualquer “bootloader” e teclar Enter para usá-lo (só por esta vez). — Costuma apresentar no final os que foram “modificados” por último.

Resposta do efibootmgr após reiniciar o computador

Tornei a executar o efibootmgr e ele confirmou que o “bootloader” do Fedora 42 passou a ser o nº 02 — enquanto o do Fedora 41 tornou-se o nº 11. — Faltam vários números (03, 05, 07, 08, 0A, 0B, 0E, 0F), de alguns “bootloaders”, obsoletos, que eu tinha eliminado dias antes — e dos “bootloaders” permanentes (DVD, Pendrive, Rede), que neste caso não foram exibidos (não me pergunte porquê).

Esses números hexa não parecem estar “dentro” desses “bootladers”, pois a pasta do Fedora 41 não foi modificada nesse dia (21 Abril 2025). — Imagino que sejam atribuídos pelo firmware, e não sei onde são guardados. Na ROM? PROM? EPROM? EAROM? EEPROM?

Localização dos “bootloaders” nas 2 partições EFI e datas de modificação

Também não têm nada a ver com a ordem em que foram modificados, ou a ordem de localização “física” em disco — que corresponde à sequência original em que instalei as distros, em 2020: — PCLinuxOS, depois openSUSE, Fedora, KDE Neon (removido), Debian, e por fim a criação manual do atual “bootloader” do Arch Linux em 2023 (havia outros, que deletei em várias épocas).

  • Sem o parâmetro “-U”, o comando tree mostraria por ordem alfabética.

Na EFI2, a ordem “física” em disco corresponde à sequência em que gerei manualmente os “bootloaders” do MX Linux, Mageia, Void Linux, há poucos dias — e agora, a instalação nova do Fedora 42.

  • Ignore o bootloader “MX”, que criei só para testar o novo aplicativo UEFI Manager (GUI) do MX Linux. — Não me interessou, e já deletei.

Só houve alterações na partição EFI2

Portanto, as únicas alterações feitas pela instalação do Fedora 42, no dia 21 Abril 2025 (além da re-numeração e da prioridade de boot), ocorreram na partição “EFI2” — criação das pastas “BOOT”, “Fedora”, “System/Library” e arquivo “mach_kernel”. — Nada disso existia antes.

  • Ver “Criando uma 2ª partição EFI”, aqui.

Um bug amplamente benigno

Excesso de “bootloaders” em nova sessão Live — sem efeito real, ao reinicializar

Houve um princípio de alarmismo com um bug em algumas imagens ISO — que andaria gerando um “bootloader” do Fedora 42, mesmo que a distro acabe não sendo instalada — e o alerta de bug parece contribuir, mais para assustar, do que para esclarecer:

«As imagens afetadas adicionarão uma entrada inesperada à lista do gerenciador de inicialização UEFI assim que a mídia for inicializada, mesmo que você não instale o Fedora. A nova entrada é adicionada ao topo da lista (portanto, é a primeira prioridade na inicialização). A entrada é intitulada "Fedora" e tenta inicializar a mídia live do Fedora».

Na verdade, essa “lista do gerenciador de inicialização UEFI” é volátil — reunida num determinado momento (a partir da leitura dos dispositivos detectados), para ser exibida e usada naquele instante — e desaparece quando se desliga o computador.

O que permanece são os “bootloaders” gravados em uma ou várias partições EFI — inclusive a do Pendrive (enquanto estiver plugado).

Executei uma nova sessão Live (depois de instalar o Fedora 42), e o efibootmgr apresentou mais 2 “bootloaders” — “Fedora” (nº 3) e “VendorCoProductCode” (nº 13) — além dos “Fedora” que já estavam instalados (nº 2, nº 11).

Mas ao encerrar a nova sessão Live e reiniciar o computador (sem o Pendrive), permaneceram apenas os “bootloaders” correspondentes às duas instalações em disco. — Tudo indica ser este o comportamento amplamente benigno (na maioria dos casos).

O alerta de bug diz que em alguns (poucos) casos, o “bootloader” do Live Pendrive fica no computador — mas se o Pendrive não estiver mais plugado, não afetará o sistema. — Não tive essa experiência.

Testando os “bootloaders”

A Swap zRAM se alastrou para minha instalação antiga do Fedora, em dualboot

Minha primeira preocupação, após a instalação nova do Fedora 42 (nas partições Linux8 e EFI2) foi testar o “bootloader” da minha instalação antiga do Fedora 41 (partições Linux4 e EFI).

Reiniciei o PC, escolhi o “bootloader” nº 11 — ele chamou o Grub do Fedora 41 — e carregou o Fedora 41.

A surpresa ficou por conta do Swap, que era de 11 GiB (em sda13) — e agora pulou para 19 GiB — com o acréscimo dos 8 GiB zRAM, configurados pelo instalador do Fedora 42.

Não perdi tempo tentando entender como a instalação nova conseguiu afetar a instalação antiga (em um SSD que não foi modificado). — Removi o pacote zram-generator, conforme sugerido pelo Jesse Smith — e o Fedora 41 voltou a usar só os 11 GiB da partição Swap.

Quanto ao Conky sem gráficos, é um problema que só tenho naquela instalação antiga do Fedora — a única em que uso sessão Wayland (para ver como se comporta). — Fiz recentemente um teste de uso de 7 dias, e nesse período o Conky deixou de exibir os gráficos (e voltou a exibi-los após algumas horas), pelo menos 5 vezes.

Testei mais alguns “bootloaders”, e todos funcionaram como esperado. — As outras distros continuaram montando apenas a Swap de 11 GiB (sda13) — que só vi ser usada 1 vez, em mais de 5 anos.

Atualização do Grub para incluir a instalação nova do Fedora 42

Enfim, atualizei o Grub do openSUSE — meu “Menu de inicialização” — para detectar e incluir a instalação nova do Fedora 42 na partição “Linux8”.

Configuração

Ajustes necessários para reaproveitar configurações “herdadas” na /home

Ao iniciar uma distro recém-instalada — com as configurações de uma partição /home “herdada” de outra distro (sempre com KDE) — aproveito o papel de parede, Painel, widgets, montagem automática de partições etc.

Mas sempre faltam alguns ajustes, a serem feitos com urgência, mesmo que sem seguir qualquer “ordem” racional — para poder começar a documentar as demais configurações, o mais cedo possível. — Não vejo muito interesse em detalhá-las:

  • Autorizar a montagem automática de partições “adicionais”, sem exigir senha
  • Corrigir alguns “lançadores rápidos” (Quick Launch) — chamar “systemsettings” em vez de “systemsettings5”, por exemplo
  • Eliminar widgets que só funcionavam no Plasma 5 — ou trocá-los por outros, que funcionem no Plasma 6
  • Configurar o KDE Spectacle para pular o diálogo e salvar as capturas de tela com nomes no padrão “<yyyy>-<MM>-<dd>_<HH>-<mm>-<ss>_F42.jpg” (por exemplo) — e trocar sua notificação visual por um aviso sonoro
  • Instalar o Chrome — cujo “lançador rápido” apareceu em branco no Painel
  • Instalar o Conky — que já está no Autostart — e ajustar seus arquivos de configuração
  • etc.
Habilitar repositórios de terceiros, no Welcome Center

Alertado por uma conversa em um fórum, testei o botão “Habilitar repositórios de terceiros”, no Welcome Center — e confirmei que ele habilita um conjunto de repositórios tão arbitrários como os do Google, específico para o Chrome; do RPM Fusion, apenas “Nonfree”, especificamente para NVIDIA e Steam; e Copr, especificamente para PyCharm. — Não me interessou esse conjunto, cuja “lógica” me pareceu irracional; e tornei a desabilitá-lo, logo após essa verificação.

Em vez disso, baixei o pacote RPM do Chrome, diretamente do site do Google, e instalei pelo comando dnf — e foi automaticamente adicionado (só) o repositório do Google Chrome:

$  sudo dnf install google-chrome-stable_current_x86_64.rpm

Antes de instalar mais e mais aplicativos, aproveitei para salvar em arquivos TXT a lista dos pacotes instalados até aquele momento — por ordem cronológica (inversa) e por ordem alfabética:

$  rpm -qa --last > rpm-qa-last.txt

$  rpm -qa | sort > rpm-qa-sort.txt

Autorização para montar partições adicionais sem exigir senha

Pelo nano, criei um arquivo de sistema autorizando a montagem de partições adicionais pelo usuário comum (sem exigir senha) — e colei nele este conteúdo:

Command:

$  sudo nano /etc/polkit-1/rules.d/90-udisks2.rules

Pasted:

// Allow udisks2 to mount devices without authentication
polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.udisks2.filesystem-mount-system" || action.id == "org.freedesktop.udisks2.filesystem-mount" || action.id == "org.freedesktop.udisks2.filesystem-mount-system-internal") { return polkit.Result.YES; } });

A partir desse momento, basta o usuário clicar no ícone de uma partição extra, no Dolphin, para ela ser montada, sem exigência de privilégios.

Configuração da montagem automática de partições no KDE System Settings

Isso é necessário para que o KDE faça a montagem automática de partições extras no início de cada sessão — utilizando o udisks2.

# dnf remove korganizer kmail akregator kaddressbook akonadi-server mariadb-common
# dnf4 autoremove
# dnf clean all
     Removed 24 files, 19 directories. 0 errors occurred.
# dnf4 upgrade --refresh
# dnf4 install kate
# dnf4 install conky
# dnf4 install lm_sensors
# sensors-detect
# dnf4 install mc
# dnf4 install plasma-workspace-x11

Removi os principais pacotes do “Personal Information Management” (PIM), removi pacotes órfãos, limpei o cache de pacotes — atualizei o sistema (445 + 14 pacotes) — e instalei alguns pacotes mais urgentes, como Kate, Conky, lm_sensors, Midnight Command (mc), Plasma Workspace X11.

Remoção do PIM: Personal Information Management

O PIM é um poderoso conjunto (suite) de ferramentas — especialmente útil em escritórios corporativos — mas não uso, e desde 2016 adotei a prática de removê-lo das distros que o instalam por padrão.

Adicionando fontes a partir de arquivos ttf

Pelo KDE System Settings, adicionei algumas fontes, a partir de arquivos ttf guardados em outra partição.

Configuração do Auto Login do KDE Plasma em sessão X11

Instalado o Conky, um Logout / Login do KDE acionou o Autostart de suas 2 instâncias, “herdado” com a partição /home — e alguns ajustes em seus arquivos de configuração. — O aspecto visual não ficou bom, devido a incompatibilidades com o Wayland, ainda não superadas.

Configurei o SDDM para fazer Login Automático em sessão X11 — e ao reiniciar, o Conky finalmente exibiu o aspecto esperado.

  • Por enquanto, eu monitoro o comportamento do Wayland na instalação antiga do Fedora — onde é comum o Conky deixar de exibir os gráficos, e voltar a exibi-los após algumas horas. — Já registrei 5+ ocorrências em 7 dias.

Instalei os repositórios RPM Fusion (Free e Nonfree), em seguida o VLC — e mais alguns pacotes que fui lembrando — inclusive o gnome-screenshot, que ainda não consegui usar com muito sucesso:

dnf4 install gnome-screenshot
dnf install https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E
dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E
dnf4 install vlc
dnf4 install kstars
dnf4 install yt-dlp
dnf4 install krename

Configurei o crontab, que aciona alguns scripts para registro de informações 5 minutos após o início de cada sessão: — Data e hora do boot, uso inicial de Memória RAM, e as versões de vários softwares — tais como Kernel, init, Plasma, Qt, Frameworks etc.

___________________
• Publicado em 23 Abril 2025 e desenvolvido até...

— … ≠ “•” ≠ … —

Fedora

PC desktop UEFI / GPT

Ferramentas &tc.

Postado por Mboaba às quarta-feira, abril 23, 2025 0 comentários
Marcadores: , , , , ,
Assinar: Postagens (Atom)