Translate

quinta-feira, 15 de junho de 2023

Multi-boot de 12 distros Linux

Quadro: - Situação das 12 distros instaladas até 11 Junho 2023

• Isto não é uma “comparação técnica” entre distribuições Linux — até porque nenhuma delas é uma “instalação padrão” (out of the box). — Isso é apenas um “quadro da situação” das minhas distros neste momento, às vésperas das novas versões do Mageia e do MX Linux.

Todas instaladas em dualboot (multiboot), por segurança. — Se uma distro quebrar, basta reiniciar, escolher outra (em 2 minutos); e deixo para consertar quando tiver tempo. — (O último desastre fatal foi em 2017, quando eu tinha 4 distros, 2 quebraram, e pude resolver com calma, semanas depois).

Me acostumei a mudar de “distro preferida”, a qualquer momento em que me sinta mais confortável com outra — um “distro-hopping em baixa velocidade”. — Se não consigo dominar uma distro logo no começo, continuo tentando nas horas vagas, durante meses, ou vários anos.

Tenho escolhido distros que cubram os “ramos” principais da “árvore de distros Linux” — diferentes filosofias, diferentes sistemas init, diferentes modos de instalação, de empacotamento e gerenciamento de pacotes etc. — para não ficar dependente de nenhuma empresa ou comunidade, em caso de falência, compra, venda, incorporação, mudanças drásticas, ou outra inconveniência.

Para lidar com essa “creche”, preciso lembrar as características das várias distros que tenho, anotar o que já consegui em cada uma, e o que ainda falta aprender.

Os itens avaliados mudam com o tempo. — Hoje, quase não preciso do Wine; o corona-cli já não é tão necessário; e o speedtest-cli deixou de ser útil; mas ainda registro, até que outras tarefas tomem seus lugares. — Em 2017, minhas preocupações eram bem outras (Fevereiro, Junho).

  • 2024 Agosto - Adicionei algumas observações do que aconteceu nos 12 ou 14 meses após a publicação original dessas notas — mas sem entrar em detalhes, pois isto exigiria reescrever quase tudo.

Índice

  • Visão geral
    • Label
    • Partições-raiz
    • Tipo de lançamento
    • Kernel
    • KDE Plasma
    • Software init
    • Servidor gráfico
    • DE Console
    • Sistema de arquivos
    • Empacotamento e gerenciadores de pacotes
    • User ID
    • Data de instalação
    • Espaço ocupado na partição-raiz
    • Tempo de boot
    • Uso de Memória RAM
    • GoogleEarth
    • Sincronização do Google
    • Foliate
    • corona-cli
    • yt-dlp
    • speedtest-cli
    • Wine
    • Outros itens
      • Grub
      • uDisks2
      • Weather
      • Exif
      • Pré-visualização de arquivos no Dolphin
      • Kim4
  • Mudanças nos aplicativos do KDE
  • Atalhos personalizados no Wayland
  • Gerenciadores de pacotes
  • Distros “preferidas”
  • Um passo de cada vez
  • Hardware

Visão geral

Label - Tanto as partições-raiz quanto os hostname's são numerados (Linux1 a Linux12), para facilitar minha vida no dia-a-dia. — Isso gera mensagens de erro durante o boot de algumas distros, talvez por não aceitarem maiúsculas e números (ou talvez, porque systemd tenta se sobrepor a /etc/hostname). — Isso ainda não me causou qualquer problema real, até o momento.

Redistribuição das distros entre 2 SSDs Sata III

Partições-raiz - Em Maio 2023, instalei um segundo SSD Sata III e “movi” para ele metade das distros. — Com isso, deixei de usar HDD para o Swap, para as partições /home e para as partições de documentos — o que reduziu bastante o tempo de boot de todas as distros.

Distribuir as 12 distros em 2 SSDs era minha intenção desde 2020, por uma questão de segurança — e só adiei por causa da pandemia.

Essa reorganização ainda está em andamento. A nova partição de documentos correntes “Warehouse” contém apenas os arquivos produzidos a partir de Maio 2023; e alguns outros que copiei (só o essencial). — Por enquanto, “Sites” e “Works” (de 2 GiB, cada) são partições vazias, e cumprem apenas o papel de manter as configurações das 12 distros (Labels em fstab, montagem automática, Conky). — Falta reorganizar o material existente nos antigos HDDs (desconectados no momento) e no SSD externo USB 2.0 de backup.

Tipo de lançamento - O Slackware permanece um desafio, para mim, e desisti de torná-lo “rolling-release” (current), por enquanto. Limito-me a atualizar um ou outro pacote, quando necessário. — O Redcore sofreu algum desastre, e agora também atualizo só um ou outro pacote; por isso, não classifico mais como “rolling-release”, até consertar. Reinstalar não me ensinaria nada, por isso prefiro continuar tentando. — Ambos funcionam bem, exceto pelos pacotes que ainda faltam.

Kernel - Uso o Kernel que cada distro “traz naturalmente”, e desde 2007 isto só me incomodou 1 vez: — Instalei o Kernel corrente no Arch, e só quando se desentendeu com o Grub é que instalei o LTS, em Março 2023. — No Manjaro, optei pelo Kernel LTS desde a instalação (mas não é o mesmo Kernel LTS do Arch).

KDE Plasma - Todas as distros estão com o KDE — e procuro configurá-las tão “igual” quanto possível, de modo que mal percebo a diferença, ao passar de uma distro para outra. — No Mageia 8, no Slackware 15 e no MX Linux 21, ainda tenho alguns recursos que desapareceram em versões recentes dos aplicativos KDE. Nada que me incomode muito. (Ver “Mudanças nos Aplicativos do KDE”, adiante).

systemd-analize vs. disponibilidade efetiva do Plasma KDE

Software init - Apenas no Void, precisei lidar com o Runit, pois fiz a instalação básica e depois adicionei o Plasma KDE. Nenhuma dificuldade. Só não encontrei um comando para exibir sua versão. — Eu raramente uso comandos do SystemD — e nas outras distros, ainda não precisei lidar com o SysV nem com o OpenRC.

O único efeito prático, é que não disponho de uma ferramenta unificada (como o systemd-analyze) para medir com precisão o tempo de boot de todas as distros — mas isso talvez seja bom, pois de nada me serve receber números como 15’’ (ou seriam 19’’?), se o Painel do KDE só se tornou disponível, de fato, aos 24’’ uptime:

«Note that these measurements simply measure the time passed up to the point where all system services have been spawned, but not necessarily until they fully finished initialization or the disk is idle»

