quinta-feira, 27 de outubro de 2016

Kubuntu 17.04 Zesty Zapus (daily-build) em drive SSD externo

Tela do Kubuntu 17.04 Zesty Zapus daily-build, instalado e configurado
Kubuntu 17.04 Zesty Zapus daily-build instalado no drive SSD externo

27 Out. - A instalação do Kubuntu 17.04 Zesty Zapus (daily-build), — sem prévio “teste de trabalho em Live USB”, — foi feita expressamente para conferir a “praticidade” de usar um Drive SSD externo de 1 Terabyte particionado para abrigar até 3 sistemas Linux (além de dados).

No entanto, a instalação foi tão tranquila, — e o Kubuntu 17.04 Zesty Zapus (daily-build) está funcionando tão bem, — que provavelmente será mantido e usado como “ambiente de produção” (alternativo), adicionando aplicativos, configurações e funcionalidades até onde for possível.


Uma vez que funciona, — e enquanto continuar funcionando, — o Kubuntu 17.04 Zesty Zapus torna dispensável “voltar atrás”, para insistir no Yakkety Yak. — O objetivo é acompanhar as novidades, para não ter surpresas, depois de 2 anos confinado no “LTS”.

Naturalmente, o controle do Grub foi devolvido a um dos sistemas instalados em HDD interno, — caso contrário, o SDD externo jamais poderia ser desconectado.

29 Out. - Uma tempestade forneceu o pretexto para desconectar o SSD externo, e confirmar que o Menu de inicialização funciona perfeitamente, sem ele. — Basta não tentar carregar o Kubuntu 17.04 Zesty Zapus, — nem qualquer outro sistema que venha a ser instalado nas demais partições da unidade portátil. — Ver “Configuração do Grub”, adiante.

31 Out. - Ao inicializar o computador, —  sem plugar o drive SSD externo, — e tentar carregar o Kubuntu 17.04 Zesty Zapus, o único efeito foi receber um aviso de erro do Grub. — Basta teclar “Esc”, para voltar à página inicial do Menu de inicialização, e escolher outro sistema.

1º Nov. - A partição do sistema foi redimensionada, — de 25 GiB para 40 GiB, — e em seguida o Kubuntu 17.04 Zesty Zapus voltou a ser carregado, para complementar este relato. — Já passou de 7 horas “uptime”, sem qualquer problema visível.

Download e Pendrive


Download do Kubuntu 17.04 Zesty Zapus (daily-build)
Página “Kubuntu 17.04 (Zesty Zapus) Daily Build”

Dois “crashes” do Instalador do Kubuntu 16.10 Yakkety Yak, no hardware local, levaram à busca de alguma dica, — uma vez que a ISO disponível ainda é a mesma já baixada e tentada antes, — e acontece que vários links do Google para “Yakkety” referem-se à fase de desenvolvimento. — E agora, quem está em desenvolvimento é o “Zesty Zapus”.

A imagem ISO baixada foi a “zesty-desktop-amd64.iso”, datada de 27-Oct-2016 05:46, tamanho 1.5G, descrição: “Desktop image for 64-bit PC (AMD64) computers (standard download)”, encontrada na página “Kubuntu 17.04 (Zesty Zapus) Daily Build”.

Provavelmente, é a mesma da página “Index of _mirrors_ubuntu-cdimage_kubuntu_daily-live_current”, onde aparecia datada das “06:46”.

Verificação sha256sum da imagem ISO do Kubuntu 17.04 Zesty Zapus (daily-build)
Verificação da imagem ISO baixada, pelo “sha256sum”

Gravação do Kubuntu 17.04 Zesty Zapus (daily-build) no Pendrive, por comando "dd"
Geração da mídia (Pendrive) pelo comando “dd”

Feita a verificação “sha256sum”, foi gerada a mídia “bootável” (Pendrive) por comando “dd”:

sudo dd if=/[PATH]/zesty-desktop-amd64.iso of=/dev/sdc bs=8M

Sessão Live


Erro no acesso às configurações do Espaço de trabalho > Temas, na sessão Live USB do Kubuntu 17.04 Zesty Zapus (daily-build)
Impossibilidade de acesso a “System settings → Workspace theme → Desktop theme”, em Live USB

A sessão Live USB do Kubuntu 17.04 Zesty Zapus (daily-build) foi carregada no dia 27, por volta das 17:05, e encerrada às 17:49, pouco depois de terminada a instalação no Drive SSD externo.

Devido aos “crashes” do Instalador do Kubuntu 16.10 Yakkety Yak, a sessão Live USB recebeu apenas as configurações mais necessárias, — e não foi instalado nenhum pacote adicional:

  • 17:05 - Fuso horário (São Paulo).
  • 17:07 - Relógio com data, fonte de letra FreeSans.
  • 17:09 - Dolphin parcialmente personalizado.
  • 17:11 - Wallpaper copiado e aplicado.
  • 17:13 - Invertidas as teclas de atalho do KDE Spectacle → “Print” para salvar, “Shift-Print” para capturar tela com retardo de 7 segundos (delay).
  • 17:14 - [constatado: “Desktop theme” inacessível, tal como no KDE Neon instalado e no Live Yakkety Yak].
  • 17:17 - Teclado PT-BR.
  • 17:21 - [constatado: Akonadi, PIM etc. não estavam carregados].
  • 17:21 - Monitor do sistema (KSysguard) e widget Relógio analógico na tela.
  • 17:24 - Iniciada a instalação.
  • 17:45 - Concluída a instalação.
  • 17:46 - PrintScreen movidos da “/home” (volátil) para a partição “F:\” do HDD.
  • 17:49 - Restart → “Please remove the installation medium, then press Enter”.

Instalação


A instalação durou cerca de 21 minutos.

Foi mantido o idioma-padrão do Instalador do Kubuntu 17.04 Zesty Zapus

