segunda-feira, 6 de fevereiro de 2017

Reparticionamento dos discos rígidos - Epílogo

Debian clonado pelo GParted para concluir a reorganização do particionamento dos HDDs

Ao deletar o Windows XP instalado numa antiga partição sda1 de 40 GiB (29 Mai. 2016), já existia uma partição estendida sda2, — contendo 2 partições lógicas “E:\” e “F:\”, que na época precisavam ser mantidas. — Por isso, ao criar 2 partições ext4 de 20 GiB no lugar do antigo Windows, elas foram automaticamente classificadas como sda1 e sda3.

Em boa hora, essa “pequena correção” foi deixada de fora do remanejamento de sistemas Linux e reparticionamento dos discos rígidos (10 Jan. 2017), — façanha que, mesmo sem isso, deu muito mais trabalho do que gostaria de tentar nos próximos 10 anos. — Mas desse modo, a nova sequência ficou invertida: sda1, sda3, sda2.

• Ver “Reparticionando o 1º HDD (sda)”, em Remanejamento de sistemas Linux ao reparticionar discos (10 Jan. 2017).

A solução do problema ficou em segundo plano (matutando nos intervalos), até chegar a hora, — agora, para poder instalar um 9º sistema, após o Manjaro, o openSUSE e o Fedora. — Além disso, precisava carregar o Knoppix para conferir mais alguns itens do Quadro comparativo de sistemas Linux.

O roteiro imaginado era simples, — embora sujeito a dúvidas sobre alguns resultados:

  1. Carregar o Knoppix (Pendrive 16 GB), para usar o GParted com total liberdade.
  2. Copiar (clonar) o Debian instalado em sda3 para a unidade SSD externa.
  3. Deletar sda3 e sda2, — fora de ordem.
  4. Recriar 2 partições, — na expectativa de que se tornariam sda2 e sda3, — na ordem certa.
  5. Copiar (clonar) o Debian de volta para a nova sda3.
  6. Fazer os ajustes necessários para o Debian e demais sistemas não estranharem nada.
  7. Atualizar o Grub, para minimizar qualquer possibilidade de estranhamento.

Em Janeiro, para não complicar, apenas a /home do Kubuntu 17.04 foi movida para uma partição separada, — como teste-piloto, — mas as do KDE Neon e do Debian ficaram para ser movidas após esta última correção no particionamento geral.

• Ver “Movendo a pasta /home para uma partição separada”, em Remanejamento de sistemas Linux ao reparticionar discos (10 Jan. 2017).

Quadro comparativo das funcionalidades obtidas com diferentes sistemas Linux, até o momento
Quadro comparativo das funcionalidades obtidas com diferentes sistemas Linux, até o momento

Agora, foi decidido não testar o clone intermediário do Debian (no SSD externo), antes de deletar a partição sda3 original, — uma vez que o excesso de cautela apenas complicou o remanejamento de sistemas Linux e reparticionamento dos discos rígidos (10 Jan. 2017), aparentemente sem necessidade.

Para essa decisão de agora, contribuiu o fato de o Debian testing (não Stretch) estar longe de ser muito útil no dia-a-dia. — Indispensáveis, de fato, são o Kubuntu 16.04 LTS e o Linux Mint 18 KDE, — reforçados pelo bom desempenho do KDE Neon, e agora também pelo bom desempenho do openSUSE, nas atividades mais requeridas.

Também é verdade que, já por 2 ou 3 vezes, o Debian testing (não Stretch) ficou temporariamente fora de combate, — mas tem sido interessante conseguir recuperá-lo, — daí, o gosto de mantê-lo, com todo seu histórico, para continuar brincando e aprendendo.

Trocando 6 por ½ dúzia


Clonando a partição original do Debian (sda3) para o SSD externo pelo GParted, no Knoppix

Mover o Debian da segunda partição (antes chamada sda3), para a terceira partição (agora chamada sda3), tem certo sabor de “trocar seis por meia-dúzia”, — mas a divergência com “Linux2” e com toda a lógica do particionamento já provocou 1 ou 2 erros, — felizmente, sem consequências graves.

De outro ângulo, “trocar seis por meia-dúzia” era justamente o que convinha: — Exigiria o mínimo de alterações manuais nos links e caminhos (path) entranhados no próprio Debian, no Grub e nos demais sistemas.

Copiando de volta o Debian para sda3, — agora, de fato a terceira partição do disco rígido

Desse modo, bastaria substituir o antigo rótulo (label) Linux2 por um novo rótulo Linux3, — para que o maior número de “coisas” continuassem funcionando, sem necessidade de inúmeros ajustes manuais por toda parte.

Alterando o rótulo (label) do Debian, — que agora está, de fato, na terceira partição do HDD

A outra opção, — trazer o Debian de volta para a segunda partição (que agora é sda2), — exigiria fazer manualmente inúmeras correções, em vários pontos, de vários sistemas.

Enfim, ao não testar o clone intermediário (provisório) no SSD externo, não foi necessária nenhuma alteração no identificador UUID, — que foi, e voltou, o mesmo. — Ao final da movimentação, bastou desconectar o SSD externo, para não confundir as coisas, ao carregar o Debian realocado.

Uma vez testado e aprovado o Debian em sua nova partição, — clone exato da antiga, — bastará formatar a partição intermediária (provisória), no SSD externo. Assim, não haverá UUID repetido para causar confusão, caso esqueça o SSD conectado.

Preparando o teste do Debian


Arquivo /etc/hosts do Debian ainda continha (apenas) Linux3

Carregado openSUSE para preparar o teste, foi constatado que o /etc/hosts do Debian, — ainda com data de Setembro, portanto antes do re-particionamento geral, — continha (apenas) “Linux3”.

Este era seu “nome” desde quando foi deletado o Windows XP, para instalar o Debian e o KDE Neon (29 Mai. 2016), — e deveria ter sido alterado após o remanejamento de sistemas Linux e reparticionamento dos discos rígidos (10 Jan. 2017).

A mudança nunca foi feita porque, no Debian, o sudo nunca reclamou, — e afinal, já era previsto que o Debian talvez voltasse a ser Linux3.

Editando /etc/hostname

Já o arquivo /etc/hostname tinha sido alterado em 12 Jan., — e agora foi editado de novo, para voltar a Linux3.

Atualização do Grub, para testar o Debian em sua nova localização física

Por fim, foi atualizado o Grub, para dar chance a qualquer eventual ajuste que pudesse faltar.

É muito possível que isto fosse totalmente desnecessário, — afinal, o Grub já apontava para sda3 e para o mesmo UUID. — No entanto, como não sei “tudo”, não custava nada investir um minuto na precaução.

Teste do Debian


Debian carregado pela primeira vez, após a clonagem para nova partição

Reiniciado o computador, o Debian carregou dentro do tempo usual dos últimos meses, — e sem nenhum problema perceptível.

Uso do su para rodar o comando apt update, — e mais tarde, o sudo

O comando apt update (via su) apontou 124 pacotes a serem atualizados, — e ao aplicar, em seguida, o Synaptic incluiu mais 1 novo, a ser instalado.