Servidor gráfico - Apenas no Fedora, mudei do X11 para o Wayland, para ficar de olho no que promete se tornar o próximo padrão. — Por enquanto, precisei apenas substituir o gnome-screenshot pelo KDE Spectacle — ambos com salvamento automático (commandline in background), sem abrir janela de diálogo GUI. (Ver “Atalhos personalizados no Wayland”, adiante).

DE Console - Localização do ambiente Plasma KDE nos Consoles tty1, tty7 e até mesmo no tty8. — Informação inútil, já que é muito mais rápido tentar logo as 3 alternativas do que procurar “onde foi que anotei” — ao voltar do tty2, que é onde costumo executar comandos fora do ambiente gráfico do KDE.

Partição BtrFS quase “vazia”, vista a partir de outras distros

Sistema de arquivos - Somente no openSUSE, optei por partição-raiz em BtrFS (com snapshots). Nenhum problema com BtrFS, desde 2017 — mas isso dificulta localizar seus arquivos do sistema, a partir de uma sessão Live USB (ou a partir das outras distros), pois estão sabe-se lá onde. Para limitar o problema, mantive as outras distros em partições ext4. — Nenhum problema com a partição /home do openSUSE em XFS, desde 2017.

Empacotamento e gerenciadores de pacotes - O Arch, o Manjaro, o Slackware e o Redcore têm modos próprios de empacotamento, que assinalei com asteriscos (*), na falta de outras siglas tão conhecidas quanto “deb” e “rpm” (aceito sugestões). — No openSUSE uso o zypper; no Fedora uso o dnf; no Mageia uso urpmi / urpme etc.; no Void uso xbps; no Redcore procuro usar o sysiphus (embora às vezes tenha de usar o emerge, para algumas tarefas). — No Debian, no KDE Neon e no MX Linux, uso o apt para verificar as atualizações; e o Synaptic para aplicá-las, ou para pesquisar e instalar novos pacotes. — No PCLinuxOS, uso só o Synaptic, para não me confundir com seu apt (apt-rpm). — No Arch, uso o pacman para atualizar o sistema; e só depois uso o yay para atualizar os poucos pacotes do AUR que utilizo. — No Manjaro, uso o pacman e, em seguida, o pamac (CLI).

Minha primeira providência, ao instalar uma distro, é remover o PackageKit, responsável pela verificação automática de atualizações. — Deixei apenas no Mageia, que me ofereceu um modo rápido de “nunca verificar”; e no KDE Neon (também desativado), porque os desenvolvedores insistem que devemos usar o comando pkcon (uso pkcon nos upgrades de versão; e às vezes para verificar se o apt / Synaptic está fazendo tudo certo). — Ao remover o PackageKit, a “lojinha” Plasma-Discover também é removida, assim como o Apper do Debian.

Nas distros “deb”, também removo unattended-upgrades, que faz atualizações “de segurança” sem perguntar nem avisar — além de aumentar a fragmentação dos registros (log separado). — Prefiro fazer tudo pelo Synaptic, de modo a ter um Histórico centralizado (e fácil de pesquisar).

Portanto, nada se instala nem se atualiza, exceto quando eu comando manualmente, em geral aos Domingos — e não fico recebendo avisos impertinentes a toda hora.

Ainda não utilizo Flatpaks, Snaps, AppImages. — Utilizo o mínimo de repositórios não-oficiais de cada distro. — Em geral, habilito os repositórios do Google para o Chrome e o GoogleEarth, a serem usados pelo apt / Synaptic / dnf / urpmi / sysiphus etc., mas no Void e no Slackware a atualização precisa ser feita na unha. — No PCLinuxOS, o LibreOffice vem direto da fonte, por um aplicativo específico (não pelo Synaptic). — No KDE Neon, recorri apenas ao PPA do Foliate; mas um dos upgrades instalou automaticamente o PPA do Mozilla Firefox (que nem uso).

Enfim, em todas as distros, instalo o corona-cli pelo comando npm — vem do github, se não me engano. — Tentei o pip algumas vezes, no Arch, no Debian e no Slackware, sem muito sucesso.

User ID - Nas minha primeira instalação do PCLinuxOS, o UID padrão era 500, e isso bloqueou o uso mútuo de arquivos com as demais distros, cujos usuários têm UID=1000. — Por isso, agora especifico UID=1000 ao reinstalar o PCLinuxOS. — Nunca tive problemas com GID=100, ou 1001, 1002 etc.

Data da instalação - No meu antigo PC, várias dessas distros foram instaladas a partir de Outubro 2016 (Debian testing) e de 2017 em diante, e continuaram funcionando sem grandes problemas até Janeiro 2020 — quando montei meu PC atual e instalei 4 distros nos primeiros 3 dias: PCLinuxOS, openSUSE, Fedora e KDE Neon (agora, em UEFI-GPT). — Nas distros instaladas por último, ainda faltam vários pacotes e funcionalidades, até porque entre elas estão algumas, nas quais ainda preciso aprender muita coisa, como Slackware, Void, Redcore. — Em breve, será hora de decidir se vou reinstalar ou apenas fazer upgrade do Mageia e do MX Linux. — Nenhum problema com sucessivos upgrades do KDE Neon e do Fedora (ou do Leap, no antigo PC).

Espaço liberado após limpar o cache de pacotes baixados

Espaço ocupado na partição-raiz - Para o openSUSE Tumbleweed, destinei uma partição de 50 GiB, pois o acúmulo de “instantâneos” (snapshots) cresce muito rápido. Limitei bastante o número de snapshots a serem mantidos, mas de vez em quando preciso eliminar os mais antigos. — Para as outras distros, destinei partições de 30 GiB, mas no caso do Redcore tive de ampliar para 60 GiB devido ao espaço exigido durante as compilações.

Nas distros em que uso o apt / Synaptic, configurei para sempre esvaziar o cache de pacotes baixados, após completar sua instalação. — No Arch, no Fedora, no Void e no Manjaro, faço uma limpeza do cache de pacotes baixados quando o espaço ocupado começa a aumentar muito. (Não costumo fazer downgrade de pacotes). — Enfim, o espaço ocupado também depende do número de pacotes instalados, quando a distro já vem com muita coisa, ou quando já adicionei muitos pacotes.

Average Boot Time (sec)

             Oct 2021   Jun 2023    Diff   Delta      Jan 2020