17:24 - Foi mantida a Linguagem padrão do Instalador., lembrando o Bug #1611010 “yakkety desktop - non-english installation crashes”.

Opções: Baixar atualizações e Instalar software de terceiros

17:24 - Marcadas as 2 opções, — [x] Download updates while installing; e — [x] Install third-party software.

Ok, desmontar partições do HDD “sdb”

17:25 - Foi aceita a sugestão de permitir a desmontagem da única partição que havia sido montada, em “sdb”. — Para isso, os PrintScreen vinham sendo salvos na “/home” (volátil) da sessão Live USB.

Foi selecionada a opção “Manual”, para decidir quais partições seriam usadas

17:30 - Propostas de instalação “guiada” em Disk setup. — Selecionada a opção “Manual”, pois já estava feito o particionamento do Drive SSD externo.

Partição “sdd1” para instalar o sistema: Ext4, Format, “/

17:31 - Partições encontradas, para opções / operações manuais.

17:32 - Partição de sistema: “sdd1”, — uma vez que o Pendrive havia assumido a denominação de “sdc”.

17:33 - Partição Swap.

Desmarcando as partições Swap que pertencem a outros Linux: — “Don’t use this partition”

17:34 - Desabilitando partições Swap que não devem ser utilizadas.

Cada partição Swap desabilitada passa a ser mostrada como “linux-swap”

17:35 - Resumo:

  • sdd1 → Partição de sistema.
  • sdd6 → Partição Swap que será usada: — Não é necessário fazer nada.
  • linux-swap → Partições Swap que não serão utilizadas.
  • sda → Device for Boot loader installation.

Partições que serão formatadas: Última chance de arrependimento

17:36 - Confirmar partições que serão formatadas: — “sdd1” e “sdd6”.

17:36 - Timezone, country.

17:37 - Keyboard layout.

Dados pessoais e opções de Login

17:37 - Who are you? - Name, username, password, computer’s name.

17:38 - Login automatically.

O “slideshow” voltou à simplicidade: figuras pequenas, estáticas

17:38 - Slideshow. — Voltou à “simplicidade”: — Imagens estáticas (1 por etapa), — em vez das “animações” que consumiam recursos, e que à certa altura foram responsabilizadas pelo “crash” do Instalador (ver “Ubiquity Installer Crashes KDE Daily Build 16.10).

17:45 - Installation has finished.

Configuração do Grub


Menu de inicialização do Kubuntu 17.04 Zesty Zapus: apenas os erros existentes nas partições

O Menu de inicialização gerado pelo Grub do Kubuntu 17.04 Zesty Zapuscometeu” apenas os erros inerentes às instalações previamente existentes nas partições do computador, — e que não chegam a causar qualquer problema, no dia-a-dia:

  • Embaralhamento de Kubuntu LTS e KDE Neon, nas Opções avançadas do Kubuntu LTS
  • Detecção de um antigo Kernel do Linux Mint 17.3, nas Opções avançadas do Linux Mint 18

Porém, não interessava deixar o Boot na dependência do Drive SSD externo, pois isso obrigaria a mantê-lo sempre plugado.

A opção mais utilizada, nos últimos meses, é manter o Grub sob controle de 1 dos 2 sistemas mais estáveis e confiáveis, — em grande parte, por serem os mais explorados e “aprendidos” até agora:


Gravação do Grub atualizado no MBR, — pelo menu “Arquivo → Instalar na MBR

Dessa vez, o Grub-customizer do Kubuntu 16.04 LTS foi acionado para retomar o controle sobre o Menu de inicialização:

  • Atualizar o Grub do Kubuntu 16.04 LTS. — Ao ser aberto, o Grub-customizer verifica automaticamente os sistemas existentes, detectando qualquer novidade.
  • Desabilitar manualmente as entradas que não fazem sentido.
  • Alterar a ordem em que as entradas aparecem dispostas.
  • Determinar qual o “sistema padrão”, — independente de estar no topo, — e o tempo de espera, antes de carregá-lo automaticamente.
  • Passar para o final as opções de Memory test (MemTest86), pouco usadas no dia-a-dia.
  • Editar (pela interface gráfica) as fontes de letra, cores, destaques, imagem de fundo etc.
  • Gravar no Master Boot Record (MBR) a chamada para o Grub do Kubuntu 16.04 LTS.

O processo se mostrou cansativo, em vista do número de erros acumulados nas partições dos 2 HDDs, — e que se embaralham do modo mais confuso, no Kubuntu, — em especial, quando a detecção é feita pelo próprio Grub-customizer.

O resultado não agradou, — a cada passo, tornam a se desdobrar submenus que deviam permanecer recolhidos, — e no meio desse caos, acabei desabilitando a entrada principal do KDE Neon User Edition, por engano.

Modo mais simples de atualizar o Menu de inicialização e devolver o comando do Grub a um Linux

Voltei, então, ao mais prático: — Usar comandos simples, no Linux Mint 18 KDE, — onde o Grub costuma gerar um Menu de inicialização com poucos erros.

Na vez anterior, foram testados 2 comandos:

sudo update-grub
sudo grub-install /dev/sda

O primeiro comando atualizaria o Grub do Linux Mint, — e o segundo instalaria no MBR a chamada para o Grub do Linux Mint.

Desta vez, foi testada outra solução, — que se resume em 1 único comando:

sudo apt install --reinstall grub-pc

Este comando reinstalou o Grub do Linux Mint 18 KDE, — com o duplo efeito de atualizar as informações sobre os sistemas existentes, e gravar a chamada no MBR.

Na falta de Grub-customizer, a imagem de fundo, — permanente, — está apenas colocada “no caminho”, para ser automaticamente detectada e incorporada ao reinstalar o Grub.

O único inconveniente dessas opções simples, — por enquanto, — é que ainda falta estudar o arquivo de configuração do Grub, para que deixe de usar letras de cor cinza dentro das Opções avançadas.