Mais tarde, foi testado também o sudo apt update, — para conferir as boas relações entre /etc/hosts e /etc/hostname.

Às 23:17, foi concluído o relato dessa etapa inicial, — com 11 imagens editadas no Gimp, — e encerrada a primeira sessão do “novo” Debian, após 9h 29min de bastante atividade, sem problemas visíveis.

Ao todo, foram dispendidas menos de 2 horas na realocação do Debian, — incluindo algumas verificações do Konqueror e do Chromium, no Knoppix, para completar o Quadro comparativo dos sistemas Linux:

  • 11:43 a 13:22 - Knoppix
  • 13:31 a 13:45 - openSUSE
  • 13:48 a 23:17 - Debian “novo”

Ajustes nos demais sistemas


Situação ao carregar o Zesty Zapus, — a montagem automática passou de Linux2 para Linux3 (sda3)

As principais alterações a serem feitas nos outros 7 sistemas instalados consistiam em:

a) Montar automaticamente a partição Linux3 (sda3), — ao invés de Linux2 (sda3).

Em quase todos os  casos, — exceto openSUSE, — a montagem automática é definida em:

Menu → [Favoritos] → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis

Em todos esses casos (exceto openSUSE), a mudança aconteceu espontaneamente, pois tudo leva a crer que o comando udisks guiava-se por “sda3”, — que acompanhou o Debian na nova partição, — e usava o antigo rótulo (label) “Linux2” apenas para definir o ponto de montagem.

b) Definir a montagem automática da partição Home3, — ao invés da Home2, como antes.

Edição das configurações do Conky, no Kubuntu Zesty Zapus

c) Ajustar o arquivo /home/.conkyrc de cada um dos demais Linux, para o Conky monitorar o uso das novas partições do Debian, — Linux3 e Home3.

Ao carregar os demais sistemas (exceto openSUSE), o Conky apresentava os seguintes dados, na linha referente às partições do Debian:

a2 Debian    0B [______]   44,0MiB [______]

Era o resultado dessa antiga linha de código, no arquivo /home/.conkyrc de cada Linux:

a2 Debian  ${alignr}${fs_used /media/flavio/Linux2} ${alignr}${fs_bar 6,45 /media/flavio/Linux2}  ${alignr}${fs_used /media/flavio/Home2} ${alignr}${fs_bar 6,45 /media/flavio/Home2}

O índice “a2” era apenas um texto, indicando sua localização no 1º HDD (sda), e sua “numeração” como 2º Linux, — um lembrete, para facilitar a vida no dia-a-dia.

Depois dos ajustes, a linha de código ficou assim:

a3 Debian  ${alignr}${fs_used /media/flavio/Linux3} ${alignr}${fs_bar 6,45 /media/flavio/Linux3}  ${alignr}${fs_used /media/flavio/Home3} ${alignr}${fs_bar 6,45 /media/flavio/Home3}

E o Conky passou a apresentar os seguintes dados, — até ocorrer a montagem automática da partição Home3, no início da sessão seguinte, — ou até fazer a montagem manual pelo comando mount -a:

a3 Debian   8,56GiB [______]   0B [______]

Linha do /home/.conkyrc copiada de um sistema para outro, — com adaptações de pontos de montagem

A linha corrigida no Conky do Zesty Zapus foi então copiada para o Conky dos demais sistemas, — com algumas adaptações, pois os pontos de montagem (ainda) não estão padronizados:

  • /media/flavio/
  • /run/media/flavio/
  • /run/media/

Alteração das partições a serem montadas, pelo Particionador avançado do YaST2

Apenas no openSUSE, — onde a montagem automática do KDE não funciona, — o procedimento teve de ser diferente.

Arquivo /etc/fstab gerado pelo Particionador avançado do YaST2

O “Particionador avançado” do YaST2 foi utilizado para alterar as partições a serem montadas no início de cada sessão, — e ele grava as alterações no arquivo /etc/fstab.

Só que, neste caso, não é necessário esperar o próximo boot, — nem usar mount -a para antecipar o efeito. — O YaST2 se encarrega de fazer a montagem, no mesmo instante.

No próprio Debian, não foi necessário alterar mais nada, — pois dentro de cada sistema, o Conky refere-se a “/” e “/home”. — Se esta última não estiver numa partição separada, a taxa de ocupação é a mesma da partição do sistema.

Ao todo, foram dispendidas menos de 2 horas para fazer os ajustes nos 7 sistemas, — sem interromper outras atividades:

  • 23:21 a 23:45 - Zesty Zapus
  • 23:55 a 00:02 - KDE Neon User Edition
  • 00:08 a 00:15 - Kubuntu 16.04 LTS
  • 00:25 a 00:30 - Linux Mint 18.1 KDE
  • 00:34 a 00:44 - Manjaro KDE
  • 00:54 a 01:06 - openSUSE
  • 01:17 a 01:28 - Fedora

Movendo a /home do KDE Neon para outra partição


Usando o Debian para mover a pasta /home do KDE Neon (Linux1) para a partição Home1

Com o Debian finalmente em seu local definitivo, chegou a hora de mover sua /home, — e também a do KDE Neon, — para partições separadas:

Linux1/home → Home1, — no caso do KDE Neon

Linux3/home → Home3, — no caso do Debian

O procedimento consiste, basicamente, em 3 passos:

1) Mover o conteúdo da pasta /home, — subpastas user1, user2, user3 etc., — para a partição onde deverá ficar

2) Atribuir a propriedade de cada subpasta ao respectivo usuário, — no caso, só havia 1 subpasta “flavio”, pois nunca foi criada outra conta no Debian, nem no KDE Neon

3) Editar o arquivo /etc/fstab para montar a nova partição como /home, — de modo que a pasta original torna-se um link para a partição “home” separada

Naturalmente, a /home que será movida não pode estar em uso. — Para isso, recomenda-se:

login as root DIRECTLY at the server or boot from a rescue medium like KNOPPIX, this will not work over ssh (because then the /home directory is in use).

A primeira alternativa, — que não testei, — talvez possa ser obtida por Sair → Encerrar sessão, e na tela de Login usar CTRL-Alt-F1 para abrir um Terminal tty (tela preta) e logar como Root. Depois, basta saber tudo (ou ter tudo anotado em papel), e sair digitando e disparando os comandos, até concluir a tarefa.

Convenhamos que, com 8 sistemas instalados em paralelo (não em VM), isso pode ser feito de modo bem mais cômodo, — usar o Debian para mover a /home do KDE Neon, — e usar o KDE Neon para mover a /home do Debian, por exemplo.

• Ver “Movendo a pasta /home para uma partição separada”, em Remanejamento de sistemas Linux ao reparticionar discos (10 Jan. 2017).

Dentro do Debian, a /home do KDE Neon foi então movida com o comando simplificado:

su
mv -f flavio /media/flavio/Home1/

Usar su torna $USER=root, — e a propriedade de pasta do usuário comum foi atribuída a ele

Em seguida, — posicionado na partição Home1, — viria o passo de atribuir a propriedade da pasta ao usuário.