openSUSE         42’’       33’’     - 9    -22%          15’’
Arch             32’’       19’’     -13    -41%
Debian           23’’       17’’     - 6    -27%
Fedora           40’’       36’’     - 4    -10%          15’’
Neon             27’’       23’’     - 4    -15%          10’’
PCLinuxOS        25’’       18’’     - 7    -27%          16’’
Mageia           37’’       18’’     -19    -51%
Slackware        31’’       15’’     -16    -52%
Void             34’’       19’’     -15    -43%
Manjaro          31’’       19’’     -12    -40%
Redcore                     14’’
MX Linux         35’’       22’’     -13    -38%

Tempo de boot - Passo até 1 semana sem reiniciar o computador, por isso, ganhar alguns segundos no boot não faz diferença — mas há tempos observo que o openSUSE (BtrFS + Snapshots) e o Fedora costumam demorar mais — enquanto o Debian testing e o KDE Neon demoram menos, por exemplo.

Após mover a partição Swap, as partições /home e as partições de documentos do HDD para SSDs Sata III, em Maio 2023, o tempo de boot diminuiu drasticamente (não tenho plano de investir em NMVe, no momento).

Os tempos acima são a média de várias observações (Conky), no momento em que finalmente é exibido o Painel do KDE Plasma. — Apenas no Debian, a montagem automática de 25 partições extras é feita pelo /etc/fstab — enquanto nas outras é feita pelo UDisks2, via KDE System Settings.

Esses tempos eram ainda menores em Janeiro 2020, quando eu ainda não usava partições Swap e /home; e a montagem automática envolvia apenas 3 ou 5 partições extras (todas em SSD Sata III).

RAM usage 10 min uptime (iddle) - just 1 sample

Void             878 MiB
PCLinuxOS        921 MiB
Slackware        940 MiB
MX Linux         940 MiB    --- average 967 MiB, for previous 6 samples
Redcore        1,001 MiB
Manjaro        1,031 MiB
Neon           1,049 MiB
Arch           1,059 MiB
Mageia         1,068 MiB
Fedora         1,139 MiB
openSUSE       1,210 MiB
Debian         1,211 MiB

Uso de Memória RAM - Com 16 GB de Memória RAM, não faz diferença se uma distro Linux usa 900 MiB ou 1.200 MiB ao terminar o boot e carregar a sessão Plasma KDE — mas talvez essas anotações possam ser úteis para quem tem um PC mais antigo / mais fraco:

  • Os números acima são de 1 única observação — exatamente aos 10 minutos uptime (iddle) — e vale lembrar que oscilam o tempo todo
  • Nenhuma dessas distros é uma “instalação padrão” (out of the box)
  • Todas, sem o KDE-PIM — KMail, KAddressBook, KOrganizer etc. — e portanto, sem 17+ processos do Akonadi em execução
  • Todas, sem File Search (indexação pelo baloo_file) — que nunca me fez falta para buscas simples no Dolphin (CTRL+F), ou avançadas (KFind). — Não uso Tags, Rating, Comment, Today, Yesterday etc. no Dolphin; e desativo os serviços correspondentes
  • Vários serviços de busca do KDE desabilitados, além do File Search — Activities, Bookmarks, Browser History, Browser Tabs, Desktop Search, Dictionary, Locations, Places, Software Centre, Spell Checker, Web Search Keyords, por exemplo
  • Vários Background Services desabilitados em “Startup and Shutdown” — Bluetooth, KSysguard, Plasma Vault module, Remote URL Change Notifier, Search Folder Updater, SMB Watcher (em geral, também elimino o Samba, pois não tenho rede local).
  • Vários Desktop Effects desabilitados em Workspace Behavior
  • Todas as distros, sem verificação automática de atualizações e sem unattended-upgrades (atualizações silenciosas de segurança) — coisas que também aumentariam o uso inicial de RAM em várias distros
    • Apenas no openSUSE, serviços de manutenção BtrFS + Snapper
    • Apenas no Mageia, serviço MSEC (segurança) — mas sem verificação periódica de zilhões de arquivos em todas as partições
    • Apenas no Fedora, SELinux ativado. — Também veio no openSUSE, mas desabilitado
  • Afora os processos normais de cada distro, estão em execução apenas 2 instâncias do Conky — a segunda, executando comandos free, top, neoFetch, htop, inxi, Screenfetch, aha, html2text 1 única vez (em background) a cada 10 segundos — e os widgets Weather e Moon Phase, que aumentam em cerca de 45 MiB o uso de RAM
  • Nenhum emulador de Terminal aberto — pois Konsole, XTerm, Xfce-Terminal etc. aumentam o uso de Memória, em quantidades diferentes, o que invalidaria a comparação entre distros com diferentes emuladores
  • A única ação executada durante os primeiros 10 minutos uptime é a captura de tela ao exibir o Painel do KDE — pelo Spectacle (no Fedora e no Slackware); ou pelo gnome-screenshot, — ambos por comandos (background: command), sem abrir diálogo em GUI
  • Aos 10 minutos uptime, um script agendado pelo crontab lê os dados em /proc/meminfo e registra o uso de Memória RAM em um arquivo TXT — usando um cálculo absolutamente igual, em todas as distros — ao contrário de ferramentas como free / top, htop, Neofetch, Screenfetch etc., que podem ter versões diferentes, com cálculos diferentes, de uma distro para outra
MEM_TOTAL=$(awk '/MemTotal/ { printf $2 }' /proc/meminfo); \
MEM_AVAIL=$(awk '/MemAvailable/ { printf $2 }' /proc/meminfo); \
MEM_USED_KILO="$(($MEM_TOTAL-$MEM_AVAIL))"; \
echo "$(($MEM_USED_KILO/1024))" MiB > MemInfo.txt

O cálculo executado por esse script (acima) é o que foi proposto por Linus Torvalds desde 2014: — Mem_Used = [Mem_Total - Mem_Available] — e que ainda não foi adotado por todas as ferramentas mais comuns.

  • Naturalmente, com Xfce, LXQt, Lumina ou um simples gerenciador de janelas — em vez do Plasma KDE — todas essas distros usariam muito menos Memória RAM

GoogleEarth - Não é fornecido diretamente por nenhuma dessas distros — mas pode ser instalado e atualizado pelos gerenciadores de pacotes de várias delas, a partir do repositório do Google. — No Mageia, abre e navega normalmente, mas a Busca (cidades, ruas) não está funcionando. — No PCLinuxOS, vários usuários conseguem instalar, usando uma ou outra dica, mas nenhuma dessas dicas resolveu para mim. — No Slackware, no Void e no Redcore, o caminho é um pouco mais complicado, e ainda não consegui, ou ainda não tentei.

