Translate

sábado, 15 de setembro de 2018

Fedora 28 KDE - install, config

Fedora 28 KDE instalado

Esta é minha 2ª instalação do Fedora, — ver Fedora 25 KDE (31 Jan. 2017), — e 6 horas depois, não carregava mais.

Depois de várias tentativas sem sucesso, já tinha desistido do Fedora 28 e me preparava para testar outra distro, — a ser precedida de um teste de badblocks nas partições.

Fedora 28 acabou salva por uma tentativa final, no último instante, — voltou a carregar, — e ganhou sobrevida, para continuar tentando, a duras penas.

No entanto, continuou apresentando problemas em série, por mais alguns dias. — Este relato teve um início precipitado, para registrar o essencial, “antes que acabe”. — Dias depois, foi encontrada a causa dos problemas, e Fedora 28 se tornou uma distro civilizada.

Índice


  • Sessão Live
  • Instalação: Anaconda
  • Problemas muito inconvenientes
  • Problemas menores
  • Inadequado para iniciantes?
  • Histórico de pacotes
  • Datação

Sessão Live


Verificação da imagem Fedora-KDE-Live-x86_64-28-1.1.iso por sha256sum

Foi escolhida a imagem Fedora-KDE-Live-x86_64-28-1.1.iso, — feita a verificação, — e gravada em DVD pelo K3b, para guardar.

No Menu de Boot, simplesmente escolhi o primeiro item, — “Start Fedora-KDE-Live 28”, — pois os demais não tinham interesse naquele momento.

Pelo KSysguard, fica claro que o Fedora KDE Live montou todas as partições Swap que encontrou, — comportamento inconveniente, a priori.

Por hábito, o ambiente foi preparado para várias atividades paralelas à instalação, — como abertura do Konqueror, para eventual pesquisa na web. — No caso do Facebook, ele abriu várias vezes como Mobile (m.facebook.com).

Papel de parede original do Fedora KDE Live 28, antes de reiniciar a sessão Plasma KDE

Pretendia digitar anotações de todo o processo no Kate (na verdade, KWrite), — com direito a data & hora exatas, via F7, — por isso, foi configurado Teclado ABNT2 (pt_BR) com acesso ao 3º Nível.

Ao reiniciar a sessão KDE (Logout / Login), — ideia boba, pois as configurações do Teclado não precisam disso para fazer efeito, — o papel de parede do Fedora 28 Live foi substituído pelo do KDE, — e caiu a conexão web.

Bastou Desconectar / Conectar pelo ícone da área de Notificações do Painel, para restabelecer o acesso à Rede.

Uso intenso de CPU ao iniciar o instalador Anaconda, no Live Fedora 28 KDE

Teria sido inútil configurar a área de trabalho na sessão Live, para instalação. — Ao clicar no ícone Install to Hard Drive, o instalador Anaconda ocupa toda a tela, — exceto o Painel.

Exame de hardware retarda a escolha do Idioma a ser usado pelo Anaconda, — e que afeta o Relógio

Há uso intenso de CPU, — desde o clique inicial, até vários minutos depois de escolher o Idioma a ser usado durante a instalação. — Suponho que se trata do exame do hardware, que neste caso abrange nada menos que 41 partições em 3 HDDs + 1 SSD externo.

Apesar disso, foi útil configurar o Menu (Cascade), KWrite, Konsole, Spectacle, além do Relógio. — Mas o fuso horário escolhido no início (UTC-0300) sofreu alteração pelo Anaconda. — Após escolher o Idioma a ser usado durante a instalação (pt_BR), Anaconda tornou a subtrair 3 horas (UTC-0600), sem atentar para o fuso escolhido (Time Zone); e apesar da sincronização NTP (que já veio ativada).

Após fechar o Konqueror, não foi mais possível reabri-lo (2 tentativas), — mas foi possível abrir 2 janelas do Konsole: uma para monitorar as atividades pelo Top; outra para tentar monitorar a Temperatura pelo Lm-Sensors (em vão: não existe isso na imagem ISO). — O KSysguard e o KWrite já estavam abertos antes do Anaconda.

Instalação: Anaconda


Etapas iniciais do instalador Anaconda no Fedora 28 KDE

Não existe uma ordem definida para as 4 primeiras etapas da instalação pelo Anaconda, — Teclado (adivinhou); Hora & Data (adivinhou); Nome do Host & Rede; Destino da instalação, — mas este último foi deixado para o final, por ser uma etapa crítica.