Este é um passo recomendado em todos os tutoriais examinados, e é seguido apenas por desencargo de consciência, — uma vez que a pasta já pertence ao (único) usuário “comum”.

Porém, neste caso específico, a tentativa foi feita de um modo errado, — e aconteceu exatamente o contrário do previsto:

su
chown -R $USER:$USER flavio

Ao usar su, o $USER em atividade passou a ser o root. — Mais tarde, ao examinar a pasta “flavio” no Dolphin, ficou claro que sua propriedade se havia transferido para root.

Tentando novamente o comando chown -R $USER:$USER, — agora, usando sudo

Após 2 tentativas frustradas de carregar o KDE Neon com sua nova partição Home1, este passo voltou a ser aplicado, — agora, do modo correto, — após verificar que a propriedade da pasta do usuário havia passado para o root.

Então, foi usado sudo, — que permite ao usuário comum rodar o comando como root, mas sem se tornar root. — Portanto, ao atribuir a propriedade da pasta a $USER, agora está realmente atribuindo ao usuário comum.

sudo chown -R $USER:$USER flavio

Depois disso, finalmente o KDE Neon carregou com sucesso, — sem qualquer problema ou demora, — e continua muito bem, após 3 dias de trabalho regular.

Copiando a linha da partição Home1 no arquivo /etc/fstab do Debian

Nesse meio tempo, já havia realizado o terceiro passo, — incluir a partição Home2 no /etc/fstab do KDE Neon, — com ponto de montagem /home.

O começo mais simples era copiar a linha referente à partição Home1 no arquivo /etc/fstab do Debian.

UUID=bf458c71-8224-4457-8faa-b4a16240fc66  /media/Home1  ext4  defaults  0  0

Arquivo /etc/fstab do KDE Neon, para montagem da partição /home separada

Em seguida, bastou colar essa linha no arquivo /etc/fstab do KDE Neon, — e fazer as adaptações necessárias.

# Home movida em 7 Fev. 2017
UUID=bf458c71-8224-4457-8faa-b4a16240fc66  /home  ext4  defaults  0  2

KDE Neon carregado com a nova partição /home

Após corrigir a propriedade da pasta do usuário (passo anterior), finalmente o KDE Neon carregou, — já com o Conky indicando menor uso da partição raiz, e o uso da nova partição /home.

Movendo a /home do Debian para outra partição


Movendo a pasta do usuário do Debian para a partição Home3

Mover a pasta do usuário do Debian para a nova partição /home.

Atribuindo (ou confirmando) a propriedade da pasta do usuário Debian

Atribuir a propriedade da pasta ao usuário Debian, por desencargo de consciência.

Arquivo /etc/fstab do Debian com a linha referente à partição /home

Acrescentar a partição /home no arquivo /etc/fstab do Debian.

# Nova Home3
UUID=9ecacf62-bfbf-4a15-8ab2-fbd46cadd7d6  /home  ext4  defaults,noatime  0  2

A inovação ficou por conta do parâmetro noatime, — que desabilita o registro da hora em que cada arquivo foi acessado (lido) pela última vez, — mas não o registro da última vez em que foi gravado.

Debian carregado, já com a /home em uma partição separada

Dessa vez, não houve qualquer percalço, e alguns minutos depois o Debian foi carregado com a /home em partição separada, — sem qualquer problema perceptível nos 3 dias seguintes.

Instalando CorelDraw e Word no KDE Neon


Exportando camadas selecionadas de um antigo mapa construído em CorelDraw

Com a /home do KDE Neon finalmente em sua partição definitiva, prosseguiram as experiências com o Wine, — instalar antigas versões do CorelDraw e do MS Word.

Não havia nenhuma fonte instalada na pasta /home/flavio/.wine/drive_c/windows/Fonts/ , — e o CorelDraw traz grande quantidade de fontes, que podem ser instaladas opcionalmente. — Ao todo, foram instaladas 100 fontes.

Mapa exportado em formato JPEG, com as camadas selecionadas

No primeiro teste, foi possível abrir um antigo mapa em camadas, selecionar algumas delas, e exportar o mapa em formato JPEG.

Antigo documento do MS-DOS Word, com acentuação codificada pelo Ventura Publisher

O Word também funcionou, — pelo menos para abrir um arquivo da década de 1990.

Agora falta substituir o arquivo normal.dot, por uma cópia contendo inúmeras macros personalizadas para converter a acentuação codificada pelo antigo Xerox Ventura Publisher.

Instalando CorelDraw e Word no Debian


Exportando camadas selecionadas de um mapa CorelDraw em formato JPEG, no Debian

No Debian, finalmente foi instalado o CorelDraw, e testada com sucesso a exportação de um mapa em formato JPEG, — porém a instalação do antigo MS Word falhou nos instantes finais (com direito a crash do LibreOffice Calc, que estava aberto). — A tentar novamente, mais tarde.

Na falta do menu de contexto “Abrir com wine”, comando “wine instalar.exe”

Ao contrário dos demais sistemas, no Debian o menu de contexto (right click) sobre o instalador, no Dolphin, não oferece “Abrir com Wine”. — A solução foi abrir um terminal no Dolphin (F4), posicionado no CD do instalador, e digitar comandos como “wine instalador.exe”.

Quadro comparativo dos sistemas instalados


Quadro comparativo dos sistemas instalados, com ao final deste relato

Nesse meio tempo, o KDE Neon avançou para o KDE Plasma 5.9.1, o Zesty Zapus avançou para Frameworks 5.30.0, — e o Linux Mint segue meio encrencado desde o upgrade para 18.1, embora não o bastante para tirá-lo da situação de “sistema principal”, ao lado do Kubuntu 16.04 LTS.

Com a instalação dessas antigas versões do CorelDraw e do Word, aumentou o utilidade do KDE Neon, — que enfrenta bem a navegação em “Páginas” do Facebook, além de rodar o Google Earth sem placa aceleradora 3D.

Para os usos mais requisitados no dia-a-dia, — parâmetro bastante pessoal, — openSUSE continua em segundo lugar, lado a lado com o KDE Neon.

Conclusão do reparticionamento


Situação final do particionamento dos discos rígidos

Com isso, termina o reparticionamento dos HDDs antigos e recentes, — com espaços para até 9 sistemas operacionais (ou 12, contando o SSD externo), todos com partições separadas para /home e Swap exclusivo, — afora as partições para dados de uso comum (Sites, Works, XTudo, Armazem1, Armazem2).

Como parte do processo, não ficou mais nenhum sistema com pasta /home na partição-raiz, — e qualquer um deles pode ser reinstalado ou substituído, sem perda de configurações, Wine, CorelDraw, dados do Google Earth etc.

Uma vez que o antigo particionamento (bem menos planejado) funcionou de meados de 2009 até Jan. 2017, — exigindo apenas 2 ajustes pontuais, em 2011 e 2016, — é de se esperar que este dure pelo menos mais alguns anos, já que a modularidade facilita a substituição de 1 ou vários sistemas.

Em caso de substituir os HDDs mais antigos, o mesmo modelo pode ser aplicado em novos discos de maior capacidade, — e os sistemas podem migrar para eles, com o mínimo de trabalho. — Nem a numeração precisa mudar.