Sincronização do Google - Desde quando o Google bloqueou a sincronização do Chromium (e derivados), optei pelo Chrome, instalado e atualizado tal como o GoogleEarth — porém, como no Slackware, no Void e no Redcore é mais trabalhoso, acabo só atualizando quando pretendo usar uma dessas distros por um tempo mais longo — porque basta não estar 100% atualizado, para não sincronizar.

Foliate - Virei fã do ePub — e como não faz sentido salvar duplicatas de tudo em PDF, me tornei dependente do Foliate, rapidamente adotado pela maioria das distros. — Só no PCLinuxOS e no Slackware, ainda não instalei.

corona-cli - Instalei pelo comando npm — mas já faz algum tempo que não uso, e fui parando de atualizar (ele avisa quando há novas versões, mas só quando é executado). — Ainda não instalei no Slackware e no Redcore.

yt-dlp - É o sucessor do Youtube-DL, que ficou abandonado. — Fundamental para baixar vídeos, também, do Twitter, do Facebook e outros mil lugares. — É um problema no KDE Neon, cuja base Buntu-LTS fica estagnada (e eu não uso PPA, Flatpak, Snapd etc.).

speedtest-cli - Já foi uma ferramenta fantástica... até a Ookla lançar seu próprio aplicativo — e impor limitações crescentes. — Ainda preciso dele, mas os resultados parecem cada vez menos confiáveis (o que me obriga a testar por 3 ou 4 sites, para ter uma noção do estado real da conexão).

Wine - Já faz alguns anos que converti a maior parte dos meus DOCs dos anos 1990, usando velhas macros que criei no MS Word — e a maior parte dos Views DXF do AutoCAD, usando o CorelDraw. — Desde o início dos anos 2000, não criei para mim nenhuma nova “dependência” desses velhos softwares, e nas distros mais recentes nem cheguei a instalar o Wine. — Pelo que verifiquei esta semana, alguma coisa daquilo tudo ainda funciona no KDE Neon e no Fedora; ao passo que no openSUSE sumiu do Menu e talvez eu precise configurar de novo.

Outros itens

Entradas para Arch e Manjaro no Grub do openSUSE e do Mageia

Retirei do “Quadro” alguns itens que agora têm menos importância — ou com os quais posso lidar sem necessidade de um lembrete permanente:

Grub - O Arch e o Manjaro exigem parâmetros, que só o Grub do openSUSE é capaz de detectar e incorporar, por padrão. — Para usar meu “Grub de reserva” (do Mageia), preciso fazer uma correção manual — caso a caso, conforme os Kernels do Arch e do Manjaro:

Find:           initrd /boot/intel-ucode.img
Replace with /  initrd /boot/intel-ucode.img /boot/initramfs-linux.img
    (or)     |  initrd /boot/intel-ucode.img /boot/initramfs-linux-lts.img
    (or)     \  initrd /boot/intel-ucode.img /boot/initramfs-5.10-x86_64.img

(Se eu remover o Manjaro e o Kernel corrente do Arch, bastaria uma busca-e-troca global automática no /boot/grub2/grub.cfg do Mageia — coisa que o editor do meu Midnight-Commander (mcedit) no Mageia já está treinado para fazer).

Por outro lado, o Grub do Mageia é o único capaz de detectar e carregar o openSUSE — instalado em partição BtrFS e sem /boot em partição separada. — Por isso, é o meu “Grub de reserva”.

Nas outras 10 distros, desabilito os-prober, para que o Grub deles não perca tempo detectando outras distros. — Basta que cada um detecte e gere entradas para sua própria distro — para serem lidas e incorporadas pelo Grub do openSUSE.

(Quanto mais distros os-prober tiver de verificar, maior a demora nas atualizações de algumas distros, ao instalarem novas versões / revisões de Kernel, pois executam os-prober 2 ou 3 vezes — em especial, quando também se remove a versão mais antiga).

Por isso, faço as atualizações em ordem inversa, do último (Linux12) para o primeiro (Linux1) — para que o Grub do openSUSE detecte e incorpore as atualizações de Kernel das outras 11 distros. — Considere isso um “algoritmo” a ser seguido, ao fazer dualboot / multiboot de distros Linux.

Enfim, no Fedora precisei desativar o Boot Loader Specification (BootLoaderSpec ou BLS), que impede a geração de “entradas” no seu próprio Grub, substituídas por “entradas” em /boot/loader (que o Grub de outras distros não entende). — Por isso, o dnf não atualiza o Grub do Fedora, ao instalar e remover Kernels, e preciso atualizá-lo manualmente — caso contrário, o Grub do openSUSE (ou do Mageia) não verá novas “entradas” do Fedora para atualizar.

Montagem de partições extras pelo uDisks2, via KDE System Settings

uDisks2 - Apenas no Debian, ainda uso o arquivo /etc/fstab para montagem automática das partições “extras” — ou seja, as que não são da própria distro, tais como “Warehouse”, “Sites”, “Works” e as partições das outras distros:

LABEL=Warehouse  /media/Warehouse   ext4        defaults,user    0   2
# LABEL=Depot1     /media/Depot1      ext4        defaults,user    0   2
LABEL=Sites      /media/Sites       ext4        defaults,user    0   0
LABEL=Works      /media/Works       ext4        defaults,user    0   0
LABEL=Linux1     /media/Linux1      btrfs       defaults,user    0   0
LABEL=Linux2     /media/Linux2      ext4        defaults,user    0   0
# LABEL=Linux3     /media/Linux3      ext4        defaults,user    0   0
LABEL=Linux4     /media/Linux4      ext4        defaults,user    0   0
LABEL=Linux5     /media/Linux5      ext4        defaults,user    0   0
LABEL=Linux6     /media/Linux6      ext4        defaults,user    0   0
LABEL=Linux7     /media/Linux7      ext4        defaults,user    0   0
LABEL=Linux8     /media/Linux8      ext4        defaults,user    0   0
LABEL=Linux9     /media/Linux9      ext4        defaults,user    0   0
LABEL=Linux10    /media/Linux10     ext4        defaults,user    0   0
LABEL=Linux11    /media/Linux11     ext4        defaults,user    0   0
LABEL=Linux12    /media/Linux12     ext4        defaults,user    0   0
LABEL=Home1      /media/Home1       xfs         defaults,user    0   0
LABEL=Home2      /media/Home2       ext4        defaults,user    0   0
# LABEL=Home3      /media/Home3       ext4        defaults,user    0   0
LABEL=Home4      /media/Home4       ext4        defaults,user    0   0
LABEL=Home5      /media/Home5       ext4        defaults,user    0   0
LABEL=Home6      /media/Home6       ext4        defaults,user    0   0
LABEL=Home7      /media/Home7       ext4        defaults,user    0   0
LABEL=Home8      /media/Home8       ext4        defaults,user    0   0
LABEL=Home9      /media/Home9       ext4        defaults,user    0   0
LABEL=Home10     /media/Home10      ext4        defaults,user    0   0
LABEL=Home11     /media/Home11      ext4        defaults,user    0   0
LABEL=Home12     /media/Home12      ext4        defaults,user    0   0

