Existe um recurso oficial onde está disponível uma lista completa de todos os lançamentos do Ubuntu , mas incluindo a respectiva versão systemd
aplicada a cada um? Encontrei esta página do systemd/NEWS onde aparece cada systemd
versão mas quero saber para cada Ubuntu
lançamento qual foi a systemd
versão aplicada.
Manuel Jordan's questions
Para Ubuntu Desktop 22.04 foi instalado o navegador Brave de acordo com as instruções oficiais indicadas em Instalação do Canal de Lançamento - Debian, Ubuntu, Mint . Portanto da seguinte forma:
sudo apt install curl
sudo curl -fsSLo /usr/share/keyrings/brave-browser-archive-keyring.gpg https://brave-browser-apt-release.s3.brave.com/brave-browser-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/brave-browser-archive-keyring.gpg] https://brave-browser-apt-release.s3.brave.com/ stable main"|sudo tee /etc/apt/sources.list.d/brave-browser-release.list
sudo apt update
sudo apt install brave-browser
O processo foi bem sucedido mas nesse processo e para cada execução do apt update
comando aparece:
sudo apt update
...
Hit:3 https://brave-browser-apt-release.s3.brave.com stable InRelease
...
Fetched 3,590 B in 3s (1,411 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
3 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://brave-browser-apt-release.s3.brave.com stable InRelease' doesn't support architecture 'i386'
Observe a última linha (dividida em várias linhas para fins de apresentação):
N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository
'https://brave-browser-apt-release.s3.brave.com stable InRelease' doesn't support
architecture 'i386'
Eu sei que é uma nota por N:
parte, mas ficando curioso: Como remover a mensagem de não suporta arquitetura 'i386' ?
Apenas por curiosidade sobre a seguinte situação
Quando o adduser
comando é executado da seguinte forma:
sudo adduser optimusprime
Adding user `optimusprime' ...
Adding new group `optimusprime' (1015) ...
Adding new user `optimusprime' (1013) with group `optimusprime' ...
Creating home directory `/home/optimusprime' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for optimusprime
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n]
Observe que existem 5 campos opcionais disponíveis para gravar dados. Se eles forem deixados vazios como padrão quando o cat /etc/passwd
comando for executado, o registro desse usuário aparecerá da seguinte forma:
optimusprime:x:1013:1015:,,,:/home/optimusprime:/bin/bash
Observe a ,,,
parte GECOS. Representa 4 campos como A,B,C,D
e não 5 como A,B,C,D,E
. Por que essa diferença ou incompatibilidade entre eles? Para ser honesto, eu esperava
optimusprime:x:1013:1015:,,,,:/home/optimusprime:/bin/bash
O que representa também os 5 campos disponíveis através do adduser
comando.
E se for usado o usermod
comando da seguinte forma:
sudo usermod -c "A,B,C,D,E" optimusprime
O usuário aparece como:
optimusprime:x:1013:1015:A,B,C,D,E:/home/optimusprime:/bin/bash
Eu sei que é possível até adicionar mais campos através do usermod
comando da seguinte forma:
sudo usermod -c "A,B,C,D,E,F" optimusprime
sudo usermod -c "A,B,C,D,E,F,G" optimusprime
Portanto, as execuções desses comandos são refletidas da seguinte forma, respectivamente
optimusprime:x:1013:1015:A,B,C,D,E,F:/home/optimusprime:/bin/bash
optimusprime:x:1013:1015:A,B,C,D,E,F,G:/home/optimusprime:/bin/bash
À primeira vista não está claro se o GECOS se baseia no mínimo em 4 ou 5 campos.
Depois de fazer uma atualização através do VirtualBox para Ubuntu Desktop 20.04 para 22.04 - focal
para jammy
- no /etc/apt/sources.list.d
diretório existe o mysql.list
arquivo.
De acordo com uma pesquisa foi indicado abrir esse arquivo e mudar de local
para jammy
. Portanto eu tenho agora
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out entries below, but any other modifications may be lost.
# Use command 'dpkg-reconfigure mysql-apt-config' as root for modifications.
deb http://repo.mysql.com/apt/ubuntu/ jammy mysql-apt-config
deb http://repo.mysql.com/apt/ubuntu/ jammy mysql-8.0
deb http://repo.mysql.com/apt/ubuntu/ jammy mysql-tools
#deb http://repo.mysql.com/apt/ubuntu/ jammy mysql-tools-preview
deb-src http://repo.mysql.com/apt/ubuntu/ jammy mysql-8.0
manueljordan@mac2013-vb143:/etc/apt/sources.list.d$
Agora quando é executado o sudo apt update
comando acontece o seguinte:
sudo apt update
Get:1 http://repo.mysql.com/apt/ubuntu jammy InRelease [20.2 kB]
Hit:2 https://download.docker.com/linux/ubuntu focal InRelease
Hit:3 https://dl.google.com/linux/chrome/deb stable InRelease
Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:5 http://pe.archive.ubuntu.com/ubuntu jammy InRelease
Hit:6 http://pe.archive.ubuntu.com/ubuntu jammy-updates InRelease
Err:1 http://repo.mysql.com/apt/ubuntu jammy InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B7B3B788A8D3785C
Hit:7 http://pe.archive.ubuntu.com/ubuntu jammy-backports InRelease
Fetched 20.2 kB in 2s (11.7 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
16 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mysql.com/apt/ubuntu jammy InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B7B3B788A8D3785C
W: Failed to fetch http://repo.mysql.com/apt/ubuntu/dists/jammy/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B7B3B788A8D3785C
W: Some index files failed to download. They have been ignored, or old ones used instead.
Como você pode ver, há muitos erros
Como consertar o apt update após atualizar o arquivo mysql.list?
Através do VirtualBox foi instalado há muito tempo o Ubuntu Desktop 20.04 ( focal
) e foi atualizado com sucesso para 22.04jammy
Agora, o motivo deste post, quando o sudo apt update
comando é executado aparece:
sudo apt update
Hit:1 http://repo.mysql.com/apt/ubuntu focal InRelease
Hit:2 https://download.docker.com/linux/ubuntu focal InRelease
Hit:3 https://dl.google.com/linux/chrome/deb stable InRelease
Hit:4 http://security.ubuntu.com/ubuntu jammy-security InRelease
Hit:5 http://pe.archive.ubuntu.com/ubuntu jammy InRelease
Hit:6 http://pe.archive.ubuntu.com/ubuntu jammy-updates InRelease
Hit:7 http://pe.archive.ubuntu.com/ubuntu jammy-backports InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
11 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: http://repo.mysql.com/apt/ubuntu/dists/focal/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
Observe as duas primeiras linhas, elas contêm o focal
termo, e as demais linhas contêm o jammy
termo.
Como atualizar os locais dos repositórios de focal
para jammy
?
O objetivo é atualizar corretamente o MySQL e o Docker.
Para Ubuntu Desktop 22.04 , com o atalho ctrl++ é aberto o terminal padrão disponível.altt
Agora Terminator
foi instalado e com o mesmo atalho agora Terminator
é aberto. Fiz uma pesquisa sobre Preferences
cada um e não existe um atalho para definir como abrir cada um. Apenas seus respectivos atalhos internos.
Através:
- Configurações -> Teclado -> Atalhos de teclado -> Visualizar e personalizar atalhos -> Atalhos personalizados foram definidos ctrl+ alt+ ypara
Terminator
e funcionam.
Mas ctrl + alt+ tpermanece por Terminator
enquanto.
Através
- Configurações -> Teclado -> Atalhos de Teclado -> Visualizar e Personalizar Atalhos -> Iniciadores Posso ver a
Launch terminal
opção definida com ctrl+ alt+ tmas não é possível editar para indicar usoTerminal
Como consertar isto?
Para fins de documentação, sobre o apt-key
comando em muitos lugares, encontrei essas duas variações:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys PUBKEY
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv PUBKEY
Observe a diferença sobre a opção mais recente --recv-keys
e --recv
. Sobre o oficial do Ubuntu man
em jammy apt-key(8) menciona apenas sobre:
adv (deprecated)
Pass advanced options to gpg. With adv **--recv-key** you can e.g. download key from
keyservers directly into the trusted set of keys. Note that there are no checks
performed, so it is easy to completely undermine the apt-secure(8) infrastructure if
used without care.
E agora de cima veja outra opção --recv-key
(diferente como --recv-keys
- termina com s )
E em jammy gpg(1) menciona apenas sobre:
--recv-keys keyIDs
Import the keys with the given keyIDs from a keyserver.
A observação no mencionado man
aparece o --recv-key
termo como conteúdo para outras opções, mas não existe como uma definição de opção em si. (considere usar as teclas ctrl+ fpara pesquisar usando o --recv
como termo de busca, pois existe uma linha com o --recv-key
termo dividido em 2 linhas.)
Pergunta
- Qual é a diferença entre
--recv-key
,--recv-keys
e--recv
opções?
Se existe essas 3 opções, pois cada uma tem uma finalidade específica.
Sobre o dpkg
comando, alguns tutoriais mencionam a --unpack
opção. De acordo com
jammy (1) dpkg.1 indica
--unpack package-file...
Unpack the package, but don't configure it. If --recursive or -R option is specified,
package-file must refer to a directory instead.
Bem, apenas como teste, na página MySQL APT Repository é possível obter o mysql-apt-config_0.8.24-1_all.deb
arquivo. Então no Downloads
diretório eu executei o comando:
sudo dpkg --unpack mysql-apt-config_0.8.24-1_all.deb
Funciona com a seguinte mensagem
(Reading database ... 238377 files and directories currently installed.)
Preparing to unpack mysql-apt-config_0.8.24-1_all.deb ...
Unpacking mysql-apt-config (0.8.24-1) over (0.8.24-1) ...
Mesmo quando o MySQL está instalado.
Pergunta
- Onde está descompactado o conteúdo de um
.deb
arquivo?
Uma simples execução do ls
comando mostra apenas o .deb
arquivo atual. Eu esperava uma espécie de extração . Estou assumindo que um tipo de diretório padrão ou outra coisa foi usada.
Se com a -c
opção for possível ver os diretórios do .deb
arquivo, estou assumindo que a --unpack
opção descompacta o .deb
arquivo - se minha suposição estiver incorreta sobre o último, corrija-me.
Tendo VirtualBox com Ubuntu Server baseado em:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal
e
neofetch --off
------------------------
OS: Ubuntu 20.04.5 LTS x86_64
Host: VirtualBox 1.2
Kernel: 5.4.0-125-generic
Uptime: 17 mins
Packages: 1272 (dpkg), 5 (snap)
Shell: bash 5.0.17
Resolution: preferred
Terminal: /dev/pts/0
CPU: Intel i5-3230M (2) @ 2.594GHz
GPU: 00:02.0 VMware SVGA II Adapter
Memory: 236MiB / 3883MiB
Baseado nestes dois tutoriais valiosos:
Eu fiz os seguintes passos:
sudo apt-mark showhold # Returns nothing
sudo apt-mark unhold <packagename> # Not necessary as above returned nothing
sudo apt update
sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
mysql-client mysql-server
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
sudo reboot
sudo apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
mysql-client mysql-server
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
sudo apt --purge autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
sudo apt install update-manager-core # It to install 'do-release-upgrade'
sudo do-release-upgrade -c
Checking for a new Ubuntu release
New release '22.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
sudo do-release-upgrade # <---- final step
Checking for a new Ubuntu release
Please install all available updates for your release before upgrading.
Eu fiz o processo mostrado acima apenas no caso duas vezes e sempre aparece a mensagem:
Please install all available updates for your release before upgrading
Como resolver este cenário?
Observação Por precaução, estou fazendo esse processo ssh
na mesma LAN.
Observe em outra máquina virtual, agora o processo de atualização está funcionando, mas para o servidor Ubuntu 18 a 20 ... portanto, parece que as instruções das etapas compartilhadas estão corretas
Prestes a atualizar o SO de uma versão para outra, por exemplo - de 18.04 para 20.04 ou de 20.04 para 22.04 - em todo o processo existe e é usado o do-release-upgrade
comando, e ele tem algumas opções como -c
e -d
, agora no tutorial a seguir
Na etapa 4. Atualize o Ubuntu Linux para a seção LTS mais recente indica o seguinte:
Execute o seguinte comando:
sudo do-release-upgrade
Observe se você pode ser recebido com a seguinte mensagem:
Checking for a new Ubuntu release There is no development version of an LTS available. To upgrade to the latest non-LTS develoment release set Prompt=normal in /etc/update-manager/release-upgrades.
Nesse caso, passe a
-d
opção para obter a versão mais recente com força :
sudo do-release-upgrade -d
No /etc/update-manager/release-upgrades
arquivo atualmente tem o Prompt=lts
valor - de acordo com algumas pesquisas este valor/configuração é recomendável
Devo assumir que se sudo do-release-upgrade -d
for executado então
- O
Prompt=lts
valor atual é ignorado e usadoPrompt=normal
temporariamente ? - apenas para o tempo de vida de execução do processo - O
Prompt=lts
valor atual é ignorado e usadoPrompt=never
temporariamente ? - apenas para o tempo de vida de execução do processo - O
Prompt=lts
valor atual é substituído porPrompt=normal
? - portanto, agora está permanentemente alterado - O
Prompt=lts
valor atual é substituídoPrompt=never
- portanto, agora é alterado permanentemente
... e o processo continua
Atualmente a opção man do-release-upgrade
para a -d
opção indica
-d, --devel-release
If using the latest supported release, upgrade to the development release
Mas infelizmente não está claro.
Pergunta:
- Como funciona exatamente
do-release-upgrade -d
?
Perguntas extras
- Qual cenário é aplicado? 1,2,3,4?
- Quando/por que seria de uso obrigatório
do-release-upgrade -d
?
Desde que versão/lançamento do Ubuntu foi criado e disponibilizou o apt
comando? Ele com a finalidade de substituir apt-get
ou oferecer como uma nova alternativa contraapt-get
Quero que o post oficial Ubuntu.com
indique ou anuncie o comando "novo" apt
, e o(s) motivo(s), para fins de documentação histórica .
Sim, li alguns tutoriais sobre a diferença entre eles e os motivos, mas não da fonte ( Ubuntu.com
)
Sobre apt
no /var/log/apt
diretório aparecem principalmente os arquivos history.log
e term.log
e suas "variações" (versões antigas) como:
history.log.1.gz
...history.log.11.gz
term.log.1.gz
...term.log.11.gz
Pergunta
- Qual é a diferença/relação entre
/var/log/apt/history.log
e/var/log/apt/term.log
?
Eu vi o conteúdo de cada um e eles são semelhantes.
Prestes a realizar uma atualização para os pacotes atuais instalados - desde o Ubuntu 18:04 a 20:04 para ambientes Desktop e Server - sempre usei:
sudo apt update
sudo apt upgrade
Observe apenas no caso - eu nunca usei o apt-get
comando, de acordo com:
Até agora praticamente, não tive nenhum problema e tudo funcionou como esperado.
Sobre fazer um upgrade , vi praticamente em todos os tutoriais sendo usado o mesmo par citado acima, e claro que faz sentido, mas em poucos lugares vi o sudo apt full-upgrade
comando sendo usado.
Perguntas
- Quando usar
sudo apt full-upgrade
? - Quando é obrigatório?
Para o do-release-upgrade
comando é possível usar a -d
opção. De acordo com a documentação é:
-d, --devel-release
If using the latest supported release, upgrade to the development release
Li esses dois posts:
Mas não está claro, quando é de uso obrigatório -d
e quando não.
De acordo com o meu entendimento existem duas ramificações LTS
e desenvolvimento , onde a primeira é melhor porque tem um EOL maior que a segunda.
Se do-release-upgrade
for usado - sem nenhuma opção/parâmetro - deve passar de LTS para LTS (se existir um novo LTS para alcançar/aplicar a atualização, por exemplo from 16.04LTS to 18.04LTS
ou from 18.04LTS to 20.04LTS
). Anteriormente poderia ser confirmado/verificado do-release-upgrade -c
para saber se é possível fazer um upgrade ou não.
Portanto:
- Quando é obrigatório usar o
-d
parâmetro para odo-release-upgrade
comando? E quando não?
No link a seguir
para swap file
fins de redimensionamento, o dd
comando é usado da seguinte forma:
sudo dd if=/dev/zero of=/swapfile bs=1M count=1024 oflag=append conv=notrunc
Perguntas:
- Como funcionam os parâmetros
oflag
e ?conv
- Deve-se esperar uma continuidade bem definida dos novos blocos adicionados com zero ao tamanho atual do
swap file
?
Observe apenas no caso do Ubuntu ser 20.04
Sobre Linux Swap
, para fins de redimensionamento, encontrei três abordagens
- Exclua o atual
/swapfile
e crie um novo com o novo tamanho necessário - Adicione mais gigas conforme necessário para o atual
/swapfile
- Adicionar outro
Swap file
NOTA : certifique-se de desabilitar a primeira troca por meio de comandos sudo swapoff -v /swapfile
ousudo swapoff -a
As abordagens 2 e 3 são mencionadas/abordadas aqui:
A abordagem 1 é abordada aqui:
Pergunta
- Qual é a abordagem recomendável? e porque?
Perguntas extras
- Quando seria obrigatório e qual a vantagem de acrescentar outro
/swapfile
? - portanto/swapfile2
... etc - Como o kernel funciona com 2 ou mais
swap file
s? Acho que tem algumas vantagens... - Existe um limite recomendável para adicionar
swap files
? só até 3 por exemplo?
Normalmente eu costumava trabalhar com a swap partition
abordagem onde só existia uma partição, então, essa abordagem de adicionar algumas swap files
à primeira vista é rara/incomum
De acordo com o seguinte link:
Como o Ubuntu 17:04 é usado por padrão swap file
.
As principais dúvidas é:
- Qual é o tamanho padrão definido para os ambientes Desktop e Server?
Perguntas secundárias:
- Eles são iguais?
- Ser igual ou não - é fixo? ou é definido em tempo real de acordo com o hardware atual onde o Ubuntu está sendo instalado?
Sobre Ubuntu
a instalação:
- para qualquer um
Desktop
ouServer
ambientes - para um disco rígido baseado em um
HDD
ouSSD
Para um PC ou laptop mais recenteUEFI
, para fins de inicialização, é recomendável definir /boot/efi
com 1 GB de espaço.
Para um PC ou laptop antigoBIOS
onde usa - portanto não existe UEFI
- para fins de inicialização, qual deve ser o tipo de partição e o espaço recomendado?
Para alguns laptops instalei o Ubuntu Desktop
e Server
- 20.04 - até o VirtualBox
, normalmente ocupando todo o espaço em disco definido e disponível através do .vdi
arquivo. Até aqui está tudo ok.
Agora vou instalar o Ubuntu diretamente em alguns desktops de PC. Então agora é hora de usar partições, portanto, quero primeiro obter alguma prática e experiência. Infelizmente não posso usar como eu poderia fazer GParted
em VirtualBox
um disco rígido real - por favor me corrija se estiver errado - então devo usar as próprias ferramentas disponíveis através do Ubuntu Live .iso
arquivo - para ambientes Desktop e Server. Li muitos tutoriais sobre como criar/gerenciar as partições para ambientes Desktop e Server, como:
Onde eles usam as próprias ferramentas disponíveis do Ubuntu. Bem, eu quero tentar testar muitas abordagens, inclusive incluindo e não LVM
sugeridas em outro post:
Portanto
- É seguro criar partições dentro do .vdi para instalar o Ubuntu Desktop/Server através do VirtualBox?
- Com e sem LVM?
Eu não quero fazer uma bagunça (realmente causar um dano) no disco rígido do host
Observe que alguns laptops (o Host) têm o disco rígido baseado em HDD
e SSD
- talvez seja importante levar em consideração.
Através do VirtualBox, mesmo em máquinas diferentes, tenho 2 instâncias do Ubuntu Server 20.04 rodando com as seguintes informações:
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
Ambos têm o MySQL instalado com as mesmas instruções que usei meses atrás. De repente só para um deles quando eu faço sudo apt update
aparece o seguinte:
Get:2 http://repo.mysql.com/apt/ubuntu focal InRelease [12.9 kB]
Hit:3 http://pe.archive.ubuntu.com/ubuntu focal InRelease
Ign:4 https://packages.erlang-solutions.com/ubuntu focal InRelease
Hit:5 https://packages.erlang-solutions.com/ubuntu focal Release
Get:6 http://pe.archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
Err:2 http://repo.mysql.com/apt/ubuntu focal InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 467B942D3A79BD29
Get:9 http://pe.archive.ubuntu.com/ubuntu focal-backports InRelease [108 kB]
Get:10 http://pe.archive.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Hit:7 https://packagecloud.io/rabbitmq/rabbitmq-server/ubuntu focal InRelease
Fetched 349 kB in 3s (133 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mysql.com/apt/ubuntu focal InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 467B942D3A79BD29
W: Failed to fetch http://repo.mysql.com/apt/ubuntu/dists/focal/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 467B942D3A79BD29
W: Some index files failed to download. They have been ignored, or old ones used instead.
Perguntas
- Por que aconteceu isso?
- Como resolvê-lo?