Letras em cinza funcionam bem em fundo preto, ou muito escuro, — mas dificilmente são legíveis, com a maioria das imagens de fundo já experimentadas.

Obs.: - O Linux Mint foi deixado sem Grub-customizer, exatamente para dispor dessa alternativa de aprendizado, sem sua interferência.

Configurações e observações


Fantasma (meia-trava) ao arrastar janela de diálogo. — Nunca mais se repetiu (48 horas)

18:25 - Uma ligeira “meia-trava” produziu atraso ao arrastar uma janela de diálogo, nos primeiros minutos da sessão inicial do Zesty Zapus instalado, — coisa que não se repetiu mais, nesses 5 dias.

Ainda não visto, antes: — Pergunta sobre Firmware. — Do que se trata? Foi aceito? Rejeitado?

18:33 - Minutos depois, foi aberta uma “notificação” do Painel, e rodou o “Driver manager”, — coisa ainda não vista, nos últimos anos, — com uma citação do “Processor microcode firmware for Intel CPU's”. — O que se deve fazer?

Os PrintScreen não permitem avaliar se a consulta chegou a ser compreensível, ou se alguma opção foi exercida, em resposta.

  • Dias depois, — examinando o comportamento do “Driver manager”, — ficou claro que nenhuma opção foi exercida nesse primeiro momento. — Ver adiante.

Sem conexão, ao tentar instalar Flash-plugin

18:34 - O passo seguinte, — ainda em obediência às “notificações” do Painel, — foi tentar instalar pacote(s) para usufruir do “Flash”.

Porém, nesse momento ficou claro que a conexão da NET havia caído (voltou às 20:25).

Synaptic vs. “apt install”


Synaptic refém de um conflito: — “Corrija os pacotes quebrados primeiro”

20:31 - A princípio, nem o Synaptic, nem o QApt Batch Installer, nem qualquer outro recurso das “notificações” conseguiam instalar coisa alguma, — ao que parece, devido a um conflito entre bibliotecas do Flashplugin-installer.

Por isso, no primeiro dia, todos os pacotes necessários foram instalados pelo “apt install” ou pelo “apt-get install”, sem dificuldade alguma:

  • + lm-sensors
  • + fancontrol, hddtemp
  • + dolphin4, kfind, konqueror-nsplugins, konsole4-kpart, kpart-webkit
  • + konq-plugins, arj, kdiff3, kompare, xxdiff, krename

Registros cruzados do comando “history” com o “/var/log/apt/term.log”, — 27 Out. 2016:

    2  sudo apt install synaptic                      → 20:31
    7  sudo apt install conky-all                     → 20:42
    9  sudo apt install xsensors                      → 20:43
   11  sudo apt install psensor                       → 20:44
   13  sudo apt install gimp                          → 20:46
   15  sudo apt install exfat-fuse                    → 20:47
   19  sudo apt install konqueror krusader            → 20:50
   26  sudo apt install konq-plugins arj kdiff3 kompare xxdiff krename → 20:54
   28  sudo apt install xsane                         → 20:57
   30  sudo apt install kwrite                        → 21:00
   32  sudo apt install screenruler                   → 21:02
   34  sudo apt install gnome-screenshot              → 21:03
   36  sudo apt install pyrenamer                     → 21:04
   38  sudo apt install chromium-browser              → 21:07
   47  sudo apt-get install ttf-mscorefonts-installer → 21:39

Talvez isto sirva de pista para o conflito:

A instalação do Chromium sugeriu instalar “adobe-flashplugin”, — porém, não há sinal algum de que “flashplugin-installer” se tenha chegado a instalar com sucesso, em várias tentativas, por todos os meios possíveis. — No entanto, foi removido por um comando “apt-get autoremove” (ou “apt-get install -y -f”), por já não ser necessário.

Ao tentar reinstalar “flashplugin-installer”:

Os pacotes a seguir têm dependências desencontradas:
 flashplugin-installer : Depende: libpango1.0-0 mas não será instalado
E: Impossível corrigir problemas, você manteve (hold) pacotes quebrados.

Tentando instalar libpango1.0-0, para ver aonde isso podia levar:

Os pacotes a seguir têm dependências desencontradas:
 libpango1.0-0 : Depende: libpango-1.0-0 (= 1.40.1-1ubuntu1) mas 1.40.3-3 está para ser instalado
                 Depende: libpangocairo-1.0-0 (= 1.40.1-1ubuntu1) mas 1.40.3-3 está para ser instalado
                 Depende: libpangoft2-1.0-0 (= 1.40.1-1ubuntu1) mas 1.40.3-3 está para ser instalado
E: Impossível corrigir problemas, você manteve (hold) pacotes quebrados.

Só no outro dia, à noite, o Synaptic começou a funcionar, — aparentemente por se ter resolvido o conflito de bibliotecas, — e finalmente o flashplugin-installer pôde ser instalado:

Commit Log for Fri Oct 28 22:04:56 2016

Instalados os seguintes pacotes:

flashplugin-installer (11.2.202.643ubuntu1)
libpango1.0-0 (1.40.3-3)
libpangoxft-1.0-0 (1.40.3-3)

Konqueror: — “Mount and open CD image”

Depois disso, puderam ser instalados pelo Synaptic o fuseiso e o kde-service-menu-fuseiso, para o Konqueror montar e “abrir” imagens ISO como pastas comuns.

Também foi instalado o curl, — que até então não tinha feito falta alguma, — para uma brincadeira de ver o clima de Brasília, Aeroporto internacional de Brasília, fase da Lua etc.

Desde então, todas as atualizações e instalações de pacotes passaram a ser feitas pelo Synaptic.

Recovery mode


Salvar sessão; depois → Reiniciar → Recovery mode → Network / Dpkg

27 Out., 21:47 - Restart com passagem por Grub → Advanced options → Recovery mode → Network / Dpkg, para “consertar pacotes quebrados”.