Nas demais distros, uso o uDisks2 (via KDE System Settings); mas ainda enfrento falhas renitentes no Void e no Redcore, depois de reorganizar os discos (por exemplo, agora que “movi” partições dos HDDs para o novo SSD). — Isso exige montar manualmente (pelo Dolphin) as partições que faltam; e marcá-las outra vez para montagem automática.

Weather2 (widget), após o KDE 5.26

Weather - Uso esse widget desde 2016 (inicialmente, no KDE Neon), mas com a chegada do KDE 5.26, no último trimestre de 2022, começou a ficar truncado — exceto no MX Linux, Mageia e Slackware (ainda com KDE mais antigo). — A solução foi desinstalar o Weather (sem manutenção há 6 anos) e instalar o Weather2 (já na versão 2.33, de Outubro 2022).

  • Isto se tornou um problema no Plasma 6, que ainda não resolvi (Ago. 2024).

Dados Exif das fotos no Mageia Cauldron

Exif - No Redcore, ainda não consegui que o Dolphin mostre os dados Exif das fotos no Painel Informações (F11), do lado direito — embora o Gwenview tenha essa capacidade (ao custo de vários cliques).

Exibição de vídeos no Painel Informações (F11) do Dolphin

Pré-visualizações no Dolphin - De um modo geral, consegui (há alguns anos) que o Dolphin mostre pré-visualizações de arquivos de imagem, de vídeo, GIFs animados, TXT, ODT, ODS, PDF, ePub, Mobi, SVG, KML KMZ, XCF, e às vezes até DOC, DOCX, CBR (com direito a assistir os vídeos no Painel) — mas sempre há exceções de alguns tipos de arquivos, em alguma distro. — Não vale a pena registrar em detalhes, até porque isso varia ao longo do tempo.

Menu de contexto do Kim4 para o Dolphin, no MX Linux

Kim4 - Era um ótimo “menu de contexto”, desde os tempos do KDE4, para os recursos do ImageMagick no Dolphin — e ainda se encontra no AUR do Arch; e até recentemente, no repositório do MX Linux 21; enquanto o PCLinuxOS oferece um “Kim5”. — Isso deixou de ser relevante, desde que existem vários widgets com a mesma função, que podem ser baixados a partir das configurações do Dolphin.

  • Isto se tornou um problema no Plasma 6, que ainda não resolvi (Ago. 2024).

Mudanças nos aplicativos do KDE

Antigos atalhos F10 e F11 no Kate / KWrite

Em algum momento, Kate / KWrite perderam as antigas teclas de atalho F10, para alternar “Dynamic Word Wrap” (on / off); e F11 para “Show Line Numbers” (on / off). — O F10 pode ser restabelecido manualmente, mas F11 agora conflita com o atalho global para “Full Screen”, e preferi não mexer nisso. — A solução foi tornar padrão “Show Line Numbers” (on) nas configurações, tanto do Kate quanto do KWrite, separadamente.

(No Dolphin, F11 ainda alterna on / off o “Painel Informações”, à direita).

O Gwenview agora “não pára“ no final de uma pasta. Avança... para o começo. Se eu optar por ser avisado, preciso de pelo menos 2 cliques para voltar. — Se eu ampliar e renomear (F2) um arquivo de imagem, não volta mais ao tamanho normal (Fit); e não atualiza o nome na barra de título da janela (o que impossibilita arrastar e soltar para upload). — Para atualizar o nome e voltar ao tamanho normal (Fit), torno a usar F2 + Esc em sequência.

Essas mudanças me incomodaram, porque uso esses recursos o tempo todo, tentando não perder tempo. — Para amenizar, alterei minha personalização do Gwenview (Barra de Ferramentas). — Ainda tenho os antigos comportamentos no Slackware 15, no Mageia 8 e no MX Linux 21, mas isso está perto de acabar.

Ok, há muitos anos a evolução permanente do Plasma KDE costuma aprontar incômodos como esses (e até piores) — mas no final das contas, vale a pena, diante do acréscimo de ótimas funcionalidades. — Lembro que muitos recursos foram perdidos na passagem do KDE4 para o KDE5, e depois voltaram aos poucos.

Lidar com essas perdas faz parte da minha opção inicial pelo KDE Neon, com Plasma sempre novo; e mais tarde, por distros rolling-release — ao invés de ficar 2 anos num Kubuntu LTS estagnado, e depois receber uma cambulhada de novidades, o que anula a “produtividade” até que eu me acostume outra vez.

O Fedora KDE Wayland alterou várias coisas. — Agora, renomear um arquivo no Gwenview (F2) abre uma sub-janela no alto, à esquerda, em vez da janelinha centralizada de todas as outras distros com a mesma versão de KWin ou dos Aplicativos KDE em sessão X11.

  • Em suma, o Wayland eliminou a configuração autônoma da sub-janela pelo KWin.

Atalhos personalizados no Wayland

Criação de atalhos personalizados para o gnome-screenshot em Plasma X11

Há muitos anos, adotei o gnome-screenshot em “modo automático” (sem perguntas) para capturar telas ou janelas e salvar automaticamente em arquivos JPG com um padrão de nome “data + hora + sufixo da distro”:

PrtScn ----- Capture and save full screen
gnome-screenshot -p -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Shift+PrtScn ----- Capture and save full screen after 7 seconds
gnome-screenshot -p -d 7 -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+Shift+PrtScn ----- Capture and save active window
gnome-screenshot -w -p -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+PrtScn ----- Capture and save active window after 7 seconds
gnome-screenshot -w -p -d 7 -f /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Criação de atalhos personalizados para o KDE Spectacle em Plasma X11