O tamanho padronizado das partições de sistema e de “home” já se provou extremamente prático para a realocação de qualquer Linux, — mesmo com “etapa intermediária” (clone provisório no SSD externo), — sem a necessidade de redimensionar nada, nem desfazer nada depois.

A grande ameaça à durabilidade desse particionamento geral está na tecnologia, — uma vez que se baseia em BIOS, MBR, ext4.

Pode ser necessário alterá-lo, quando se tornar necessária Memória RAM superior aos atuais 4 GB, — pois a placa-mãe só aceita DDR2, que já não se encontra no mercado, e ainda ignoro tudo sobre BIOS, Legacy etc. nas placas atuais. — Porém, mesmo neste caso, pode sobreviver (ao menos, em parte), na medida em que o computador atual seja mantido (talvez em rede), com os HDDs mais antigos, ao lado de outro mais novo.

Ou em caso de defeito físico, — uma vez que até agora a CPU e a Memória RAM parecem longe de se tornar insuficientes para os usos requeridos.

Sequência da reorganização



___________
Relato inicialmente produzido no Debian testing, em 6 Fev. 2017; e complementado no Debian e no KDE Neon até 10 Fev. 2017.

— … ≠ • ≠ … —

Ferramentas &tc.


quinta-feira, 2 de fevereiro de 2017

Fedora 25 KDE - Instalação e configuração

Fedora 25 KDE

Dúvida sobre particionamento, — aliada à falta de sessão Live, para pesquisar na web, — fizeram interromper a instalação, e só retomar 1 hora mais tarde.

Instalador e tutoriais empurram o usuário para a criação de uma partição /boot separada, — além de considerarem ponto pacífico que o usuário deseja usar LVM. — Por isso, a primeira instalação acabou abortada, até apurar direito essa estória.

O Installation Guide para o Fedora 25 contém pelo menos 4 páginas diretamente relacionadas a essas 2 questões:

5.4.8. Installation Destination
5.4.10. Manual Partitioning
5.4.10.6. Recommended Partitioning Scheme
5.4.10.7. Advice on Partitions

Porém, lendo e relendo essas 4 páginas, — e abstraindo vários tópicos misturados, além de links cruzados para questões paralelas, sem relação direta com a dúvida, — fica um sabor de omissão e de esquiva. Não se encontra uma única afirmação positiva da necessidade (ou não) de uma partição /boot separada, — muito menos, um porquê.

Igualmente, fala de LVM como se todos já soubessem tudo a respeito, e não desejassem outra coisa na vida. — Porém, chama atenção a reiterada ressalva de que a pasta /boot não pode estar em um volume lógico (ou sub-volume) LVM.

Isto acende uma hipótese que explicaria o porquê da partição /boot separada. — Em vários momentos, as ressalvas abrangem o par, — “não pode estar em um volume LVM, nem em um subvolume BtrFS”.

Isso lembra a preferência do openSUSE por BtrFS, — com seus 19 sub-volumes, inclusive 2 sub-volumes para subpastas em /boot/grub2/, — mas não para a pasta /boot, propriamente dita (com o initramfs e o vmlinux), que propunha colocar em uma partição “tradicional”, separada.

Afirmações positivas e claras, mesmo, só fui encontrar no artigo “Disk partitioning in Fedora”, de Bruce Byfield, — um texto não-engajado no LVM, nem no particionamento tradicional, — e muito menos, a favor ou contra as opções do Fedora.

Livre da “obrigação” de ensinar “tudo”, — portanto, sem indigestão de assuntos paralelos, — o artigo dá o resumo da ópera, em especial nos tópicos necessários para fazer as opções imediatas e retomar uma simples instalação do Fedora 25 KDE:

  • Fedora suporta tanto o particionamento “tradicional”, quanto gerenciamento de volumes lógicos (LVM). Qual você deveria usar, é assunto de guerra santa, mas o Fedora adota LVM como padrão, “provavelmente” porque permite partições remotas, tornando-o atrativo para servidores e redes.
  • LVM oferece a vantagem de redimensionamento rápido. Partições tradicionais tomam mais tempo para alterar, mas são mais robustas, — se uma partição tradicional se corrompe, outras não são necessariamente afetadas, — enquanto o colapso de uma partição LVM pode levar ao colapso geral.
  • Raiz (“/”) e Swap são as 2 únicas partições indispensáveis. — Se você não criar nenhuma outra, todas as pastas do sistema serão alojadas na Raiz.
  • Você tem a opção de criar partições separadas para outras pastas do sistema, — o que pode protegê-lo em caso de ataques.

Era o que precisava saber, para prosseguir com a instalação, — sem fazer primeiro um PhD, — e deixar o estudo para a fase do relato, já com o Fedora 25 KDE funcionando, para observar e testar algumas dicas.

Montagem automática de partições


Montagem automática de partições pelas Configurações do sistema (KDE)

Montar automaticamente um punhado de partições adicionais, — este foi o maior desafio encontrado após a instalação do Fedora, — e retardou as configurações por mais 1 dia.

Por “partições adicionais”, refiro-me às que não fazem parte do sistema, — partições de outros sistemas, outras partições de documentos etc., — mas que precisam estar montadas desde o início da sessão, para o Conky exibir o espaço ocupado.

No Kubuntu, no Linux Mint KDE e no KDE Neon, basta marcar as partições desejadas em:

Menu → [Sistema, ou Configurações] → Configurações do sistema → Hardware → Armazenamento removível → Dispositivos removíveis
Mas isso é apenas uma interface gráfica, que traduz as opções do usuário em comandos e parâmetros, gravados em arquivo-texto, — como tudo, do Linux, — em algum lugar da “árvore” de arquivos e pastas, na partição de sistema (raiz).

Por trás dessa interface gráfica, o que existe são comandos udisks, — os mesmos usados pelo Dolphin, — de modo que o caminho (path) de montagem é padronizado, — /media/$USER/, em alguns sistemas; ou /run/media/$USER, em outros (regra modificável em /etc/udev/rules.d/99-udisks2.rules).

No Debian KDE, isso não funciona, — provavelmente, pelo mesmo motivo que não funcionou no Fedora, — mas seu Gerenciador de discos (Disk Manager) mostrou-se uma ótima interface gráfica para resolver a questão, inclusive com montagem instantânea, — muito melhor do que o Discos (gnome-disk-utility), — e com isso, não foi necessário aprender mais.

Gerenciador de partições do KDE edita pontos de montagem, grava em /etc/fstab, — e não consegue montá-los

O que estes 2 fazem, é gerar e gravar entradas no arquivo /etc/fstab, — e tentei fazer isso no Fedora, seja pelo Discos (instalado só para isso), seja pelo Gerenciador de partições do KDE (KDE Partition Manager).

Em princípio, não gosto do Discos, por misturar ações inocentes (montar partições, editar pontos de montagem) com ações potencialmente desastrosas (deletar partição, formatar), — mas acaba sendo melhor do que editar manualmente o arquivo /etc/fstab. — Se você edita à mão e não dá certo, você perde horas imaginando mil erros dos mais variados tipos, ao passo que uma interface gráfica exclui erros de digitação, de atenção e de imaginação criadora, pois segue padrões pré-estabelecidos.