É um hábito que tem surtido bons efeitos, após a instalação de vários Linux “derivados” do Debian, quando o Conky resiste a ficar transparente.

Ritual de magia para dar uma “arrumada” em sistemas acabados de instalar

Às vezes, isso não instala nem remove pacote algum, — mas, mesmo assim, depois disso o Conky finalmente adquire transparência.

Neste caso, porém, instalou o pacote “kubuntu-desktop_1.344_amd64”.

21:52 - Ao carregar novamente o Kubuntu 17.04 Zesty Zapus, o Conky já estava transparente.

Também valeu para a transparência parcial, aplicada ao Psensor, KSysguard, Xsensors, Konsole, KInfocenter, — para registrar o máximo de dados, — que só se tornou efetiva depois disso.

Workspace theme


Sem acesso às configurações da aparência (tema) da área de trabalho

Instalado o Kubuntu 17.04 Zesty Zapus (“development branch”), continuava impossível o acesso às Configurações do sistema → Tema da área de trabalho.

Finalmente, acesso às configurações da aparência (tema) da área de trabalho

Porém, depois do Recovery / Dpkg, a barreira simplesmente sumiu, — e finalmente pôde ser aplicado o tema Oxygen, — responsável pelo Painel / Menu escuro, semi-transparente (ou translúcido).

Mas este acesso às configurações do “Workspace theme” é de curta duração: — Só até (re)iniciar pelo modo “normal”, — sem passagem pelo “Recovery mode”.

“Some graphic drivers require a full graphical boot”

O motivo é que, ao retomar (“Resume”) o carregamento do sistema, a partir do “Recovery mode”, nem todos os drivers são carregados. — Para isso, é recomendado novo Boot.

Aviso do Linux Mint 17.3 Cinnamon, após “Recovery → Resume”

O antigo Linux Mint 17.3 Cinnamon costumava assinalar, — após cada “Resume”:

“Executando no modo de renderização de software. (…) rodando sem aceleração do hardware de vídeo, podendo ocasionar maior uso de CPU. (…) é recomendado usar esse modo somente para Solução de problemas”.

Portanto, o obstáculo às “Configurações → Tema da área de trabalho” fica suspenso quando não se carregam todos os drivers, — e o sistema entra em modo de renderização de software.

Para obter esse efeito, em especial, não é necessário fazer nada no “Recovery mode”, — basta entrar, e na mesma hora, — mandar “Resume”, para prosseguir o carregamento do sistema.

Maia transparent + Transparent Oxygen

Esse caminho “heterodoxo” foi testado uma dúzia de vezes, — tanto no Kubuntu 17.04 Zesty Zapus (daily-build), como também no KDE Neon User Edition, — e mostrou sua “utilidade” para (pelo menos), conseguir realizar essas configurações.

Não dá impressão de usar mais CPU, — pelo contrário, até parece usar menos, — mas ocorre algum retardo, por isso vale a pena fazer logo todas as experiências de configuração da Área de trabalho.

E fica aberto vasto campo para pesquisa e leitura, — sobre um mistério que, depois de decifrar, talvez pareça óbvio.

Isso lembra o “Driver manager”, notificado para rodar logo nos primeiros minutos após a instalação do sistema, — agora, traduzido para “Gerenciador de drivers”, — cujo mistério também continua intacto.

Após “Refresh driver list”, exibe uma opção (desmarcada) de usar firmware proprietário para CPU Intel, — porém a opção “em foco” para receber um “Enter” parece ser “Padrões”, — que “redefine todos os itens com seus padrões predefinidos”. Na prática, apenas deixa tudo como está no momento.

A única opção capaz de mudar alguma coisa, é marcar o firmware proprietário, — então, habilita-se a tecla “Aplicar”, — e ela exige senha de Administrador.

Pode-se, ainda, escolher “Ok” ou “Cancelar”, — dois modos de sair sem fazer nada, equivalentes ao “x” de fechar a janela.

Facebook


23:05 - É o segundo Linux instalado, onde se torna impraticável visitar “Páginas” do Facebook e compartilhar suas postagens, — o primeiro é o Debian “testing”, — embora o problema já se tenha manifestado em sessões Live USB com outras “distribuições” Linux.

Surto de CPU


Trava geral, — possivelmente, ao tentar ver a data e hora da última das fotos já baixadas

Prints “represados” por 4 minutos, até desplugar o cabo USB do smartphone. — Já vi isso no Mint Cinnamon

Ascensão e queda da temperatura do Core0, até fechar 3 notificações alucinadas de “dispositivo conectado”

28 Out., 8:55 - Trava geral com 2 Dolphin abertos, um deles exibindo as fotos do smartphone Nokia Lumia W8, o outro em uma pasta com quase 2.000 fotos já baixadas. — Atividade desvairada de CPU, liderada por “plasmashell” ocupando não menos que 50% de Core0 e Core1, simultaneamente. — Parcialmente “solucionado” pela retirada do cabo USB. — Notificações seguiram exibindo 3 atividades desvairadas, não-identificadas. — Foi feito Restart em seguida (9:20), uptime 11h 31 min da 3ª sessão do Zesty Zapus instalado, para eliminar excessiva atividade residual do processo “xorg”, ainda em torno de 13% ~ 15% da CPU.

9:39 - Após o restart, o smartphone Nokia Lumia WP8 voltou a ser conectado por cabo USB, e as 96 fotos foram copiadas para uma pasta vazia no HDD, sem nenhum problema ou dificuldade.

Conky


Aplicando “shades” ao Conky, para deixá-lo mais legível

Já estava incomodando, o nome do “Zesty Zapus”, no título do Conky, ficar borrado por algumas folhas mais claras da imagem de fundo.

A solução foi ativar “shades”, — mais discreto do que “outlines”, — o que também deixou mais legíveis os textos menores.

O truque está no contraste, — se cor da letra é clara, destaca-se onde o fundo é mais escuro, — e o delineamento parcial (embaixo, à direita) em cor escura destaca-se onde o fundo é mais claro.