Particionamento dos HDDs + SSD externo para instalação de 12 distros Linux em dualboot

Diante do particionamento cuidadosamente organizado para permitir a convivência de 12 distros Linux em “slots” lado-a-lado, — sem interferência mútua, — não faria sentido permitir que o instalador Anaconda se esbaldasse e fizesse a festa, como bem entendesse.

Seleção do SSD externo e da opção de Particionamento “Personalizado”, no instalador Anaconda

Portanto, o caminho era selecionar um único disco, — o SSD externo, — e Particionamento “Personalizado”.

Nesse aspecto, é tranquilizador o aviso de que: — “Os discos não selecionados aqui não serão tocados”.

Essa garantia trouxe tranquilidade, mais adiante, — ao perceber que não tinha visto nenhum campo para selecionar a localização do Bootloader. — Era fundamental que o Anaconda não gravasse a trilha inicial (MBR) do primeiro disco (sda), de onde é chamado o Menu de inicialização da máquina, sob controle do Mageia.

Substituição de “LVM” por “Partição padrão”, no instalador Anaconda

Chegando ao Particionamento “personalizado” (manual) do SSD externo, o Anaconda agrupa as partições pertencentes a cada sistema instalado, — “Debian GNU-Linux 9” (MX Linux), “LMDE 3”, “Linux desconhecido” (Devuan 2), — e em “Desconhecido” uma partição de backup (Armazem1), que não pertence a nenhuma distro.

Esse agrupamento de partições, — segundo o sistema a que pertencem, — veio bem a calhar, para o sistema de “slots” adotado nessa máquina. Não faria sentido usar a partição-raiz de uma distro, a partição-home de outra, e a partição-swap de uma terceira distro.

Neste caso, seriam usadas as partições do MX Linux (Debian GNU-Linux 9), — que não tinha sido bem instalado e configurado. — O Plasma KDE implantado parecia sofrer várias interferências de resíduos de configuração do IceWM-Roxy original.

A primeira providência foi substituir a opção LVM, — “Logical Volume Manager”, preferida pelo projeto Fedora, — por partições “padrão” (tradicionais). Pretendia instalar o Fedora 28 em partições comuns, independente de quais partições seriam escolhidas.

Essa opção pessoal vem desde a instalação do Fedora 25, — quando pesquisei o assunto. — A meu ver, partições LVM não trariam nenhuma vantagem para um usuário comum, analfabeto em TI, com uma máquina antiga, 2 HDDs velhos e lentos (2008); 1 SSD externo USB2 bastante usado (2011); e apenas 1 HDD mais recente (2016).

Distribuição das 3 distros Linux mais “produtivas”, em 3 HDDs diferentes

No momento, o risco está “distribuído”, — das 3 distros que domino melhor, KDE Neon está em um HDD; Kubuntu em outro; Linux Mint em um terceiro, — de modo que qualquer falha em 1 dos 3 HDDs ainda deixa 2 distros habilitadas para todas as atividades.

Já o SSD externo tem sido usado para as mais variadas experiências, — Antergos, Sabayon, Devuan, antiX, MX Linux, LMDE 3; e agora, Fedora 28 KDE. — Nenhum motivo para misturar as coisas.

Até hoje, não houve necessidade de “redimensionar rapidamente” qualquer partição, de nenhum sistema. — Os tamanhos foram definidos uma única vez, com base na experiência de 9 anos com várias distros Linux; — e provavelmente só serão redefinidos ao montar outro hardware, com discos maiores e mais modernos, para atender as exigências previsíveis dos próximos 5 ou 10 anos.

Tampouco, nunca foi necessário “adicionar” nenhum “volume” ou partição, — nem local, muito menos “remoto”, — a qualquer um dos sistemas instalados.

Implantar LVM em uma máquina de uso puramente doméstico, — e cada vez mais superada, pelos parâmetros atuais, — só faria sentido para um estudante, ou aspirante a profissional, como ponto de partida em sua formação e aperfeiçoamento.