Apenas no Slackware, eu ainda usava o KDE Spectacle, enquanto não encontro o gnome-screenshot para instalar — mas o diálogo GUI é muito incômodo, para fazer várias capturas com retardo. — Isso foi resolvido graças à dica de um colega sobre os comandos CLI, em Maio 2022:

PrtScn ----- Capture and save full screen
spectacle -p -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Shift+PrtScn ----- Capture and save full screen after 7 seconds
spectacle -p -d 7000 -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+Shift+PrtScn ----- Capture and save active window
spectacle -p -a -e -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

CTRL+PrtScn ----- Capture and save active window after 7 seconds
spectacle -p -d 7000 -a -e -b -o /PATH/$(date +%F_%H-%M-%S)_Xxx.jpg

Teste do KDE Spectacle por comandos no Fedora

A discussão, naquele momento, era devido ao gnome-screenshot não funcionar em sessão Plasma Wayland — e minha primeira providência foi adotar o KDE Spectacle para poder testar o Wayland no Fedora, de modo permanente.

Seção de Atalhos personalizados ocultada no Wayland

Infelizmente, esqueci de documentar aquela configuração e copiar os comandos exatos, naquele momento — pois logo no mês seguinte, o KDE System Settings deixou de exibir a seção de Atalhos personalizados na sessão Plasma Wayland.

Seção de Atalhos personalizados na sessão Plasma X11

Agora, quando carrego uma sessão Plasma X11 do Fedora, para ter acesso à seção de Atalhos personalizados, tudo que encontro lá são os antigos atalhos do gnome-screenshot (desativados); e um atalho experimental (também desativado) do KDE Spectacle. — Portanto, tenho as 4 ações de captura de tela que costumo usar — mas não sei como fiz, nem como alterar, se necessário.

Na seção de Atalhos do KDE Spectacle, essas teclas estão desmarcadas — restam só as que não utilizo — e de qualquer modo, não há opção de alterar para comandos personalizados (commandline: background).

  • Isto ficou ainda mais complicado, quando chegou o Plasma 6 — mas surgiu (ou demorei a descobrir?) outro caminho para criar Atalhos Personalizados, no KDE System Settings. — Ao longo do 1º semestre de 2024, também houve pelo menos 2 mudanças nos códigos do KDE Spectacle para salvar os arquivos das capturas em formato “YYYY-MM-DD_HH-mm-SS”, e quando falha o código antigo, não recebo aviso. Apenas não salva; ou salva com nome errado, e portanto fora da sequência cronológica esperada.

Gerenciadores de pacotes

Downloads do pacman em ordem decrescente de tamanho dos pacotes

Usar vários gerenciadores de pacotes, lado a lado, todas as semanas, é uma das alegrias dessa vida — e não me canso de acompanhar os indicadores de velocidade de download, atividade de CPU, Disk I/O etc., pelo Conky.

O pacman é, sem dúvida, o mais interessante — por baixar os pacotes em ordem decrescente de tamanho, o que ajuda a manter uma velocidade ótima, já que cada requisição implica no início de uma nova remessa. — Para coroar, indica a velocidade de download de cada pacote; e a média do conjunto, no final.

O dnf, que uso só no Fedora, também tem o ótimo hábito de apresentar esses números (embora em MB, não em MiB) — mas a ordem dos pacotes é outra, o que implica em oscilações bruscas de velocidade. — E uma vez que se disponha de boa conexão, já não faz sentido o tempo gasto para calcular o “delta RPM” de cada pacote e do total de “economia de banda”.

  • Ultimamente, o dnf abandonou essa perda de tempo com “delta RPM” (Ago. 2024).

Graças a essas estatísticas do pacman e do dnf, é fácil comparar a demora relativa dos downloads do zypper — sempre nos mesmos dias, com o mesmo hardware, e a mesma conexão.

A velocidade de download do zypper sempre foi apenas uma fração do que minha conexão permitia — quando eu tinha 10 “megas”, depois 200 “megas”, e agora 480 “megas”. — Contratar uma conexão mais rápida melhora, mas sempre obtenho só uma fração do obtido em outras distros, nos mesmos dias e horários.

Tanto no openSUSE quanto no Fedora, aceitei a configuração-padrão, que redireciona para espelhos mais “próximos” ou mais velozes (sem que eu saiba quais são) — mas no openSUSE o resultado é sempre muito menor. — Para comparar, no Arch eu uso um espelho fixo, ótimo no eixo Paraná-Brasília:

           openSUSE     Arch            Fedora

 4 Jun     6,6 MiB/s    33.7 MiB/s      22   MB/s
28 May     6.8 MiB/s    33,7 MiB/s      23   MB/s
21 May    10.3 MiB/s                    26   MB/s
 7 May   ~ 5   MiB/s                    19   MB/s

After "download.max_concurrent_connections = 10" in /etc/zypp/zypp.conf

18 Jun     3,3 MiB/s    29.1 MiB/s      18   MB/s
25 Jun     7.1 MiB/s    30.6 MiB/s      14   MB/s

O zypper também é menos cômodo para copiar e manter um registro em arquivo TXT (legível a partir de outras distros) — e o mesmo posso dizer do urpmi (no Mageia) e do xbps (no Void). — O urpmi não indica velocidades de download; e as que o xbps indica não conferem com o mostrado pelo Conky.

Tamanho pré-definido do nala oculta listas mais extensas

Nas distros .deb, uso o apt apenas para “ver” se todos os repositórios respondem bem — e quantos (e quais) pacotes serão atualizados. — Experimentei o nala, mas o tamanho pré-definido de seu quadro restringe a visualização de listas mais extensas (talvez possa alterar isso, mas não descobri como). — Isso é chato, no caso do Debian testing, por exemplo, que chega a consultar mais de 100 arquivos nos repositórios, para definir quantas centenas de pacotes precisa baixar.

Resumo dos pacotes e total do download, no Synaptic

Após verificar, pelo apt, se todos os repositórios respondem, abro o Synaptic, clico em “Mark all upgrades” — e invisto um tempo a examinar as seções “Auto-removable”, “Local or obsolete”, “Residual config”, “Missing Recommended packages” etc. — Quando há nova versão ou revisão de Kernel, aproveito para procurar e marcar o mais antigo para remoção completa. — Ao clicar em “Apply”, registro o resumo dos pacotes a serem atualizados, instalados, e o tamanho do download.

Como não indica a velocidade de download, preciso medir a duração pelas capturas de tela do Conky + KRuler (1 pixel = 1 segundo) — e faço a conta. — Mas isso é trabalhoso, por isso, em geral, limito as comparações ao Pacman e ao dnf.