O acréscimo de mais um Linux, — e do Drive SSD externo com várias partições, — também pedia mais algumas linhas.

No Kubuntu 17.04 Zesty Zapus, bastaram essas 2 linhas no arquivo “/home/.conkyrc”:

  • Terabyte ${alignr}${fs_used /media/flavio/Terabyte} / ${fs_size /media/flavio/Terabyte}  ${alignr}${fs_bar 6,60 /media/flavio/Terabyte}
  • Linux5 Zesty ${alignr}${fs_used /} / ${fs_size /}  ${alignr}${fs_bar 6,60 /}

uma vez que a partição “sdc1” é sua partição de sistema (“/”).

Nos demais sistemas Linux, a segunda linha precisava ser mais explícita:

  • Linux5 Zesty ${alignr}${fs_used /media/flavio/Linux5/} / ${fs_size /media/flavio/Linux5/}  ${alignr}${fs_bar 6,60 /media/flavio/Linux5/}

Refazendo o rótulo da partição pelo comando “sudo e2label /dev/sdc1 Linux5

A princípio, não funcionou, — porque o rótulo (Label) “Linux5” tinha sido apagado pelo Instalador, ao formatar a partição “sdc1”.

Foi necessário voltar ao Zesty Zapus para rotular novamente a partição, — pois nem o GParted, nem o KDE Partition Manager, conseguiram fazer isso a partir de outros sistemas:

flavio@Linux5:~$ sudo e2label /dev/sdc1 Linux5
[sudo] senha para flavio:
flavio@Linux5:~$ sudo e2label /dev/sdc1
Linux5

Outras configurações


xx
__________
Publicado às 11:43 do dia 27 e desenvolvido nos dias subsequentes, usando o Kubuntu 17.04 Zesty Zapus instalado na partição “sdc1” do Drive SSD externo.

— … ≠ • ≠ … —

Kubuntu & KDE


terça-feira, 25 de outubro de 2016

Particionamento de Drive SSD para vários Linux

GParted Live CD utilizado para particionar o Drive SSD externo Samsung de 1 Terabyte

O particionamento do “disco” SSD externo de 1 Terabyte foi um ensaio de planejamento, para fazer o mesmo, — sem os mesmos erros, — em um futuro HDD interno, provavelmente também de 1 Terabyte.

Também era intenção usar uma partição do drive SSD externo para instalar o Kubuntu 16.10 Yakkety Yak, — e se desse certo, já ficavam reservados espaços para outros 2 sistemas Linux, — com sobra.

Acabou sendo utilizada para instalar o Kubuntu 17.04 Zesty Zapus (daily-build 2016-10-27), — que está funcionando belamente, e cumpre o papel de acompanhar a evolução da “família” Ubuntu, entre uma “LTS” e a outra.

Sequência da reorganização



GParted Live


Verificação sha256sum da ISO GParted Live CD

À primeira vista, não havia motivo para usar o GParted Live CD, — exceto testá-lo. — É uma ferramenta fundamental, para se ter à mão. Só faltava conferir, ver como funciona, quais as limitações etc.

O GParted e o KDE Partition Manager já estavam instalados em alguns dos 4 sistemas Linux, e deveriam bastar, para lidar com partições que não são deles.

No entanto, há várias situações em que um sistema instalado dificulta ou impossibilita certas tarefas. — É preciso que as partições sejam desmontadas, — e não se tornem a montar, automaticamente, nos momentos mais inoportunos.

Além disso, se determinado Linux, — ou sua “/home”, — está em uma partição lógica, digamos, de número 5, será impossível deletar qualquer partição de número inferior, — de 1 a 4, — mesmo que não estejam montadas, nem tenham nenhuma relação com ele. — Foi o caso do Linux Mint, em “Particionamento de disco para vários Linux.

Gravação do GParted Live CD pelo K3b, em 2 minutos e meio

Foi baixada a ISO GParted Live CD, — diferente da destinada a USB, — e gravada usando o K3b, após verificar a integridade do download pelo sha256sum.

Situação inicial do Drive SSD


Tamanho e ocupação do Drive SSD Portable 1 Terabyte

O drive SSD externo foi recebido com uma única partição NTFS de 931,5 GiB, — e apenas 98,8 GiB ocupados.

Partição original, ocupando todo o Drive SSD

Redimensionamento da partição existente, — por arrastamento (gráfico) ou tamanho exato (numérico)

O primeiro passo foi mandar “encolher” aquela partição única para 117 GiB, — naturalmente, mantendo o sistema de arquivos NTFS, sob pena de perder tudo que havia ali.

  • A intenção era redimensioná-la para 120 GiB, porém ficaram faltando 2.880 MiB. — Embora o GParted apresente os valores em MiB, cabe ao usuário lembrar que a multiplicação deve ser feita sempre por 1.024. — Neste caso, 120 x 1.024 = 122.880.

Partição estendida, com todo espaço restante, para possibilitar a criação de mais partições lógicas

Os 814 GiB restantes seriam usados em uma partição estendida de 814 GiB, — recurso para driblar o limite de apenas 4 partições, — uma vez que dentro de uma partição estendia se podem criar várias partições “lógicas”:

  • Partição primária 1
  • Partição primária 2
  • Partição primária 3
  • Partição estendida
  • Partição lógica 1
  • Partição lógica 2
  • … (etc.)
  • Partição lógica “n”

A ideia é ter até 3 partições primárias para instalar sistemas Linux, — reservar um espaço no final da partição estendida para partições lógicas de Swap, — e deixar a maior parte do espaço para dados.

  • Essa disposição “corrige” alguns inconvenientes observados no atual particionamento dos 2 HDDs de 320 GiB, — cuja estrutura básica foi planejada em 2009.

Aplicação das mudanças no particionamento pelo GParted: — Menos de 50% após 1 hora