Pessoalmente, considerei uma experiência relativamente proveitosa, — ao instalar o openSUSE Leap em partição BtrFS, com /home XFS, em Janeiro de 2017. — Aprendi apenas o bastante para admirar a beleza dessa maravilha, que após mais de 1½ ano e 2 upgrades ainda não apresentou problemas. Até hoje, funciona com admirável suavidade e solidez. Mas o grande aprendizado é que aquilo tem um custo, — com frequência, a máquina fica semi-inútil durante vários minutos, ao carregar o openSUSE Leap pela primeira vez, de manhã, enquanto se realizam tarefas agendadas de manutenção  (snapper, btrfs, os_prober). Em suma, tenho uma segurança extra, — mas que o Linux Mint também oferece (a qualquer usuário “médio” ou iniciante), pela simples inclusão do Timeshift.

Seleção da partição-raiz do Fedora, no instalador Anaconda

Ao selecionar uma partição para o sistema, o instalador Anaconda detecta e indica o sistema de arquivos (ext4) e o rótulo (Label) pré-existentes. — Bastou preencher o ponto de montagem “/” e marcar para formatação. — Ao formatar, os rótulos (Label) são mantidos ou re-aplicados, o que é muito prático.

Transferência das partições da antiga distro Linux para a nova instalação do Fedora 28

O mesmo aconteceu com as partições Home e Swap, — exceto que esta última dispensa indicar ponto de montagem.

À medida em que as partições são escolhidas, “movem-se” do grupo da distro anterior — MX Linux (Debian GNU / Linux 9) — para o grupo “Novo Fedora 28 instalação”.

Resumo das mudanças a serem feitas nas partições

É apresentado então um sumário das partições que serão destruídas — e sua nova destinação, — para “Aceitar mudanças”, ou voltar atrás e corrigir alguma coisa.

Obs.: - Totalmente alheio a este Sumário, o instalador Anaconda “escolheu” o Swap11 (do LMDE) como “Resume device”, — coisa que só foi percebida e corrigida 2 dias depois.

Criação de usuário — opção de torná-lo Adminsitrador — e configurações avançadas, no Anaconda

Depois disso, surgem mais 2 etapas, — senha de Root — e Criação de usuário, com a opção de torná-lo Administrador.

Nas configurações avançadas de Usuário, é possível escolher outro nome para sua pasta pessoal; — alterar seu identificador (UID) ou o de seu grupo (GID); — ou incluí-lo em mais alguns grupos.

Como todas as distros precisam ler e gravar nas mesmas partições de dados, foi tranquilizador ver que o Fedora adota por padrão UID e GID=1000, — o mesmo nível das demais distros instaladas (exceto PCLinuxOS, que usa 500 por padrão, e teve de ser compatibilizado).

Ao final de cada etapa, clicar “Pronto”, no canto superior esquerdo da tela, 1 ou 2 vezes.

Instalação do Fedora 28 completada

Feito isso, a parte automática da instalação (slideshow) se realizou em cerca de 29 minutos, — das 11:42 às 12:11, — ou das 8:42 às 9:11, segundo o Relógio alterado pelo Anaconda.

Problemas muito inconvenientes


Falha em verificar e montar a partição-raiz. — Grub >> Advanced >> Rescue >> fsck

2018-10-19 - Fedora 28 KDE funciona bem desde o primeiro momento, há mais de um mês (2018-09-13, às 12h22), — configurações, instalação de novos pacotes, atualizações, trabalhos regulares etc., — exceto por 2 comportamentos muito inconvenientes:

  • Nos primeiros 5 dias: — Frequentes falhas de Boot, — e abundantes mensagens de erro, das mais variadas
  • Do 2º dia até hoje: — Após algum tempo de funcionamento tranquilo (meia hora, ou várias horas), a abertura de aplicativos começa a gerar mensagens de erro, — “(app)rc not writable”, — e não pára mais, até reiniciar a máquina, com uma pausa no meio do Boot para rodar fsck na partição /home.

Falhas de Boot foram muito frequentes nos primeiros 5 ou 7 dias, — a menos que depois tenha enjoado de fotografá-los, e por isso quase não haja registros após 2018-09-20. — De qualquer modo, depois dessa data dei um tempo no Fedora (apenas 3 ou 4 sessões não muito longas, em 3 semanas), para descansar a cabeça.

A falha de Boot afetava a verificação e montagem da própria partição do sistema. — A princípio, tentei o fsck a partir de sessões Live ou outras distros, mas isso apenas fazia o problema se repetir, mais tarde, e talvez pior. — Depois, passei a usar a opção Grub >> Advanced >> Rescue, que permite rodar fsck sobre a partição-raiz, quando ele não consegue montá-la.