Porém, o Gerenciador de partições do KDE não conseguiu montar, — por não existir o ponto de montagem definido nele mesmo (digitados manualmente, mas segundo padrões já vistos em vários sistemas). — Será que faltava reiniciar, para fazer efeito?

Fedora não carrega, porque udisks não tem permissão para montar partições adicionais do /etc/fstab

Nos 2 casos, ao reiniciar o computador, o resultado é que o Fedora simplesmente já não carregava.

You are in emergency mode. After logging in, type “journalctl -xb” to view system logs, “systemctl reboot” to reboot, “systemctl default” or “^D” to try again to boot into default mode.
Forneça a senha de root para manutenção
(ou pressione Ctrl-D para continuar):

Examinar os logs do sistema não trouxe qualquer inspiração, — pelo menos, até a linha nº 1.863, — e ainda faltava seguir inúmeros conselhos exibidos nessas 1.863 linhas, de examinar outras 1.001 coisas, talvez igualmente intermináveis (e remetendo a outras 999 coisas).

No emergency mode do Fedora, poderia usar vi /etc/fstab para desabilitar a entrada e seguir com o boot

Digitando um simples “reboot”, foi possível carregar outro sistema (openSUSE), para desabilitar a entrada do /etc/fstab que causava o problema, e continuar pesquisando, — até descobrir que o obstáculo estava em um emaranhado de “regras” ou “políticas”, — diferentes das que vigoram no Debian, por exemplo.

Até onde é dado a um leigo perceber, parece que criar ponto de montagem exige poderes de nível 1.300-e-alguma-coisa, mas udisks só alcança 1.100-e-lá-vai-pedrada, — ou será o contrário? — Por isso, o que no Debian acontece com naturalidade, no Fedora exige autorização por escrito (digamos assim).

É muito possível que essa burocracia reforçada, para montar partições adicionais no Fedora, derive de sua conformação ao uso de volumes e sub-volumes LVM.

Em tempo - Na verdade, não era necessário reinicializar o computador, para testar o /etc/fstab, — bastava um comando simples. — Nada como problemas, para aprender mais.

“… até descobrir”, é um modo de dizer, — nem tudo que reluz é ouro. — Por mais que parecesse fazer sentido, só um teste poderia confirmar ou descartar.

Me limitei a criar o arquivo “/etc/polkit-1/rules.d/90-udisks2.rules”, — sugerido no 4º link (abaixo), — copiar da página, e colar nele o conteúdo:

// 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; } });

Depois de 24 horas, montagem automática de partições no Fedora solucionada em 10 minutos

Desse momento em diante, todas as partições marcadas nas Configurações do sistema passaram a ser montadas automaticamente, no início da sessão, — e nunca mais foi pedida senha, nem de Root, nem de Usuário Administrador.

Só então, foi possível avançar com várias outras configurações, — mais ou menos paradas desde a véspera, por exigirem montagem frequente de partições adicionais para examinar outros sistemas Linux, consultar anotações etc.

Depois de pesquisar desde a véspera, a solução foi aplicada em 10 minutos, — tempo gasto para conferir links relacionados. — Depois que se encontra a palavra-chave, tudo parece óbvio.

Pistas - Chegaram a ser consultadas apenas algumas páginas. — Demorado, foi chegar a elas (entre centenas de outras), pesquisando “Fedora automount mountpoint” etc., — até descobrir que a palavra-chave era “polkit”:

  1. Mount NTFS partition on-demand without password?
  2. Fedora KDE: Automount NTFS Partition at Login
  3. Bug 1318473 - Can't add parttitions to fstab
  4. montar partição local on demand como usuário regular
  5. pklocalauthority

No mato sem Grub


xx

Wallpaper


Goiás “Velho”, em foto de Adelano Lázaro

Foto de Goiás “Velho”, por Adelano Lázaro.

O nivelamento foi feito pelo prumo dos elementos verticais, com ScreenRuler “sempre no topo”

A edição no Gimp limitou-se a um rotacionamento de -1,30º, para acertar o nivelamento; e em seguida, corte das bordas inclinadas.

O nivelamento foi feito pelo prumo dos elementos verticais, com ajuda do ScreenRuler “sempre no topo”, para não ser ocultado pelo Gimp durante o trabalho.

— … ≠ • ≠ … —

Não-debians


segunda-feira, 30 de janeiro de 2017

Consertando Kubuntu 17.04 Zesty após uma estranha atualização

Kubuntu 17.04 Zesty Zapus (development branch) sem Painel e sem Menu, após uma estranha atualização •

Uma atualização muito estranha deixou o Kubuntu 17.04 Zesty Zapus (development branch) fora de ação durante 1 semana, — até encontrar tempo e inspiração para consertá-lo.

Em resumo, carregava sem Painel e sem Menu, — ou carregava completo, mas logo começava a piscar, e desapareciam o Painel e o Menu.

Em algumas tentativas de carregamento, Painel, Menu etc. desapareciam, voltavam, e tornavam a desaparecer, — em rápida sequência, — mas o que prevalecia era, sempre, o desaparecimento.

Contexto anterior


Esse problema aconteceu em meio ao turbilhão do “Remanejamento de sistemas Linux ao reparticionar discos”, — durante o qual, o Zesty Zapus foi movido de uma partição para outra, o identificador UUID foi alterado, e o Kernel foi reinstalado para incorporar o novo UUID.

No entanto, parece pouco provável que aquela movimentação toda tenha qualquer responsabilidade nesse problema, — exceto, talvez, de modo bastante indireto.

12 Jan. 2017 - A reinstalação do Kernel provou ser a solução para incorporar o novo identificador UUID.

18:26 - Editado manualmente a entrada do Zesty Zapus no Grub, — com o novo UUID, — para que pudesse ser carregado.

18:50 - Uma vez carregado com sucesso o Zesty Zapus, o Kernel ativo (mais recente) foi reinstalado, via Synaptic, para incorporar o novo identificador UUID.

Commit Log for Thu Jan 12 18:50:29 2017

Reinstalados os seguintes pacotes: [resolver root=UUID no Grub]

linux-generic (4.9.0.11.15)
linux-headers-4.9.0-11 (4.9.0-11.12)
linux-headers-4.9.0-11-generic (4.9.0-11.12)
linux-headers-generic (4.9.0.11.15)
linux-image-4.9.0-11-generic (4.9.0-11.12)
linux-image-extra-4.9.0-11-generic (4.9.0-11.12)
linux-image-generic (4.9.0.11.15)
linux-libc-dev (4.9.0-11.12)

19:10 - Atualizado o Grub, para obter automaticamente, — do próprio Kernel do Zesty Zapus, — seu novo identificador UUID.

Synaptic definiu que apenas 76 dos 77 pacotes seriam atualizados

Depois disso, o Kubuntu 17.04 Zesty Zapus foi carregado com sucesso, — sem necessidade de correção manual do Grub.

Origem (provável) do erro