O redimensionamento começou a ser “aplicado” por volta das 2:05, e às 3:02 ainda estava longe da metade. — Foi deixado a rodar, e às 9:47 já estava concluído, — sabe-se lá desde quando.

  • Obs.: As horas são dadas pelas fotos de celular, — UTC -02:00 (horário de verão), — não pelo relógio no painel do GParted Live CD, que indicou sempre horário UTC.

Criação de uma partição lógica, dentro da partição estendida: — Quase instantâneo

O passo seguinte foi destinar 794 GiB da partição estendida para uma partição lógica em sistema de arquivos ext4, — deixando “sem alocação” apenas 19,5 GiB, no final, para futuros Swap

Essa “tarefa” se completou em poucos segundos.

Encerrando o GParted Live CD: — Partição NTFS “encolhida”, criada partição ext4, espaço restante

Encerrada a sessão Live CD do GParted às 10:02 (UTC -02:00). — Hora de carregar um sistema Linux “completo”, para ver o resultado.

Acesso negado para gravar na partição “ext4”: — Proprietário: — “Root”

O Dolphin abriu as 2 partições, — “Terabyte” (NTFS), com o conteúdo original; — e “Terabyte01” (ext4), vazia.

Porém, não foi possível copiar o conteúdo de uma partição para outra. — Acesso negado para gravação em “Terabyte01”, — que pertencia ao grupo Root, usuário Root.

Provavelmente, a melhor solução era apenas transferir sua “propriedade” para grupo “flavio”, usuário “flavio”, — mas existem pelo menos 4 sistemas instalados, e há controvérsia quanto aos direitos de “flavio” gravar nas partições “/home” de “flavio”, entre sistemas diferentes. — Ótimo tema para pesquisa e aprendizado, mas não agora, por um prazo imprevisível.

O sistema “Fat32” já é bem conhecido (partições F:\ e E:\), — nunca deu problema, exceto não seguir a datação Unix, — e o sistema NTFS também vinha funcionando bem, no Drive SSD, apesar da fama de desperdiçar recursos à toa.

Por isso, foi experimentado um terceiro sistema de arquivos, —  exFAT, — tido como não tão primitivo quanto o FAT32, nem tão gastador de recursos à toa, quanto o NTFS, — e mais adequado a unidades SSD e Pendrives.

  • Um bom motivo para tentar usar sistema de arquivos “ext4”, é a “sincronização” com o Lucky Backup, pois o uso de Hora UTC evita dores-de-cabeça, — em especial, no fim do Horário de verão.

Desmontando a partição, para que suas “Propriedades” se tornem editáveis

A “aplicação” dessa mudança na partição ainda vazia foi feita pelo KDE Partition Manager, no próprio Linux Mint, — que seria usado para copiar os arquivos:

10:42 - Right-click em “sdc5” → Desmontar (para que suas “Propriedades” possam ser alteradas).

10:43 - Right-click em “sdc5” → Propriedades (editar).

10:50 - Alterada seleção, de “ext4” para “exFAT”.

10:51 - Aviso: — “Você está prestes a perder todos os dados da partição /dev/sdc5. Alterar o sistema de arquivos de uma partição já existente fará com que todo seu conteúdo seja apagado. (…) todos os seus dados serão irrecuperavelmente perdidos”. — Yes.

10:51 - Alterada a etiqueta (Label) de “Terabyte01” para “Terabyte”.

10:51 - Aplicar. — “Aviso: isso irá modificar permanentemente seus discos”. — Aplicar.

10:52 - Concluído (cerca de 7 segundos).

Instalando “exfat-fuse” para habilitar a montagem (leitura e escrita) em partições exFAT

Feito isso, o Dolphin não conseguia exibir a nova partição exFAT, em nenhum dos 4 Linux, — “unknown filesystem type exFAT”.

Mas bastou instalar o pacote “exfat-fuse”, — em cada um deles, — para habilitar a montagem e exibição da partição exFAT no Dolphin, Konqueror e Krusader.

Montagem ao conectar: — Evitar montagem no início de cada sessão

11:09 - Início da cópia dos arquivos para a nova partição exFAT. — Duração 3h 20 min (até 14:29).

11:50 - Enquanto isso, exame das “Configurações do sistemaDispositivos removíveis”.

Parecia que o Drive SSD externo não precisava ser marcado para montagem no início da sessão, — uma vez que já está habilitada a opção geral de montar mídias removíveis ao serem conectadas. — Mais tarde, a experiência mostrou que não é bem assim.

E a vida continua: — Atualizações do Linux Mint, via Synaptic

11:54 - Ainda durante a cópia dos arquivos, — atualizações do Linux Mint, pelo Synaptic.

Temperatura e fornecimento de energia, — por volta da metade da cópia, às 12:45

12:45 - Durante todo o processo de cópia entre as partições do Drive SSD externo, a única alteração nos níveis de energia foi a tensão Vcore, sempre próxima de 1,27V, — o que parece normal, dado o surto de atividade intensa, com a CPU trabalhando sempre perto de 100%, — em contraste com uma tensão de 1,20V ~ 1,21V na maior parte dos outros dias.

Uma vez que o Drive SSD não tem “motor”, não puxa energia da saída de 12V da fonte do computador, — usa apenas a saída de 5V, que se manteve em torno de 4,97V, — nível bastante comum no dia-a-dia, quando costuma oscilar entre 4,97V ~ 4,99V.

Conclusão da cópia dos arquivos entre as 2 partições do Drive SSD externo

14:29 - Concluída a cópia dos arquivos para a nova partição exFAT.

Sincronização das pastas originais e copiadas, pelo Konqueror

Ao final, foi usado o Krusader para “sincronizar” as pastas e arquivos originais com as cópias, — em busca de “diferenças” de qualquer tipo, que pudessem indicar falhas.

Pacotes necessários para o Konqueror sincronizar pastas

Instalação do KDiff3 e do Kompare, pelo Synaptic