É muito provável que essa mudança de procedimento tenha sido a solução do problema. — Na época, fiquei com a impressão de que a solução tivesse sido a correção do “Resume device” (2018-09-17 e 18), mas analisando agora, isso não parece fazer muito sentido.

Mensagens em série de arquivos de configuração “not writable”, após 9 horas de sessão normal

Depois disso, Fedora foi pouco usado durante cerca de 3 semanas, — um descanso, até voltar a insistir na pesquisa e solução de problemas, a partir de 2018-10-14, — mas as fotos de Boot (verbose) mostram mensagens de erro relacionadas apenas ao segundo problema.

Propriedade e permissões perfeitamente normais, em plena vigência do “not writable”

O segundo problema só começou 2 dias após a instalação do Fedora, — e não impede o Boot (apenas atrasa, até ser corrigi-lo), — mas é muito chato, quando você está concentrado em um trabalho importante, com vários arquivos e aplicativos abertos, pois praticamente obriga a fechar tudo e reinicializar a máquina, ou ficar clicando Ok o tempo todo.

Falha em iniciar verificação da /home, no Boot, após as mensagens de “not writable”

A partir do momento em que surge a primeira mensagem de “(app)rc not writable”, é certo que no próximo Boot surgirá uma falha em verificar e montar a partição /home. — Isso não chega a impedir o Boot. — Há uma pausa no tty (Emergency mode), você faz Login como Root, roda fsck na partição /home, tecla Ctrl-D (Exit) e o Boot se completa, com a perda de apenas 1 ou 2 minutos.

Só que, perdem-se as configurações feitas na última sessão, — o Klipper perde várias coisas que estavam na memória, — o Chromium reclama que não foi fechado corretamente etc.

Depois disso, você trabalha normalmente por mais algum tempo, — 2 horas, ou 9 horas, ou 30 minutos, — até o problema se manifestar outra vez.

Pelo que tenho lido nos últimos anos, parece muito possível que esses problemas se devam ao fato de não ter adotado partições XFS, ou LVM, — mas realmente não tenho conhecimentos bastantes para ter certeza. — Quem sabe, um dia volte ao Fedora, com o formato que ele “prefere”.

Problemas menores


1) Quando você aplica “propriedades de exibição” (view properties) para vigorarem apenas na /home e suas subpastas, — exibir arquivos ocultos + colunas Owner, Group, Permissions, — isto se propaga a todas as pastas das demais partições, nas quais você não quer nada disso.

2) Ainda não consegui me entender com o Fedora para exibir videos no Chromium.

3) ...

São coisas que talvez já estivessem resolvidas, com mais investimento de tempo e pesquisa, mas, — além de tomar esse “tempo”, — os problemas inconvenientes desestimulam o uso continuado do Fedora, no dia-a-dia.

Inadequado para iniciantes?


Embora não seja propriamente um “iniciante”, — com uma série razoável de problemas resolvidos nos últimos 11 anos, — fico muito tentado a concordar com a singela avaliação “Por qué no recomendamos Fedora (y otras tantas)”.

Inclusive na comparação com openSUSE Leap, que já passou por 2 upgrades e caminha para completar 2 anos instalado, sem fazer marolas.

Por enquanto, não há motivo para remover o Fedora 28 KDE, — se precisar de um “slot” para uma nova experiência, posso substituir o LMDE 3 KDE, por exemplo, que já cumpriu sua função como campo de aprendizado e experimentação. — Por vários motivos, vale a pena investir mais um pouco no Fedora.

Histórico de pacotes


Estado do Fedora 28 KDE recém-instalado, — antes de receber 962 atualizações

Ao carregar pela primeira vez o Fedora 28 KDE recém-instalado, já se apresentaram 962 pacotes disponíveis para atualização, — na verdade, 942 atualizáveis + 20 para instalar, como ficou claro logo adiante.

Pacotes efetivamente instalados com o Fedora 28 KDE

Antes de instalar essa avalanche de atualizações, foi documentado o estado inicial do Fedora 28, com todos os pacotes instalados e suas versões:

sudo rpm -qa > ~/rpm-qa-all-installed.txt

O arquivo obtido tem 1.746 linhas, — número presumível dos pacotes instalados pelo Anaconda, — e, de acordo com o Gerenciador de Partições do KDE, estavam ocupados 5,62 GiB da partição do sistema.