O pacote não-selecionado pela opção “Marcar todas as atualizações” exige decisão do usuário

19:56 - Após recarregar as informações dos repositórios, o Synaptic detecta 77 pacotes atualizáveis (+3 para instalar), — mas a opção “Marcar todas as atualizações” seleciona apenas 76 pacotes.

20:00 - O pacote automaticamente ignorado pela opção “Marcar todas as atualizações” levaria a desinstalar algumas sobrevivências do Plasma4, — por isso, teria de ser marcado por decisão consciente do usuário:

plasma-workspace 4:5.8.5-ubuntu2 (Plasma Workspace for KF5)

Plasma Workspace for KF5. Workspaces provide
support for KDE Plasma Widgets, integrated search,
hardware management and a high degree of customizability.

THIS WILL REMOVE YOUR KDE Plasma 4.

Infelizmente, não foi feita a simulação de marcar manualmente esse pacote, — e perdeu-se a oportunidade de registrar exatamente quais pacotes do Plasma4 seriam afetados, — pois depois disso, nunca mais o dilema voltou a se apresentar.

Mas, vamos por partes.

Lembrança ruim


Havia motivos para não querer decidir precipitadamente sobre a remoção de pacotes do Plasma4.

Algumas semanas antes, uma atualização do KDE Neon tinha removido vários pacotes do Plasma4, — e seu Konqueror ficou “aleijado” até hoje:

Commit Log for Mon Dec 19 16:30:50 2016 — [KDE Neon]

Removidos completamente os seguintes pacotes: *** [Konqueror amputado] ***

dolphin4
kde-baseapps-bin
kde-baseapps-data
konqueror-nsplugins
libappstreamqt1
libindi1
libjpeg-progs
libjpeg9
libkexiv2-11v5
libkexiv2-data
libkonqsidebarplugin4a
libkprintutils4
libnova-0.14-0
libokularcore7
libpoppler-qt4-4
libqimageblitz4
libqmobipocket1
libtidy-0.99-0

Desde esse dia, o Konqueror do KDE Neon deixou de exibir o Painel lateral (F9), — nem existe isso na sua Barra de menus, — perdeu a funcionalidade de converter arquivos PNG, JPEG, TIFF etc., e não oferece mais a montagem de imagens ISO.

Portanto, havia motivos para adiar a questão, — pois ainda faltava conferir e corrigir várias coisas urgentes, após a movimentação de sistemas de uma partição para outra, mudança de identificadores UUID etc.

Zesty bichado


Recovery mode instalava um pacote, — e desinstalava, — sem resolver o problema

Uma vez que o pacote não foi automaticamente incluído ao “Marcar todas as atualizações”, podia-se imaginar que sua instalação não fosse “obrigatória”, — segundo a visão de um leigo sobre o apt / Synaptic, que costuma brecar inconsistências. — Mas, faltava combinar que o Zesty Zapus ainda está em desenvolvimento.

Só que, depois disso, o Zesty Zapus nunca mais foi o mesmo, — pelo menos até ser consertado.

Várias vezes foi carregado o Recovery mode (Grub → Opções avançadas) e rodado “Consertar pacotes quebrados” (dpkg), — mas o resultado era apenas instalar um pacote, que logo em seguida era removido, — e não resolveu o problema.

KRunner (Alt-F2)


Konsole aberto por comando (via Alt-F2), para baixar as informações dos repositórios

Só no dia 19 finalmente foi encontrado tempo para tentar solucionar o problema, — torcendo muito para que, nesse meio tempo, alguma “correção de bug” já houvesse removido dos repositórios aquele dilema sem saída.

A falta de Menu foi driblada usando o KRunner (Alt-F2) para chamar o Konsole e/ou o Synaptic por comando.

Atualização Qt 5.6.1 para 5.7.1, pelo Synaptic

Lá estava, de novo, o pacote plasma-workspace 4:5.8.5-0ubuntu2, — que dessa vez, foi selecionado automaticamente, no meio de outros 200 (Qt 5.7.1), pelo “Marcar todas as atualizações” do Synaptic, — e não exigiu remover Plasma4.

Segundo o Histórico do Synaptic, foram removidos apenas 2 pacotes:

Commit Log for Thu Jan 19 12:28:57 2017

Removidos os seguintes pacotes:

libqalculate5-data
libqalculate5v5

Usando KRunner (Alt-F2) para reiniciar o computador, pelo comando reboot

Por fim, o KRunner (Alt-F2) foi usado para disparar o comando reboot, — a fim de verificar o resultado.

Zesty Zapus normalizado, — e Konqueror com todas as suas funcionalidades

Depois disso, o Kubuntu 17.04 Zesty Zapus (development branch) voltou a carregar normalmente, — e o Konqueror não perdeu nenhuma de suas funcionalidades.

Dois dias depois, o Kernel recebeu atualização, — de 4.9.0-11 para 4.9.0-12.

Por quê um Kubuntu em construção?


Sistemas pioneiros, instáveis ou em desenvolvimento podem ser pouco produtivos, para um leigo

Imagens ISO “daily-build” de sistemas ainda em construção são disponibilizadas principalmente para desenvolvedores, e/ou para usuários dispostos a testar, — com conhecimentos suficientes para fornecer um feed-back minimamente aproveitável. — Nenhuma das 2 hipóteses é o caso, para um leigo nesses assuntos.

O Kubuntu 17.04 Zesty Zapus (development branch) foi instalado em 27 Out. 2016, basicamente, porque calhou de o instalador do Yakkety Yak não funcionar, aqui, naquele momento específico. — Não tem Yak, vai Zap.

O objetivo inicial era não ficar alheio à evolução do Kubuntu, — e depois de 2 anos, ser pego de surpresa por novidades radicais, no próximo LTS.

De certo modo, — observar o futuro, — também tem sido a maior utilidade do KDE Neon, com seu KDE “rolling-release”, — e do Debian testing (não “Stretch”!).

Para um leigo, não são muito produtivos, — nem, com frequência, muito confiáveis.

Dessa falta de confiabilidade, porém, tem vindo um aprendizado interessante e, — por que não?, — útil.

Enfim, desde os primeiros dias do ano, foi disponibilizada a versão Alpha1, — e nos últimos dias, a versão Alpha2. — A versão final está prevista para 13 de Abril.

— … ≠ • ≠ … —

sábado, 28 de janeiro de 2017

Upgrade para o Linux Mint 18.1 “Serena” KDE

Upgrade do Linux Mint para 18.1 Serena
Upgrade do Linux Mint para 18.1 Serena levou apenas 11 minutos

O upgrade do Linux Mint 18 “Sarah” KDE para 18.1 “Serena” levou apenas 11 minutos, — mesmo parando para atender à recomendação de ler as páginas “Release notes” e “What’s new”.

Esse upgrade implicou na atualização de apenas 28 pacotes, — além da instalação de 2 novos, — e após reiniciar o computador, o Centro de Informações do Sistema (KInfocenter) não apresentou qualquer mudança em relação ao quadro anterior.