Para isso, foram instalados os pacotes KDiff3 e Kompare, no Linux Mint e no Debian testing.

  • Esses pacotes já tinham sido instalados no Kubuntu e no KDE Neon, ao adubar o Konqueror. — Talvez, agora, bastasse um dos dois pacotes, mas nesse caso, o que abunda não prejudica.

Resultados da comparação originais / cópias, em andamento

A “sincronização” ou comparação foi feita até o enésimo-milésimo arquivo, — sem encontrar qualquer erro, — e a verificação foi considerada satisfatória.

  • Há muitos anos não se registra um caso de cópia com defeito, — embora tenha perdido a conta das horas investidas em verificações. — Mas, é recomendável verificar sempre, até o fim.

Apagar e criar partições com o KDE Partition Manager

15:12 - A partir daí, a antiga partição NTFS, — “encolhida” para 117 GiB, — foi desmontada e “apagada”, — utilizando o KDE Partition Manager, instalado no Linux Mint 18 KDE.

Em seu lugar, foi criada uma nova partição primária “sdc1” (ext4), de 24,4 GiB, — rotulada “Linux5”.

Restaram ainda 93 GiB “não-alocados”, para mais duas partições primárias e/ou expansão futura.

No mesmo passo, foi tentado criar uma partição lógica de Swap, — mas um erro impediu de completar o conjunto de tarefas.

Montagem automática, tão logo a nova partição foi criada

A nova partição “sdc1” (ext4) foi automaticamente montada, — de imediato, — e os últimos passos do processo não se puderam realizar.

Mensagem do KDE Partition Manager: — “/dev/sdc1 is mounted”

Este é um caso típico, em que o uso do GParted Live CD evita interferência, — sem ter de alterar as configurações de montagem automática do Linux Mint, por exemplo (e depois lembrar de refazê-las).

A partição lógica “Swap5c”, de 3,9 GiB teve de ser criada mais tarde. — E restaram 15,6 GiB de espaço não-alocado, no final da partição estendida, para usos futuros.

Desse modo, ainda será possível criar mais 2 partições primárias, e mais 2 Swap, — com bastante folga, caso precisem ser maiores do que hoje.

Verificação e correções


Aviso do GParted, de que a verificação (e reparação) pode causar perda de dados

26 Out. - Utilizado o GParted Live CD para verificar a partição “sdc1”, — uma vez que o KDE Partition Manager do Linux Mint parece não ter concluído essa tarefa.

Além disso, foram feitas 2 pequenas correções:

Deixar a partição “sdc1” com 24,4 GiB não constitui problema algum, — os outros 4 Linux estão instalados em partições de 16 ~ 20 GiB, e não ocupam nem a metade.

O mesmo se pode dizer do “Swap5c”, com 3,9 GiB, — os outros Linux dispõem de 4 GiB, mas raras vezes chegaram a usar a metade disso.

Esses tamanhos foram “corrigidos”, — ou, “arredondados”, — apenas como exercício:

  • Para chegar a 25 GiB, é necessário multiplicar 20 MiB x 1.024 = 25.600 MiB.
  • Para chegar a 4 GiB, multiplicar 4 MiB x 1.024 = 4.096 MiB

Essas pequenas correções de tamanho foram feitas no GParted, sem qualquer susto ou novidade, uma vez que essas 2 partições ainda estavam vazias.

Teste de uso


27 Out. - Instalado o Kubuntu 17.04 Zesty Zapus (daily-build 2016-10-27) em “sdc1”, usando “Swap5c”.

29 Out. - Uma tempestade forneceu o pretexto para desconectar o drive SSD externo, e confirmar que o Menu de inicialização funciona perfeitamente, sem ele. — Basta não tentar carregar o Kubuntu 17.04 Zesty Zapus, — nem qualquer outro sistema que venha a ser instalado nas demais partições da unidade portátil.

31 Out. - Ao inicializar o computador, — sem plugar o drive SSD externo, — e tentar carregar o Kubuntu 17.04 Zesty Zapus, o único efeito foi receber um aviso de erro do Grub. — Basta teclar “Esc”, para voltar à página inicial do Menu de inicialização, e escolher outro sistema.

Teste de fogo


Relatório do GParted Live CD após redimensionar a partição “sdc1”, onde está o Kubuntu 17.04 Zesty Zapus

1º Nov. 2016 - Depois de instalado e bastante configurado o Kubuntu 17.04 Zesty Zapus, o GParted Live CD foi carregado outra vez, para redimensionar sua partição de sistema, — de 25 GiB para 40 GiB.

Kubuntu 17.04 em funcionamento normal, após ter sua partição redimensionada para 40 GiB

Em seguida, o Kubuntu 17.04 Zesty Zapus foi carregado, — sem qualquer problema visível, — e usado para complementar este relato:

  • Baixar as fotos do celular
  • Renomear as fotos por data e hora, usando o pyRenamer
  • Editar as imagens no Gimp
  • Publicar este acréscimo ao relato

Após 7 horas de trabalho, nenhum problema foi detectado no Kubuntu 17.04 Zesty Zapus.

Antecipando


Konqueror em Modo de visualização “Tamanho de arquivo”, — ótimo para análise rápida do espaço que ocupam

Receber de presente o Drive SSD externo (“portátil”) provocou uma reavaliação dos planos, — o quê adquirir, “em vez de” o planejado SSD, — e uma revisão dos métodos de backup, utilizados até então.

Antes, havia os seguintes espaços em disco:

Partição sda6 F:\   180,0 GiB Fat32 → Arquivos de trabalho
Partição sda5 E:\    70,0 GiB Fat32 → Sites + arquivos excedentes
Partição sdb5 Home1 176,0 GiB ext4  → backup de F:\
Partição sdb7 Home2  73,5 GiB ext4  → backup de E:\