Um segundo comando gerou outra lista, — agora, em ordem alfabética, — para referência rápida a qualquer momento em que precise conferir alguma coisa:

sort rpm-qa-all-installed.txt > rpm-qa-all-installed-SORT.txt

Copiando em TXT o registro das atualizações instaladas no Fedora 28 KDE

Só depois disso, foram aplicadas as atualizações, — por comando, para copiar a lista em um TXT. — Digamos, alguma coisa como: “pacotes_historico_Fedora-28.txt”.

Uma lacuna na experiência anterior (Fedora 25), foi justamente ter me limitado a dar Ok às atualizações apresentadas na área de notificações do Painel, — e a usar o dnfdragora para instalar ou remover pacotes.

Ao contrário do Synaptic, essas “facilidades” do Fedora não oferecem pesquisa no histórico, — nem permitem selecionar e copiar a lista dos pacotes envolvidos, para documentar as operações em um TXT de consulta rápida:

pacotes_historico_Arch.txt
pacotes_historico_Debian-ex8-Testing.txt
pacotes_historico_Devuan2-KDE.txt
pacotes_historico_Fedora-28.txt
pacotes_historico_KDE-Neon.txt
pacotes_historico_Kubuntu-16-04.txt
pacotes_historico_Leap.txt
pacotes_historico_LMDE3b.txt
pacotes_historico_Mageia-6.txt
pacotes_historico_Mint-17-18.txt
pacotes_historico_PCLinuxOS.txt

É muito mais simples e prático consultar ou fazer buscas nesses arquivos TXT, — pertencentes ao usuário-padrão (UID=1000), e reunidos em uma só pasta, acessível a partir de qualquer distro, — do que em logs de sistema espalhados em pastas e subpastas de 12 distros diferentes.

Além disso, esses arquivos ficam preservados, quando uma distro é removida.

Por falta de um TXT como esses, não é mais possível saber, hoje, exatamente o quê foi instalado ou removido do Fedora 25, por exemplo. — Queria fazer melhor, agora, com o Fedora 28.

Naturalmente, esse TXT já começa enorme, e logo se tornará descomunal. — O do Debian testing, por exemplo (iniciado em 1º Out. 2016), já está com 26.715 linhas, — mas isso não é problema para um CTRL-F dentro dele, no Kate.

Você faz uma busca, digamos, por “Kernel”, — e rapidamente verifica todas as atualizações, instalações, reinstalações e remoções ao longo de meses, ou mesmo anos.

Busca por pacotes específicos no histórico de todas as distros instaladas

Tampouco é problema para um CTRL-F por conteúdo, no Dolphin, — em uma pasta com os TXTs de todas as distros. — Em um instante, você verifica, por exemplo, quais distros têm pyRenamer, ou apenas o KRename.

Esses TXT também incluem os pacotes manualmente instalados, — dentro da ordem cronológica dos acontecimentos, — e sempre utilizando F7 > date [Enter], no Kate, para documentar o dia e a hora aproximada do registro (exceto no caso do Synaptic, que já fornece a hora exata).

Horas mais exatas são dadas pelo histórico do Bash, — datado desde o primeiro dia:

1 2018-09-17_10-23-39 echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
2 2018-09-13_14-27-21 source ~/.bash_profile

[flavio@linux10 ~]$ history | grep install

27  2018-09-13_15-35-54 sudo dnf install rpm-build cabextract ttmkfdir
32  2018-09-13_16-16-57 sudo dnf install lm_sensors.x86_64
37  2018-09-13_16-49-53 sudo dnf install redhat-lsb.x86_64
39  2018-09-13_17-10-44 sudo dnf install chromium.x86_64
42  2018-09-13_17-16-42 sudo dnf install libreoffice.x86_64
45  2018-09-13_17-23-12 sudo dnf install gimp.x86_64
48  2018-09-15_09-48-20 sudo dnf install gnome-screenshot.x86_64
64  2018-09-15_14-08-27 sudo dnf install pyrenamer.noarch
65  2018-09-15_14-11-30 sudo dnf install krename.x86_64

Remoção do PackageKit pelo dnfdragora — sem direito a seleção e cópia da lista

