 |
| 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 configurar 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
- Remoção da distro instalada
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 (1, 2, 3).
 |
| Menu e seções do instalador Anaconda “tradicional” |
O Anaconda “tradicional” segue o modelo “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).
- Percebi poucas diferenças 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, propõe esquema de pontos de montagem BtrFS em vez de LVM (optei por particionamento padrão).
Desta vez, a escolha do layout de Teclado não foi tão óbvia, para mim. — Minha primeira opção mostrou-se totalmente errada, 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.
- Eu uso qualquer distro para olhar ou editar alguma coisa nos arquivos de sistema das outras — o que é mais cômodo do que usar uma sessão Live, para isso — mas é difícil (e perigoso) lidar com a árvore de arquivos do BtrFS “desmontada”.
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 acabei esquecendo de configurar a partição 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 nem aparece. — A depender 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. Dizem que é 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 da sessão Live 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 |
Carreguei uma das distros instaladas, 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 não foram listados (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? — Ou é apenas a “lógica” do firmware que atribui sempre os mesmos números, fazendo-os parecer “fixados”?
 |
| Localização “física” 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 os “bootloaders” foram modificados — nem com 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, 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 evapora quando o computador é desligado.
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 — 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. — Sem isso, a montagem automática não pode funcionar. — Não é um “bug” do KDE System Settings. É um requisito lógico
- Corrigir alguns “lançadores rápidos” (Quick Launch) — chamar “systemsettings” em vez de “systemsettings5”, por exemplo
- Eliminar widgets que só funcionavam no Plasma 5 — Weather, Moon Phase, no meu caso — ou trocá-los por outros, que funcionem no Plasma 6
- Configurar o KDE Spectacle para pular o diálogo — salvar logo 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” aparecia 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, só para o Chrome; do RPM Fusion, apenas “Nonfree”, só 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 — 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:
Create file:
$ 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.
Eu chamo essas partições de “adicionais”, ou “extras”. — O KDE chama essas partições de “dispositivos removíveis” — porque não fazem parte do sistema, e por isso podem ser desmontados.
# dnf remove korganizer kmail akregator kaddressbook akonadi-server mariadb-common
Transaction Summary:
Removing: 79 packages
# 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 (para mim), como Kate, Conky, lm_sensors, Midnight Commander (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 fiz alguns ajustes em seus arquivos de configuração. — O 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 apenas 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
dnf4 install fastfetch
dnf4 install inxi
dnf4 install htop
dnf4 install aha
dnf4 install html2text
dnf4 install gimp
 |
| Configurando o crontab para executar scripts após cada boot |
Configurei o crontab para acionar scripts que registram 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: — Kernel, init, Plasma, Qt, Frameworks etc.
Instalei Fastfetch, inxi, htop, aha, html2text, utilizados por esses scripts e pelo Conky — reiniciei o computador — e após 5 minutos (idle) da nova sessão, o script registrou uso de cerca de 1.700 MiB de RAM.
 |
| Redução gradual do uso de RAM do Fedora 42 KDE |
Reiniciei mais 4 vezes o computador, e o uso inicial de Memória RAM foi diminuindo mais um pouco, até cerca de 1.400 MiB.
Desabilitei vários serviços em “Plasma Search” — Activities, Bookmarks, Browser History, Browser Tabs, Dictionary, File Search, Software Centre, Spell Checker. — No Discover, desabilitei Flatpaks e a notificação de atualizações.
Após remover o zram-generator e o PackageKit, o uso inicial de Memória RAM caiu até cerca de 1.300 MiB — nível que vem se mantendo até 5 Maio:
Boot Boot + 5min (2025-04-22)
15:37 1.736 MiB
15:59 1.512 MiB
16:23 1.473 MiB
16:37 1.429 MiB
16:53 1.434 MiB
18:06 ----------- removed zram-generator
18:08 1.413 MiB
20:47 ----------- disabled some Plasma Search services
21:03 ----------- disabled Flatpaks & Discover notifications
21:05 1.400 MiB
21:21 ----------- removed PackageKit
21:25 1.306 MiB
 |
| Configuração e atualização do Grub do Fedora 42 |
O Fedora não atualiza seu Grub, ao instalar nova versão / revisão do Kernel. — No detalhe do alto, à direita, o arquivo grub.cfg ainda exibia a data e hora da instalação no computador. — As alterações só tinham sido feitas na pasta /boot/loader/entries — uma “novidade” do Fedora, que o Grub de outras distros ignora.
Em /etc/default/grub, desabilitei “Boot Loader Specification” (BLS) — e atualizei o arquivo grub.cfg, para que o novo Kernel seja “visto” pelo Grub do openSUSE — o “Menu de inicialização” do meu computador.
- Também desativo os_prober em (quase) todas as distros, para não perderem tempo detectando as outras. — Basta que o Grub de cada uma gere entradas para seus próprios Kernels — para serem lidas pelo Grub do openSUSE (e pelo do Mageia, que é meu Grub de reserva).
Remoção da distro instalada
 |
| Upgrade da “instalação antiga” do Fedora 41 para 42 |
Ainda no final de Abril, fiz o upgrade da minha “instalação antiga” do Fedora 41 para 42 — mas mantive a “instalação nova” — para o caso de ainda querer verificar mais alguma coisa.
 |
| Formatando a partição “Linux8” com a “instalação nova” do Fedora |
Por fim, em 1° Junho, deletei a “instalação nova”: — Para isso, formatei a partição “Linux8”, onde ela estava — mas não a partição “Home8”, que poderá ser aproveitada por outra distro, no futuro.
 |
| Deletando o “bootloader” na partição EFI2, pelo efibootmgr |
Deletei seu “bootloader” na partição EFI2, usando o efibootmgr.
 |
| Grub atualizado, para eliminar a distro deletada |
Enfim, atualizei o Grub do openSUSE, para retirá-la do Menu de inicialização.
___________________
• Publicado em 23 Abril 2025 e desenvolvido até 4 Junho 2025.
— … ≠ “•” ≠ … —
Fedora
- Fedora 30 - instalação e configuração (Bios / MBR)
- Upgrade para Fedora 31
- Transição para hardware UEFI-GPT
- Upgrade para Fedora 32
PC desktop UEFI / GPT
- Transição para hardware UEFI-GPT
- Arch Linux - install, config
- Debian testing - install, config
- Linux Mint 20 (beta) "Ulyana" + Plasma KDE
- Upgrade para o Fedora 32
- Void + KDE
- MX Linux 19.2 KDE Beta 2
- KDE Neon upgrade 20.04 Focal Fossa
- Slackware by Alien BOB
- Slackware 15 alpha1
- Manjaro - instalação e configuração
- PCLinuxOS KDE Darkstar - instalação de substituição
- MX Linux 21 Wildflower KDE - instalação de substituição
- Linux, dualboot, discos, partições e backups
- Redcore Linux - instalação e configuração
- Multiboot de 12 distros Linux
- Upgrade do Mageia 8 para o Cauldron (Mageia9)
- MX Linux 23 “Libretto” KDE - instalação e configuração
- KDE Neon - Plasma 6 em sessão Wayland
- Fedora 42 KDE - instalação e configuração
- Kubuntu LTS, Linux Mint (KDE), KDE Neon, revisitados
Ferramentas &tc.
- O Neofetch parou? Viva o Fastfetch!
- Multi-boot de 12 distros Linux
- Transição para hardware UEFI-GPT
- Speedtest de banda larga de “200 megas”
- Pré-visualização de arquivos no Dolphin
- Limpeza do Cooler da CPU
- Escolhendo Grub entre vários Linux
- De volta ao Gnome-screenshot
- Substituição da fonte de energia do computador
- Corrigindo pontos de montagem no Linux Mint 18 KDE
- KDE “light” eliminando o PIM
- Google Earth sem placa 3D no Xenial
- Linux ficou sem Administrador. Que fazer?
- Padronizando PrintScreen no Linux (com Shutter) e no Windows
- Montagem automática de partições adicionais (Cinnamon e Gnome)
- Boot com “Live USB” (Pendrive) do Linux Mint Cinnamon
- Repositórios de software Linux e gerenciador de pacotes Synaptic
- Monitorando a temperatura da CPU no Linux e Windows
- Conversão em massa de TIFF em JPEG
- Meu Wi-Fi parou de funcionar. E agora?
- Cópia de artigos da mídia para citação
- Lua, Júpiter e Vênus em ISO 1600
- Como se livrar do SPAM da Claro que te interrompe de 30 em 30 segundos
- Quantas pessoas cabem na Avenida Paulista?