A relatar - Após 2 dias, registra-se um surto de uso de CPU pelo kwin_x11, ainda sem solução (31 Jan. 2017). — Na prática, não impede o trabalho, porém eleva um pouco a temperatura, — além de algum incômodo para consertar detalhes (Dolphin fora de lugar, Conky não abre sozinho etc.).

Características do Linux Mint 18.1 KDE Beta em Live USB, há 2 semanas, — só o Kernel era “novo”

Isso já era mais ou menos esperado, desde o teste Live USB com a versão Beta, há 2 semanas.

Lançada a versão final do Linux Mint 18.1 “Serena” KDE, a página “What’s new” também não apresentava grandes novidades, para quem tinha o Linux Mint 18 “Sarah” KDE, com as atualizações em dia.

Portanto, não havia nenhum grande motivo para fazer esse upgrade, — exceto acompanhar a evolução do Linux Mint.

O início e o final do processo estão resumidos na image inicial (no alto). — O processo e outros detalhes estão nos tópicos a seguir:

  • Preparação
  • Upgrade
  • Log das alterações
  • Kernel, à parte
  • apt & Synaptic
  • KDE, à parte
  • Kwin surtado
  • Histórico da instalação

Preparação


Atualizações do Linux Mint 18 KDE, — antes do upgrade para 18.1

O primeiro passo, — antes do upgrade, — foi aplicar todas as atualizações que ainda faltavam ao Linux Mint 18 “Sarah” KDE.

Por mero hábito, as informações dos repositórios foram buscadas pelo “apt update”, — e a aplicação foi feita pelo Synaptic, — cujo Histórico registra:

Commit Log for Sat Jan 28 01:35:46 2017


Atualizados os seguintes pacotes:

apt (1.2.18) to 1.2.19
apt-transport-https (1.2.18) to 1.2.19
apt-utils (1.2.18) to 1.2.19
firefox (50.1.0+linuxmint1+serena) to 51.0.1+linuxmint1+serena
firefox-locale-en (50.1.0+linuxmint1+serena) to 51.0.1+linuxmint1+serena
firefox-locale-pt (50.1.0+linuxmint1+serena) to 51.0.1+linuxmint1+serena
libapt-inst2.0 (1.2.18) to 1.2.19
libapt-pkg5.0 (1.2.18) to 1.2.19
virtualbox-guest-dkms (5.0.24-dfsg-0ubuntu1.16.04.1) to 5.0.32-dfsg-0ubuntu1.16.04.2
virtualbox-guest-utils (5.0.24-dfsg-0ubuntu1.16.04.1) to 5.0.32-dfsg-0ubuntu1.16.04.2
virtualbox-guest-x11 (5.0.24-dfsg-0ubuntu1.16.04.1) to 5.0.32-dfsg-0ubuntu1.16.04.2

Upgrade


Início do upgrade para Linux Mint 18.1 “Serena”

Fechado o Synaptic, foi usado right-click no ícone do Gerenciador de atualizações (mintUpdate) para abri-lo.

Na Barra de menu, “EditarAtualizar para Linux Mint 18.1 Serena”.

1:45 - Uma nova versão do Linux Mint está disponível.

1:45 - Por favor, leia as Notas de versão.

1:49 - Por favor, olhe as novas funções introduzidas na nova versão.

Aviso de riscos que novas versões sempre podem trazer etc.

1:50 - Aviso. — Novos lançamentos fornecem correções de erros e novas funções, porém algumas vezes podem introduzir novos problemas etc. — Ok, conheço os riscos e quero atualizar.

1:50 - Baixando informações dos repositórios.

1:50 - Volta a exibir o Aviso, — mas já não é clicável. — Parece mera falta de coisa melhor para mostrar.

1:51 - Baixando pacotes.

1:53 - Aplicando as alterações.

1:55 - Volta a exibir o Aviso, — mas não é clicável. — Parece mera falta de coisa melhor para mostrar.

1:55 - Seu sistema operacional foi atualizado com sucesso. Por favor, reinicie seu computador para que todas as mudanças tenham efeito.

Log das alterações


KDE, Frameworks, Qt, Kernel, — antes do upgrade do Linux Mint para 18.1 “Serena”

De acordo com o arquivo /var/log/apt/history.log, as operações realizadas foram:

Start-Date: 2017-01-28  01:52:11
Commandline:
/usr/sbin/synaptic --hide-main-window --non-interactive --parent-window-id 77594627 -o Synaptic::closeZvt=true --progress-str Por favor aguarde, isto pode levar algum tempo --finish-str Atualização concluída --set-selections-file /tmp/tmp2q96sbfj
Install:
mint-backgrounds-serena:amd64 (1.1, automatic)
iso-flag-png:amd64 (1.0.1, automatic)
Upgrade:
mint-translations:amd64 (2016.06.25, 2016.12.12)
mint-y-icons:amd64 (1.0.3, 1.0.4)
apturl-common:amd64 (0.5.2+linuxmint3, 0.5.2+linuxmint4)
mint-themes-gtk3:amd64 (3.18+8, 3.18+11)
mint-themes:amd64 (1.4.7, 1.4.8)
gdebi-core:amd64 (0.9.5.7ubuntu1, 0.9.5.7xmint4)
mintsources:amd64 (1.6.0, 1.6.4)
mintsystem:amd64 (8.2.9, 8.3.0)
ttf-mscorefonts-installer:amd64 (3.4+nmu1ubuntu2, 3.6)
gdebi:amd64 (0.9.5.7ubuntu1, 0.9.5.7xmint4)
mint-artwork-common:amd64 (2.0.9, 2.1.0)
apturl:amd64 (0.5.2+linuxmint3, 0.5.2+linuxmint4)
apturl-kde:amd64 (0.5.2+linuxmint3, 0.5.2+linuxmint4)
mint-common:amd64 (1.2.6, 1.2.7)
mint-meta-core:amd64 (2016.07.23, 2016.11.28)
mintdrivers:amd64 (1.3.3, 1.3.4)
mint-info-kde:amd64 (2016.01.11, 2016.11.02)
nvidia-prime-applet:amd64 (1.0.5, 1.0.6)
mint-meta-kde:amd64 (2016.07.23, 2016.11.28)
mintbackup:amd64 (2.2.4, 2.2.7)
mintstick:amd64 (1.2.8, 1.3.1)
mintupload:amd64 (4.0.8, 4.0.9)
mintupdate:amd64 (5.1.0.4, 5.2.0)
mint-y-theme:amd64 (1.0.9, 1.1.5)
bash:amd64 (4.3+linuxmint3, 4.3+linuxmint4)
mint-artwork-kde:amd64 (2.0.27, 2.0.28)
base-files:amd64 (18.0.2, 18.1.0)
mint-x-icons:amd64 (1.3.9, 1.4.0)
End-Date: 2017-01-28  01:54:57

KDE, Frameworks, Qt, Kernel, — depois do upgrade do Linux Mint para 18.1 “Serena”

É o mesmo que consta do Histórico do Synaptic, — exceto que este considera a hora da concordância com os “riscos” (Aviso), disparando o processo, — e coloca os pacotes em ordem alfabética, — além de jogar para baixo os 2 novos pacotes que, na verdade, foram instalados primeiro.:

Commit Log for Sat Jan 28 01:50:53 2017


Atualizados os seguintes pacotes:

apturl (0.5.2+linuxmint3) to 0.5.2+linuxmint4
apturl-common (0.5.2+linuxmint3) to 0.5.2+linuxmint4
apturl-kde (0.5.2+linuxmint3) to 0.5.2+linuxmint4
base-files (18.0.2) to 18.1.0
bash (4.3+linuxmint3) to 4.3+linuxmint4
gdebi (0.9.5.7ubuntu1) to 0.9.5.7xmint4
gdebi-core (0.9.5.7ubuntu1) to 0.9.5.7xmint4
mint-artwork-common (2.0.9) to 2.1.0
mint-artwork-kde (2.0.27) to 2.0.28
mint-common (1.2.6) to 1.2.7
mint-info-kde (2016.01.11) to 2016.11.02
mint-meta-core (2016.07.23) to 2016.11.28
mint-meta-kde (2016.07.23) to 2016.11.28
mint-themes (1.4.7) to 1.4.8
mint-themes-gtk3 (3.18+8) to 3.18+11
mint-translations (2016.06.25) to 2016.12.12
mint-x-icons (1.3.9) to 1.4.0
mint-y-icons (1.0.3) to 1.0.4
mint-y-theme (1.0.9) to 1.1.5
mintbackup (2.2.4) to 2.2.7
mintdrivers (1.3.3) to 1.3.4
mintsources (1.6.0) to 1.6.4
mintstick (1.2.8) to 1.3.1
mintsystem (8.2.9) to 8.3.0
mintupdate (5.1.0.4) to 5.2.0
mintupload (4.0.8) to 4.0.9
nvidia-prime-applet (1.0.5) to 1.0.6
ttf-mscorefonts-installer (3.4+nmu1ubuntu2) to 3.6

Instalados os seguintes pacotes:

iso-flag-png (1.0.1)
mint-backgrounds-serena (1.1)

Kernel, à parte


Características do Linux Mint 18 Sarah na antevéspera, — mantidas após o upgrade para 18.1 Serena

É verdade que uma instalação nova, — ou reinstalação, — teria introduzido nova versão do Kernel (4.4.0-53).

Porém, no upgrade, — assim como nas atualizações comuns do dia-a-dia, — atualizar Kernel sem motivo não é recomendado pela equipe do Linux Mint.

Aliás, não recomendam, sequer, a migração do 18 “Sarah” para 18.1 “Serena”, — a menos que você tenha um motivo para isso.

“Se funciona, não conserte”, — é a recomendação do Linux Mint, — mas a decisão é do usuário.

No Linux Mint, Kernel não é um “corredor-de-matadouro”, — mas um cardápio de opções

Ao invés de uma “linha do tempo”, — como se todos os usuários devessem substituir o Kernel a cada nova versão, feito boiada no matadouro, — no Linux Mint, isso é oferecido como um cardápio.

O usuário pode examinar todas as versões de Kernel oferecidas, — várias delas, não-adotadas nos instaladores do Linux Mint, — e analisar os relatos de bug de cada uma.

A qualquer momento, você pode escolher qualquer uma, entre várias versões de Kernel, — mais nova ou mais antiga, — e o upgrade do 18 “Sarah” para 18.1 “Serena” não se intromete nisso.

apt & Synaptic


Pela primeira vez, o Synaptic inclui Kernel na categoria Instalado (Atualizável)

Fiel a essa recomendação, — que se reflete na Política de Kernel do Linux Mint, — uma atualização para o Kernel 4.4.0-34, feita aqui sem pensar (20 Ago.), foi revertida dias depois, e o sistema permanece até hoje com o Kernel 4.4.0.21.

Isso é facilitado por uma alteração do Synaptic pela equipe do Linux Mint. — Não existe o item “Marcar todas as atualizações”, — e novas versões do Kernel não são incluídas entre elas.

Agora, pela primeira vez, — na minha experiência pessoal, — o Synaptic passou a exibir uma nova versão de Kernel na categoria Status → Instalado (atualizável).

É possível que isso também acontecesse após outros upgrades anteriores de “versão-de-ponto”, — e não tenha visto, apenas, porque nunca tinha feito isso.

Mas se persistir, vai tornar incômodo evitar a atualização do Kernel, — a menos que abandone o hábito de recarregar informações dos repositórios por apt update, para em seguida aplicar pelo Synaptic.

No Gerenciador de atualizações (mintUpdate), isso não é problema. — Versões de Kernel são apresentadas numa classificação que, por default, não se aplica automaticamente, — a menos que o usuário altere as Preferências.

KDE, à parte


Isto não significa que o Linux Mint KDE tenha parado no tempo. — Pelo contrário, uma mega-atualização surpreendente, de nada menos que 518 + 31 pacotes, deu um salto do KDE 5.6.5 para 5.8.4, — e em menos de 3 semanas, outra atualização levou ao KDE 5.8.5.

Portanto, se o upgrade para Linux Mint 18.1 “Serena” parece modesto, é porque o sistema vinha sendo regularmente atualizado, — e as grande novidades já estavam instaladas.

A verdade é que ambientes gráficos como KDE, Cinnamon, MATE, Xfce, LXDE, Gnome etc. são projetos independentes, uns dos outros, — cada um com seu próprio “timing”, — e só por acaso um deles daria um grande passo à frente, justo no momento em que o Ubuntu lança sua nova versão semestral, ou no momento em que o Linux Mint lança uma nova “versão-de-ponto”.

No caso do KDE, uma cooperação com a equipe do Kubuntu permitiu ao Linux Mint acelerar a implementação do KDE 5.8.

Em resumo, KDE também é um assunto específico, — e o upgrade do 18 “Sarah” para 18.1 “Serena” não tem relação com isso.

Kwin surtado


Problemas com kwin_x11, após 2 dias

31 Jan. 2017 - Surto de kwin_x11 ocupando CPU. — Ainda sem solução. — Não impede o trabalho, embora esquente um pouco. — Ao carregar nova sessão, Dolphin fora de lugar, e sem abrir o Conky.

Histórico da instalação


O antigo Linux Mint 17.3 Cinnamon foi instalado em 19 Jan. 2016, — com formatação da partição do sistema (“/”), antes usada por um antigo Kubuntu, — porém sem formatar a partição “/home”, que mantém a herança de vários sistemas anteriores.

O Linux Mint 18 “Sarah” KDE foi instalado ainda na versão Beta, em 20 Ago. 2016, — sem formatar a partição do sistema (“/”), que portanto, manteve várias pastas e arquivos do sistema anterior, — coisa que não se recomenda ninguém a fazer.

Ao ser lançada a versão final do Linux Mint 18 “Sarah” KDE, um exame de seus pacotes mostrou que a instalação Beta já estava atualizada, — por isso, não houve reinstalação (nem havia nenhum “upgrade” a fazer).

Portanto, o atual upgrade para 18.1 “Serena” foi feito em cima do 18 “Sarah” (inicialmente) Beta, — permanentemente atualizado.


— … ≠ • ≠ … —

Linux Mint