Pesquisa por “packagekit” no Histórico do Synaptic

O Synaptic é uma ferramenta excepcional, com todas as funções oferecidas pelo apt (e mais nada) para examinar a consistência do sistema, os pacotes de cada repositório, e assim por diante. — Nunca encontrei nada tão completo, nem no YaST2 (openSUSE), nem no Mageia, ou em qualquer outra distro. — O histórico do Synaptic permite localizar todas as atualizações, instalações, remoções de qualquer pacote (e alguma dependência que ficou).

Synaptic do PCLinuxOS, que usa o apt-rpm

No PCLinuxOS, não uso seus comandos apt (apt-rpm), para não me confundir com pequenas diferenças em relação ao apt das distros de base Debian — e seu Synaptic também apresenta algumas diferenças: — Se fizer 2 “Reloads” seguidos, esvazia-se a seção “New in repository”, o que é chato.

Distros “preferidas”

Já faz mais de 1 ano que uso o Arch Linux quase o tempo todo — embora eu tenha todos os recursos de que preciso, também, no openSUSE, no Debian, no Manjaro e no MX Linux. — Então, por que uso quase que só o Arch, em 99% do tempo, a semana inteira?

Talvez seja a distro que menos me dá trabalho — quase nenhum problema, nos últimos 6 anos — mas não tenho estatísticas objetivas, para confirmar.

Dizer que o Arch “fica fora do meu caminho”, talvez seja pouco. — Pode parecer esquisito dizer que ele não tem sabor, não tem cheiro, não tem cor, mas isso talvez seja a melhor definição. — Se eu “percebo” qual distro estou usando, é porque alguma coisa nela me incomoda, por mínima que seja.

A distro ideal é aquela, em que eu não percebo “qual distro estou usando”! — Isso talvez seja um indicador muito mais valioso, do que qualquer "estatística de problemas".

O Arch é uma das mais “enxutas”, por eu mesmo ter “construído” passo-a-passo: Só tem o que eu quis instalar. — Isso o torna “mais ágil”? Talvez seja apenas outra impressão subjetiva. Sem dúvida, a ausência de pacotes inúteis ajuda a atualizar mais rápido, mas o empacotamento, o pacman, o espelho (no Brasil) e a boa conexão até minha cidade também ajudam muito.

Tudo isso também vale para o Manjaro, exceto que nele tenho 1.429 pacotes instalados, mesmo sem Wine e outras coisas (contra 1.126 no Arch, com Wine), por ser uma instalação padronizada, não-pessoal; mas a diferença mal se percebe, no dia-a-dia. Apenas, o Manjaro não me atrai. — Instalei para testar e aprender mais algumas coisas (antes de aplicá-las no Arch); e mantive como uma “reserva de segurança”. Só que não sinto medo de perder o Arch, e eu não hesitaria em remover o Manjaro, se eu quisesse experimentar mais alguma distro.

Arch                             Manjaro

# pacman -Q --foreign            $ pamac list -m
google-chrome 114.0.5735.90-2    gnome-icon-theme          3.12.0-7          AUR  10.3 MB
google-earth-pro 7.3.6.9345-1    gnome-icon-theme-symbolic 3.12.0-6          AUR  2.0 MB
kim4 0.9.8-2                     google-chrome             114.0.5735.133-1  AUR  321.6 MB
pcurses 5-5                      google-earth-pro          7.3.6.9345-1      AUR  256.0 MB
ps_mem 3.14-2                    manjaro-documentation-en  20181009-1             10.0 MB
yay-git 12.0.5.r9.g1335e9b-1     manjaro-firmware          20160419-1             2.6 MB
                                 pcurses                   5-5               AUR  617.3 kB
                                 systemd-fsck-silent       239-1                  34.8 kB
                                 (+ kim4)                                    AUR

Acima: - Além dos pacotes oficiais, tenho apenas estes, no Arch e no Manjaro.

  • Mais tarde, esse tipo de estatística se embaralhou — porque instalei uma penca de “alternativas ao Neofetch” (além de Nerd Fonts), no Arch, mas não no Manjaro. — E exagerei no Void, com centenas de Nerd Fonts, ao ponto de torná-lo uma distro entulhada, ou bloated (Ago. 2024).

O Debian testing e o MX Linux também me atendem perfeitamente — com a diferença de que o Debian traz uma quantidade enorme de pacotes que não uso (por exemplo, o LibreOffice trouxe todos os idiomas do Universo); e isso contribui para tornar mais demoradas as suas atualizações (além do seu empacotamento fragmentado). — O MX Linux desempenha as mesmas tarefas, com muito menos pacotes (2.513, contra 3.638 do Debian); e por ser “stable”, costuma ter pouquíssimas atualizações; porém, traz uma ótima coleção de aplicativos muito úteis (e em versões bem recentes), que o Debian “stable” não ofereceria.

É possível fazer uma instalação enxuta do Debian, mas não vejo motivo para tentar isso, por enquanto. — Ele me atende perfeitamente, como está.

Importante: - O número de pacotes do Debian / MX Linux não pode ser comparado com o do Arch / Manjaro, por se tratar de sistemas de empacotamento muito diferentes.

Outra distro que me atende perfeitamente é o openSUSE Tumbleweed — apesar de também ter um excesso de pacotes, de que não preciso, só porque aceitei os “patterns”. — Também é possível fazer uma instalação bem mais “enxuta”, mas isso é outra coisa que não me disponho a tentar, no momento.

Com todo possível “inchaço”, o openSUSE tem funcionado com precisão, nos últimos 6 anos e meio — através de vários upgrades de versão do Leap; e em seguida para Tumbleweed (no meu antigo PC). — Continua sólido no meu PC atual, com poucos pacotes do repositório packman-essentials (e do Google).

Tenho encontrado a mesma solidez no Fedora e no KDE Neon, através de sucessivos upgrades de versão — mas não me atendem tão completamente.

  • Tudo isso se alterou bastante, com a chegada do Plasma 6. — Hoje, é comum eu clicar para abrir algum aplicativo no openSUSE Tumbleweed, demorar a abrir, e acabar não abrindo. — E no KDE Neon com Plasma 6 (instalação nova), ainda não consegui muitas coisas que tenho na instalação antiga, com Plasma 5 (Ago. 2024).

Independente de tudo isso, gosto de usar o Void, o Redcore e o Slackware.

Um passo de cada vez