Também costumo incluir nesses arquivos TXT os pacotes removidos, mas, — no caso específico do PackageKit e do Akonadi, no Fedora 28, — acabei abrindo uma exceção, para evitar o risco de eliminar algum pacote importante, no meio de um grande número de dependências.

Histórico de pacotes do dnfdragora não oferece busca nem permite seleção e cópia das listas

Aliás, foi assim que lembrei a impossibilidade de copiar a lista do dnfdragora, — pois já tinha até esquecido esse detalhe.

Uma primeira tentativa de recuperar essas listas a partir dos logs do sistema não deu resultado:

$ sudo cp /var/log/dnf.rpm.log-20180916 var-log-dnf-rpm-log-2018-09-16.txt
$ sudo cp /var/log/dnf.rpm.log var-log-dnf-rpm-log.txt
$ cat var-log-dnf-rpm-log-2018-09-16.txt | grep Cleanup > var-rpm-Cleanup.txt
$ cat var-log-dnf-rpm-log.txt | grep Cleanup >> var-rpm-Cleanup.txt

Com variações dos 2 últimos comandos, foram gerados extratos dos logs com os pacotes atualizados, instalados e removidos:

var-rpm-Cleanup.txt
var-rpm-Installed.txt
var-rpm-Upgraded.txt

Isso facilita as consultas, — mas não há registro dessas remoções feitas pelo dnfdragora. — Os logs incluem tudo o que ocorreu até esse momento, e tudo o que ocorreu depois.

É possível ter havido perda de dados, devido à série de problemas enfrentados desde a atualização inicial, — pois também se perderam sucessivas configurações (memória) do Gimp, Chromium etc., — e no bash_history falta pelo menos 1 comando.

Redução do uso inicial de Memória RAM após a remoção parcial do Akonadi (73+ pacotes) e PackageKit

Com a remoção do PackageKit (que “contamina” o uso inicial de Memória RAM), — e de 73+ pacotes ligados ao Akonadi, que “pesam” bastante, — o “consumo” do Fedora 28 KDE caiu de cerca de 830 MiB para cerca de 495 MiB.

Datação


O exame da instalação, configuração e solução de problemas foi feito, basicamente, a partir de:

  • Fotos de celular (dados Exif)
  • Capturas de tela
  • Histórico de comandos
  • Extratos de logs do sistema
  • Anotações em Caderno e em Notas.txt

As Capturas de tela, — inicialmente pelo KDE Spectacle; depois pelo gnome-screenshot, — já foram geradas no formato:

gnome-screenshot -p -f "/PATH/$(date +%F_%H-%M-%S)_F.jpg"

Para compatibilizar, as fotos de celular foram renomeadas pelo pyRenamer, — como poderiam ter sido pelo KRename, já que o Fedora oferece ambos, — no mesmo formato padrão.

No pyRenamer >> Imagens, — admitindo que as Fotos foram baixadas sem perda dos dados Exif:

{imageyear}-{imagemonth}-{imageday}_{imagehour}-{imageminute}-{imagesecond}_NL.jpg

No KRename, — admitindo que os arquivos foram gravados praticamente no mesmo instante das Fotos, — e baixados sem alteração de data e hora:

[creationdate;yyyy-MM-dd_HH-mm-ss]_NL[$16-[length]]

Com isso, basta reunir as Fotos e Capturas em uma pasta, para obter a sequência cronológica.

A datação do histórico dos comandos foi estabelecida logo na primeira hora:

echo 'export HISTTIMEFORMAT="%F_%H-%M-%S "' >> ~/.bashrc
source ~/.bash_profile

Anotações em Notas.txt usam o recurso F7 >> date [Enter] — que agiliza a digitação, — embora isto sirva apenas como referência aproximada, delimitando o que foi feito antes desse momento, ou o que será tentado desse momento em diante.

Ainda menos exatas são as anotações à mão, em caderno, — que precisam ser conferidas com outros elementos, a posteriori, — mas neste caso foram muito necessárias, devido a abundância de erros (extremamente repetitivos), durante vários dias, para evitar um excesso de Fotos e Capturas.

Mesmo assim, foram enfileiradas nada menos que 818 Fotos e Capturas de tela do Fedora 28 instalado, — afora 159 da instalação.

— … ≠ • ≠ … —

Não-debians


Postado por Mboaba às sábado, setembro 15, 2018
Marcadores: ,

Nenhum comentário:

Postar um comentário

Assinar: Postar comentários (Atom)