O objetivo dessa “divisão de trabalho” é, — no mínimo, — manter o backup em um disco separado dos arquivos originais, de trabalho. O ideal era ficar em outro prédio, de preferência bem afastado.

A conversa com o ex-proprietário do “Terabyte”, — agora, feliz proprietário de outro SSD externo maior, — agilizou a compreensão de alguns pontos, que talvez demorasse mais pelo método empírico de tentativa-e-erro, por mais que se tente evitá-los, pesquisando antes:

  • Disco externo pode ser conectado 1 vez ao mês, por exemplo, para o backup, — não há necessidade de manter plugado o ano inteiro, — uma vez que SSD externo tem vida mais curta do que o HDD, em número de gravações. Trata-se, portanto, de um SSD bastante “poupado”, desde a aquisição inicial, e com boas chances de ainda ser útil por muitos anos.

  • Backup, quem tem 2, tem 1, — e quem tem 1, não tem nenhum. — De fato, não parecia nada seguro, deixar de manter os backups em HDD, que já comprovou ser mais garantido do que CD / DVD, em certas circunstâncias (além de 1.000 vezes mais prático).

A primeira ideia foi adquirir um segundo SSD externo, — porém isso apenas duplicaria os inconvenientes de confiar o backup exclusivamente ao primeiro. — Persistiria o receio de eliminar os atuais backups em HDD, para ampliar o espaço de trabalho em mídia com maior vida útil (número de gravações).

A melhor solução, — já que os atuais HDDs de 2 x 320 GiB ainda não apresentam defeitos, — parece ser um HDD interno adicional, de 1 Terabyte (e no futuro, um segundo), para iniciar a migração dos atuais, com tempo de folga.

  • Esta solução veio lembrar que a antiga fonte de 800 Watts ainda não foi recuperada, — verificar se lubrificação ressuscitará a ventoinha, ou se existe “refil” adequado. — O suprimento do computador está “meio precário”, para se adicionarem dispositivos sem pensar.

De qualquer modo, um novo disco rígido interno exige novo planejamento de partições, — o que pode (deve) ser feito desde logo, — e o SSD externo, também.

Fato é que não existe motivo para usar o Drive SSD como “partição única”, — e quaisquer erros de “planejamento”, que se venham a revelar no processo, poderão ser evitados desde o início, no futuro disco rígido interno.

Já se evidenciaram alguns “erros de planejamento” no particionamento dos atuais HDDs de 2 x 320 GiB, iniciado em 2009.

O “ideal” é começar pelo máximo de partições primárias (3), para “sistema”, — em seguida, uma partição estendida, começando com 1 ou 2 grandes partições lógicas, para documentos, — e lá no final, 3 partições lógicas para Swap.

  • Obs.: - Por “ideal”, entenda-se: — Para o tipo de brincadeira previsto por aqui. — Cada um deve planejar, tendo em vista as brincadeiras que faz ou pretende fazer.

Já se vê que a “brincadeira” de ter vários Linux “em paralelo” (dualboot) virou festa. — Embora o KDE Neon* e o Debian “testing” pareçam “experimentos”, não há qualquer intenção de eliminar um deles para testar algum outro.
_________
(*) O KDE Neon deixou de carregar “normalmente” no dia 26, após uma atualização (embora continue em uso, carregado por vias transversas. Corrigido em 2 Nov. 2016). O Debian “testing” segue em uso intenso, embora “incompleto” para alguns trabalhos. Funcionalidade total continua sendo atributo do Kubuntu 16.04 LTS e do Linux Mint 18 KDE, — talvez (em parte) por serem os sistemas em cujo aprendizado já foi investido mais tempo.

Na verdade, — depois de instalar um 5º sistema Linux, — não parece fazer sentido instalar um 6º, nem um 7º, nem seguir acrescentando outros, indefinidamente. Mas… nunca se sabe.

Até agora, foram destinados apenas 17 ou 20 GiB para cada partição de sistema, — e isso tem sido mais do que suficiente, para os usos pretendidos (bastante modestos), mesmo apesar de o KDE Neon e o Debian não terem partições “/home” separadas.

Só que as coisas evoluem. — No futuro, 20 GiB hão de ser pouco, para partições de sistema. — Com qualquer aumento da Memória RAM, partições de 4 GiB também poderão ser insuficientes para Swap.

Por isso, esse novo “planejamento”, — que será testado no SSD externo, — parece um bom começo, para mais tarde ser adotado no 1º disco rígido interno de 1 Terabyte.

Sobre o “SSD 1TB portable”


Drive externo SSD Samsung HX-MU010EA S2 Portable 1TB, de 2011

De acordo com os aplicativos do Linux, a capacidade real é de 931,5 GiB, — o que se aproxima da conta → 1.000^4 / 1.024³ = 931 GiB:

1.000^4 = 1.000.000.000.000
1 GiB = 1.024³ = 1.073.741.824
1.000.000.000.000 / 1.073.741.824 = 931,322.574.615

Cálculo usado para chegar a “1 Terabyte”

O motivo é que as ordens de grandeza KB, MB, GB, TB, usadas pela indústria de dispositivos de armazenamento de dados, são definidas em potências de 10, — 10³, 10^6, 10^9, 10^12, — enquanto KiB, MiB, GiB, TiB são definidas em potências de 2:

  • 1 KiB = 2^10
  • 1 MiB = 2^20
  • 1 GiB = 2^30 = 1.073.741.824 Bytes
  • 1 TiB = 2^40

Especificações da série “S2 Portable”, ainda no tempo da Samsung

Taxa de transferência → 480 Mbps Max.

Made in China, 2011-05-05

Dados do Drive SSD Samsung HX-MU010EA/G2 ou (B) S2 Portable 1TB, de 2011-05-05

Convenções adotadas:

  • HDD - Hard Disk Drive
  • SSD - Solid State Drive
  • Externo - “Portable”

Sequência da reorganização



— … ≠ • ≠ … —

Ferramentas &tc.