Uma “regra” fundamental que tento seguir (já que tenho 12 distros em dualboot para escolher), é “não forçar a mão”, nem recorrer a soluções “fáceis” porém duvidosas, por “necessidade de urgência”. — Já que o Arch me atende do modo tão completo, posso deixar “de molho” por semanas, meses!, qualquer problema que surja nas outras distros. — Sinto-me à vontade para gastar tempo em busca de soluções “limpas”, em vez de ceder a qualquer tipo de gambiarra improvisada.

Não é, só, que eu seja um “cara enjoado” (de fato, sou). — Mas tentar fazer as coisas com calma, um passo de cada vez, ajuda muito a ter mais certeza das coisas, em vez de apenas “achar que entendi”. — Posso experimentar várias hipóteses (sem embaralhar!), uma por uma, de modo a ter razoável certeza de qual suposta solução estava errada, e de qual realmente foi a resposta certa.

O que mais evito, é tentar meia-dúzia de coisas, uma após outra (sem desfazer uma, antes de tentar outra!) — porque desse jeito, no final é impossível afirmar qual tentativa ajudou (ou impediu) que a outra desse resultado. — É fundamental testar 1 variável de cada vez, pois quando se mexe em 3 ou 10 variáveis, ninguém pode concluir nada, sobre qual delas fez diferença, por si só, ou em conjunto com (quais?) outras.

  • Quando se embaralham variáveis, qualquer “conclusão” não passa de exercício do “é isso, porque minha intuição garante” — ou, pior, “é isso, porque eu sei, com base na minha sapiência”. — É melhor duvidar (sempre!) de nós mesmos, seguir um roteiro “impresso e auditável”, e apresentar todos os dados para que qualquer pessoa (contra ou a favor) tenha condições de repetir o experimento e informar à comunidade se deu certo ou não, em seu hardware, SO etc., bem especificado.

Em resumo: — Minhas conclusões podem estar erradas. — Por isso, procuro mostrar os elementos que recolhi, para qualquer colega poder verificar.

Hardware

Meu hardware ainda é o que montei em Janeiro 2020 — com alteração apenas dos dispositivos de armazenamento.

Em Maio 2023, instalei um 2º SSD de 480 GB (447 GiB) — e mais tarde desconectei os 2 HDDs de 1 TB (931 GiB) — que agora ficam em “gavetas” externas USB 3.0, para uso ocasional:

      Mobo: TUF B360M-PLUS GAMING/BR, BIOS 2401 03/22/2019 - ASUSTeK
      iGPU: Intel Corporation UHD Graphics 630 (Desktop)
Processors: 6 × Intel® Core™ i5-9400 CPU @ 2.90GHz (min / max: 800 ~ 4100 MHz)
    Memory: 15.5 GiB of RAM

Local Storage:             total: 894 GiB                 used: 251 GiB   (28.1%)

Sata #1   /dev/sda   SSD   Sata III   Kingston   SA400S37480G   447 GiB   probably 2019
Sata #2   /dev/sdb   SSD   Sata III   WD         WD Green 2.5   447 GiB   2022

External Storage:

USB 3.0 / 5 Gb/s     HDD   Sata III   Seagate    ST1000DM010    931 GiB   probably 2021
USB 3.0 / 6 Gb/s     HDD   Sata III   Seagate    ST1000DM003    931 GiB   2016

USB 2.0              SSD   USB 2.0    Samsung    S2 Portable    931 GiB   2011

Quando digo “mover” partições é, na verdade, copiar & colar (pelo GParted ou pelo KDE Partition Manager) — testar as cópias — e deletar os originais.

Fiz isso de 1º a 3 Maio 2023:

  • Copiei as partições Linux7 ~ Linux12 do 1º SSD (sda) para o 2º (sdb).
  • Copiei as partições Home7 ~ Home12, de um HDD para sdb.
  • Mudei os rótulos das partições originais para Linux7old ~ Home12old e alterei seus identificadores UUID — para testar o funcionamento das cópias em sdb, com os rótulos e UUIDs originais.
  • Após testar estas 6 distros em sua nova localização, deletei as partições originais Linux7old ~ Home12old.
  • Copiei as partições Home1 ~ Home6 do HDD para sda — alterei os rótulos e identificadores UUID das partições originais — e testei estas 6 distros com as cópias de suas partições /home, antes de deletar os originais.
  • Copiei a partição Swap do HDD para sda. — O GParted manteve o UUID na cópia, o que dispensou alterar 12 arquivos /etc/fstab.

Renomeei as antigas partições de documentos com “_X” para preservar seus arquivos

Três semanas depois, desconectei os 2 HDDs de 1 TB — um com 3 partições de documentos (Warehouse, Works, Sites) — e o outro, com a partição “Depot1”, onde faço os backups e guardo arquivos pouco acessados.

  • Em sdb, criei uma nova partição “Warehouse”, para os documentos de uso corrente a partir de agora — e copiei só o essencial da partição antiga.
  • Em sda, criei pequenas partições “Sites” e “Works” (2 GiB, cada), apenas para manter as configurações do Conky, do uDisks2, dos arquivos fstab, do rsync etc. — Ficam 140 GiB não-usados em sda.

Pastas renomeadas, para não serem esvaziadas pelos próximos backups

Renomeei os rótulos das partições antigas para “Warehouse_X”, “Works_X”, “Sites_X” — e também seus backups em “Depot1” e “Depot2” — para não serem esvaziados, ao fazer o backup semanal das novas partições.

Observações:

  • Para desmontar e lidar com as partições nº 1 ~ 6, usei uma distro do “2º grupo” (nº 7 ~ 12) — e vice-versa.
  • Para copiar a partição /home do openSUSE, em sistema de arquivos XFS, usei o KDE Partition Manager do MX Linux (pois o GParted não faz isso). — A cópia já veio com um novo UUID, e tive de editar o /etc/fstab do openSUSE. — Testei 2 vezes o funcionamento do openSUSE com a sua /home em novo local, com novo UUID.
  • No Slackware, uso o caminho (PATH) das partições de sistema no /etc/fstab — por isso, tive de alterar a raiz “/” para sdb2, a /home para sdb8 e o Swap para sda13. — Não é uma boa prática, pois às vezes sda e sdb podem se inverter; mas felizmente isso nunca me aconteceu com o Slackware (o mais comum é acontecer com o Redcore).

xxx

— … ≠ “•” ≠ … —

PC desktop UEFI / GPT

Ferramentas &tc.

Postado por Mboaba às quinta-feira, junho 15, 2023
Marcadores:

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)