Bom dia gente
Eu saí do arch por conta do secure boot, nunca tive problema, mas por precisar ativar e desativar o SB todas vês eu acabei saindo, atualmente estou no fedora KDE, alguns bugs aqui ou alí, mas parece que deu uma estabilizada, porém também estou testando em VM o openSUSE TW e vejo muitos tópicos sobre isso, mas nada realmente preciso, então a melhor forma de atualizar o openSUSE seria pelo YaST, por mais que já vi que por ele no TW não é recomendado, Discover ou linha de comando, eu preferiria uma interface gráfica mas também não tô afim de quebrar o sistema msm em VM, então, o que vcs dizem?
Qual é a melhor forma?
2 curtidas
Pode usar o Yast para fazer as atualizações no TW se não quiser usar o terminal, nunca ouvi falar de problemas do Yast com TW, pelo menos quando usei anos atrás nunca tive problemas.
2 curtidas
Salve @Jhonatan96, tudo bem contigo?
Isso pode acontecer porque o openSUSE apesar de bastante conhecido, não é das distros mais adotadas aqui no Brasil. Mas, tanto aqui no fórum quanto no blog nós temos vários conteúdos interessantes sobre a família openSUSE.
Muitas vezes eu reclamo do Yast por conta da aparência ou da quantidade de opções, mas se você pretende usar o openSUSE ele é a forma mais indicada de você gerenciar sua distribuição. Dedique um tempo para aprender como as ferramentas dele funcionam e tenho certeza que não vai se arrepender.
Assim como a maioria dos sistemas baseados em Linux, raramente existe um “jeito certo” de fazer alguma coisa, o mais comum é que os sistemas permitam várias abordagens e o usuário se adapte com aquelas que tem maior facilidade.
Estou usando o Tumbleweed há alguns dias e tenho usado o Discover para instalar atualizações sem nenhum problema. Quando houver uma atualização que seja recomendada fazer pelo Yast, o Discover vai te mostrar uma mensagem informando isso.
Então pode usar a ferramenta que você gosta mais sem maiores preocupações.
4 curtidas
Entendi, mas e com relação a aquele negócio do zypper do UP e dup, eu tinha visto que cada um é pra uma versão, o YaST e o Discover se adequam a eles?
Não sei qual é essa documentação que você leu, mas o zypper é o gerenciador oficial e que funciona embaixo de todas essas interfaces gráficas. Os comandos “zypper up” e “zypper dup” tem efeitos práticos bem similares, só que no caso do “dup” podem acontecer mudanças mais profundas porque se trata de uma atualização de “produto” - que é a forma do projeto openSUSE marcar os lançamentos do Tumbleweed.
Recomendo dar uma lida nas opções do zypper usando um “–help” no console, isso deve ajudar a tirar suas dúvidas.
3 curtidas
Então o Discover e o YaST roda com qual dos 2
Dup ou UP ou ele escolhe de forma automática?
No caso para atualizar
É que eu tinha visto em alguns fóruns do reddit provavelmente da gringa que cada um usava um e o dup é melhor para o TW ou os dois só usavam o up
O Yast vai usar o comando adequado conforme a situação, acredito que o Discover deve seguir a mesma abordagem. Porém, em ambos os casos você pode optar por usar o terminal e controlar manualmente da forma que preferir.
1 curtida
Blz então
Obrigado
Ao usar o “zypper dup” ele cria um snapshot caso esteja usando BTRFS, talvez seja por isso que a galera recomenda para o Tumbleweed. No caso do Yast ou Discover, se eles criam snapshot provavelmente estão usando zypper dup por baixo dos panos.
2 curtidas
Sim, existe uma diferença:
No Leap – apenas “upgrade”, no dia-a-dia – mantendo a mesma “versão do Leap”:
zypper up
No Tumbleweed – ou quando vai migrar o Leap de uma versão para outra: – “dist-upgrade”:
zypper dup --allow-vendor-change
Em resumo: – O Tumbleweed, toda atualização = “migrar de versão”.
3 curtidas
Teria como verificar qual método ele usa?
E verificar qual método o YaST usa?
Entendi
Você sabe qual dos 2 o YaST e o Discover usa?
E só o zypper dup não é o suficiente?
Qual a diferença?
1 curtida
No caso eu desinstalei o discover e só utilizo no terminal o sudo zyyper dup e reinicio quando ele tem uma linha seguinte como “zypper ps…” significa que terei que reiniciar para nova configurarção (escrita interna do sistema) como por exemplo a atualização do Kernel ou relacionada com o KDE Plasma.
2 curtidas
Vamos por partes:
Eu aposto mais no YaST2 para “fazer a coisa certa”, pois todo o sistema openSUSE é um “relógio suíço” – ou uma BMW, ou uma Mercedes-Benz (rs) – onde todas as peças se ajustam com exatidão.
Nesse mecanismo, “zypper” é o “módulo do YaST2” que faz a atualização / instalação / remoção de pacotes – acionando o mecanismo de “instantâneos” (snapshots) do “Snapper” – e juntos acionam os mecanismos do sistema de arquivos BtrFS para distribuir os pontos de gravação.
-
Vale lembrar que o mecanismo de “baixo nível” é o rpm – utilizado pelo Zypper – da mesma forma como o apt usa o dpkg.
-
Da mesma forma, no Fedora o dnf usa o rpm; – no PCLinuxOS o Synaptic usa o apt (apt-rpm), que usa o rpm; – no Mageia o urpmi usa o rpm – cada um, acrescentando recursos que o rpm não tem. – Porém, em todas essas distros, você pode usar um comando
rpm -qa --lastpara listar todos os pacotes instalados – do último… até o primeiro (ordem cronológica inversa), com a data e hora em que cada um foi instalado. -
E, sim! – Evite utilizar zypper e dnf “alternadamente”, dentro da mesma distro / mesma instalação! – No Mageia, por exemplo, existe uma advertência para não utilizar urpmi e dnf – porque o uso de ambos irá embaralhar o rastreamento de arquivos órfãos. – Ao usar “auto-remove”, vai dar caca.
O Plasma Discover é outra coisa! – É um “front-end” GUI (específico do KDE Plasma!), que usa o PackageKit – que por sua vez utiliza os mecanismos próprios de cada distro (apt, zypper, dnf, urpmi…) – para tentar padronizar as distros mais diferentes, umas das outras.
Então, o Plasma Discover é o modo mais “indireto” que existe. – É uma coisa que usa outra… que usa outra… que usa outra… – para criar uma “camada” GUI “fácil”, para tentar “igualar” todas as distros.
- Quanto maior a “facilidade” (aparente), maior o “acúmulo de camadas”, e a complexidade – e maior a probabilidade de alguma coisa dar errado – e maior a dificuldade para descobrir o quê deu errado.
Além disso, o Plasma Discover também tenta lidar com Snapd, Flatpak, e sei lá o que mais – imagino que, também, usando o PackageKit – que a essa altura já utiliza também comandos típicos do Snapd, do Flatpak etc.
Tudo indica que o Plasma Discover funciona… Bem… Pelo menos, quando tudo dá certo, né.
- Em todas as distros, minha primeira providência é remover o PackageKit – e com isso, o Plasma Discover também é removido. – Só mantenho o PackageKit no KDE Neon, porque seus dev’s insistem em que devemos utilizar o comando pkcon (mas neste caso, uso só o comando).
Por essas e outras, é que eu prefiro usar – sempre! só! – o comando zypper.
Até o YaST2 eu evito utilizar, para atualização do openSUSE Tumbleweed.
De Janeiro a Outubro 2017, eu utilizei o “atualizador” que o openSUSE oferecia no Painel – um ícone com “Aviso de Atualizações” – até que um dia congelou a bagaça, e tive de consertar manualmente. – Desde então, utilizo só o comando zypper, e nunca mais sofri nenhum desastre.
6 curtidas
Entendi
Então o comando seria o ideal
Porém ambos(Discover e YaST) utilizam na teoria o zypper dup
Porém o mais recomendo entre os 2 é o YaST
Eu entendi certo?
1 curtida
Isso… mas é só minha opinião:
O comando zypper oferece uma visão muito clara, de tudo que acontece – e é fácil de copiar para um arquivo TXT, para examinar mais tarde, em caso de necessidade:
# date; zypper dup --allow-vendor-change; date
Sun 27 Oct 03:39:03 -03 2024
Retrieving repository 'Main Repository (NON-OSS)' metadata ............................................................................[done]
Building repository 'Main Repository (NON-OSS)' cache .................................................................................[done]
Retrieving repository 'Main Repository (OSS)' metadata ................................................................................[done]
Building repository 'Main Repository (OSS)' cache .....................................................................................[done]
Retrieving repository 'google-chrome' metadata ........................................................................................[done]
Building repository 'google-chrome' cache .............................................................................................[done]
Retrieving repository 'packman-essentials' metadata ...................................................................................[done]
Building repository 'packman-essentials' cache ........................................................................................[done]
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
The following 37 items are locked and will not be changed by any action:
Available:
akonadi-calendar-tools akonadi-calendar-tools-lang akonadi-import-wizard akonadi-import-wizard-lang akonadi-mime akonadi-plugin-calendar
akonadi-plugin-contacts akonadi-plugin-mime akonadi-search akonadi-search-lang pattern:games pattern:kde_pim kdepim-addons
kdepim-addons-lang kdepim-runtime kdepim-runtime-lang kmail-account-wizard kmail-account-wizard-lang kmailtransport kmailtransport-lang
ktnef libkdepim-lang libksieve libksieve-lang libpackagekit-glib2-18 mbox-importer mbox-importer-lang messagelib messagelib-lang PackageKit
PackageKit-backend-zypp PackageKit-branding-openSUSE PackageKit-branding-upstream PackageKit-devel PackageKit-gstreamer-plugin
PackageKit-gtk3-module PackageKit-lang
The following 427 packages are going to be upgraded:
acpica babelstone-han-fonts bind-utils bluedevil6 branding-openSUSE breeze6 breeze6-cursors breeze6-decoration breeze6-style
(.........)
xdg-desktop-portal-kde6 xf86-input-evdev xf86-input-libinput xfsprogs xorg-x11-Xvnc xorg-x11-Xvnc-module xz yast2-auth-client
yast2-installation yast2-qt-branding-openSUSE yt-dlp zenity
The following 8 patterns are going to be upgraded:
apparmor base documentation enhanced_base minimal_base sw_management x11 x11_enhanced
The following product is going to be upgraded:
openSUSE Tumbleweed 20241018-0 -> 20241025-0
The following 6 NEW packages are going to be installed:
kernel-default-6.11.5-1.1 libgnustep-base1_30 libkbdfile1 libkeymap1 libkfont0 samba-dcerpc
The following package is going to be REMOVED:
libgnustep-base1_29
The following package requires a system reboot:
kernel-default-6.11.5-1.1
427 packages to upgrade, 6 new, 1 to remove.
Package download size: 1.46 GiB
Package install size change:
| 3.45 GiB required by packages that will be installed
252.8 MiB | - 3.21 GiB released by packages that will be removed
Note: System reboot required.
Backend: classic_rpmtrans
Continue? [y/n/v/...? shows all options] (y):
...
Since the last system boot core libraries or services have been updated.
Reboot is suggested to ensure that your system benefits from these updates.
Sun 27 Oct 03:53:42 -03 2024
Por ele, vejo
- a responsividade dos repositórios;
- os pacotes que bloqueei para não serem reinstalados;
- os pacotes que serão atualizados;
- os “conjuntos de pacotes” (patterns) que serão atualizados;
- o upgrade do próprio Tumbleweed como um todo, de “18 Outubro” para “25 Outubro”
- Os pacotes novos que serão instalados
- Os pacotes que serão removidos
- Os pacotes que vão exigir Reboot
- O total de pacotes atualizados, instalados, removidos
- O tamanho do download
- A variação do tamanho da instalação – espaço liberado / usado
Esse meu TXT já está com 70.205 linhas, com os registros desde 11 Janeiro 2020 
Tenho uma “vaga impressão” de que o YaST2 também mostra muitas dessas informações (talvez todas?), mas não encontrei uma captura de tela para confirmar isso. – Por isso, não quero afirmar. – Mas nos primeiros meses de 2017, quando fiz as atualizações / instalações pelo YaST2 + Aviso de Atualizações do Painel, não tive essa facilidade de registrar tudo em detalhes. – Em suma: Não tinha como verificar o que tinha acontecido entre Janeiro e Outubro!
Sim, o YaST2 é a “espinha dorsal” do openSUSE – testado e re-testado o tempo todo. – Se ele não for confiável, o Plasma Discover será menos confiável ainda.
Outra coisa que me faz preferir os comandos, é o controle dos “instantâneos”:
# date; snapper ls
Sun 27 Oct 03:57:43 -03 2024
# │ Type │ Pre # │ Date │ User │ Cleanup │ Description │ Userdata
──────┼────────┼───────┼──────────────────────────────┼──────┼──────────┼────────────────────────┼──────────────
0 │ single │ │ │ root │ │ current │
4006* │ single │ │ Sun 17 Mar 2024 13:42:08 -03 │ root │ │ writable copy of #3998 │
4154 │ pre │ │ Sun 13 Oct 2024 13:29:01 -03 │ root │ number │ zypp(zypper) │ important=yes
4155 │ post │ 4154 │ Sun 13 Oct 2024 13:29:50 -03 │ root │ number │ │ important=yes
4156 │ pre │ │ Sun 13 Oct 2024 13:38:59 -03 │ root │ number │ zypp(zypper) │ important=yes
4157 │ post │ 4156 │ Sun 13 Oct 2024 13:55:48 -03 │ root │ number │ │ important=yes
4158 │ single │ │ Sun 13 Oct 2024 14:00:21 -03 │ root │ timeline │ timeline │
4159 │ single │ │ Sun 13 Oct 2024 17:06:20 -03 │ root │ timeline │ timeline │
4160 │ pre │ │ Sun 13 Oct 2024 18:29:23 -03 │ root │ number │ zypp(zypper) │ important=yes
4161 │ post │ 4160 │ Sun 13 Oct 2024 18:30:05 -03 │ root │ number │ │ important=yes
4162 │ pre │ │ Sun 20 Oct 2024 23:52:58 -03 │ root │ number │ zypp(zypper) │ important=yes
4163 │ single │ │ Mon 21 Oct 2024 00:00:19 -03 │ root │ timeline │ timeline │
4164 │ post │ 4162 │ Mon 21 Oct 2024 00:08:57 -03 │ root │ number │ │ important=yes
4165 │ pre │ │ Sun 27 Oct 2024 03:35:15 -03 │ root │ number │ zypp(zypper) │ important=yes
4166 │ post │ 4165 │ Sun 27 Oct 2024 03:36:06 -03 │ root │ number │ │ important=yes
4167 │ pre │ │ Sun 27 Oct 2024 03:39:58 -03 │ root │ number │ zypp(zypper) │ important=yes
4168 │ post │ 4167 │ Sun 27 Oct 2024 03:53:40 -03 │ root │ number │ │ important=yes
# snapper delete --sync 4154 4155 4156 4157 4158 4159 4160 4161
# date; snapper ls
Sun 27 Oct 04:00:30 -03 2024
# │ Type │ Pre # │ Date │ User │ Cleanup │ Description │ Userdata
──────┼────────┼───────┼──────────────────────────────┼──────┼──────────┼────────────────────────┼──────────────
0 │ single │ │ │ root │ │ current │
4006* │ single │ │ Sun 17 Mar 2024 13:42:08 -03 │ root │ │ writable copy of #3998 │
4162 │ pre │ │ Sun 20 Oct 2024 23:52:58 -03 │ root │ number │ zypp(zypper) │ important=yes
4163 │ single │ │ Mon 21 Oct 2024 00:00:19 -03 │ root │ timeline │ timeline │
4164 │ post │ 4162 │ Mon 21 Oct 2024 00:08:57 -03 │ root │ number │ │ important=yes
4165 │ pre │ │ Sun 27 Oct 2024 03:35:15 -03 │ root │ number │ zypp(zypper) │ important=yes
4166 │ post │ 4165 │ Sun 27 Oct 2024 03:36:06 -03 │ root │ number │ │ important=yes
4167 │ pre │ │ Sun 27 Oct 2024 03:39:58 -03 │ root │ number │ zypp(zypper) │ important=yes
4168 │ post │ 4167 │ Sun 27 Oct 2024 03:53:40 -03 │ root │ number │ │ important=yes
4169 │ single │ │ Sun 27 Oct 2024 04:00:14 -03 │ root │ timeline │ timeline │
(O espaço ocupado em disco caiu de 33,2 para 29,8 GiB)
Eu já limitei radicalmente a quantidade de Snapshots a serem mantidos – e o excesso é eliminado automaticamente. – Mesmo assim, gosto de eliminar mais alguns, manualmente, pois uso uma partição-raiz de apenas 50 GiB.
O simples ato de abrir / fechar o YaST2 (mesmo sem fazer nada com ele), já causa a criação de +2 Snapshots – e cada seção que você mexe dentro do YaST2, também gera mais um par de Snapshots. – São pequenos, mas essa proliferação do número de Snapshots acaba me dando mais trabalho, na hora de administrá-los.
Por isso, raramente abro o YaST2.
3 curtidas
@frc_kde caraca isso sim que é um registro detalhado
Entendi, eu acho mais confiável a linha de comando, tanto é que no arch eu usava o terminal para instalar/atualizar e remover tudo, mas com a mudança de distro, nesse momento com o fedora, eles até encorajam a usar o Discover, eu acho interessante usar a GUI, nesse caso vou fazer alguns testes, se algo acontecer também tá de boa, só recriar a máquina virtual.
Obrigado a todos que ajudaram
Vlw
1 curtida
Fedora, mesma coisa:
Só que o TXT do Fedora já está em 92.350 linhas:
# date; dnf upgrade --refresh; date
Sun 27 Oct 03:13:23 -03 2024
Fedora 40 - x86_64 2.4 kB/s | 2.8 kB 00:01
Fedora 40 openh264 (From Cisco) - x86_64 1.8 kB/s | 989 B 00:00
Fedora 40 - x86_64 - Updates 74 kB/s | 57 kB 00:00
Fedora 40 - x86_64 - Updates 1.3 MB/s | 4.8 MB 00:03
google-chrome 6.5 kB/s | 1.3 kB 00:00
google-chrome 5.4 kB/s | 1.9 kB 00:00
google-earth-pro 2.7 kB/s | 1.3 kB 00:00
RPM Fusion for Fedora 40 - Free 14 kB/s | 12 kB 00:00
RPM Fusion for Fedora 40 - Free - Updates 12 kB/s | 11 kB 00:00
RPM Fusion for Fedora 40 - Free - Updates 31 kB/s | 78 kB 00:02
RPM Fusion for Fedora 40 - Nonfree 19 kB/s | 17 kB 00:00
RPM Fusion for Fedora 40 - Nonfree - Updates 17 kB/s | 15 kB 00:00
RPM Fusion for Fedora 40 - Nonfree - Updates 10 kB/s | 27 kB 00:02
Dependencies resolved.
=================================================================================================================================
Package Architecture Version Repository Size
=================================================================================================================================
Installing:
kernel x86_64 6.11.4-201.fc40 updates 183 k
kernel-core x86_64 6.11.4-201.fc40 updates 18 M
kernel-modules x86_64 6.11.4-201.fc40 updates 64 M
(.........)
kernel-modules x86_64 6.10.10-200.fc40 @updates 62 M
kernel-modules-core x86_64 6.10.10-200.fc40 @updates 36 M
kernel-modules-extra x86_64 6.10.10-200.fc40 @updates 2.7 M
Transaction Summary
=================================================================================================================================
Install 6 Packages
Upgrade 157 Packages
Remove 5 Packages
Total download size: 811 M
Is this ok [y/N]: y
Downloading Packages:
(1/163): json-c-0.17-3.fc40.i686.rpm 80 kB/s | 47 kB 00:00
(2/163): kernel-6.11.4-201.fc40.x86_64.rpm 246 kB/s | 183 kB 00:00
(3/163): kernel-core-6.11.4-201.fc40.x86_64.rpm 6.9 MB/s | 18 MB 00:02
(..........)
(161/163): zvbi-0.2.42-1.fc40.x86_64.rpm 2.5 MB/s | 428 kB 00:00
(162/163): google-chrome-stable-130.0.6723.69-1.x86_64.rpm 36 MB/s | 108 MB 00:02
(163/163): plasma-workspace-wallpapers-6.2.2-1.fc40.noarch.rpm 5.7 MB/s | 106 MB 00:18
---------------------------------------------------------------------------------------------------------------------------------
Total 16 MB/s | 811 MB 00:50
...
Installed:
json-c-0.17-3.fc40.i686 kernel-6.11.4-201.fc40.x86_64 kernel-core-6.11.4-201.fc40.x86_64
kernel-modules-6.11.4-201.fc40.x86_64 kernel-modules-core-6.11.4-201.fc40.x86_64 kernel-modules-extra-6.11.4-201.fc40.x86_64
Removed:
kernel-6.10.10-200.fc40.x86_64 kernel-core-6.10.10-200.fc40.x86_64
kernel-modules-6.10.10-200.fc40.x86_64 kernel-modules-core-6.10.10-200.fc40.x86_64
kernel-modules-extra-6.10.10-200.fc40.x86_64
Complete!
Sun 27 Oct 03:18:10 -03 2024
1 curtida
Caramba
Mas no caso do fedora, como eles mesmos falam que pode usar tranquilamente o Discover então tá mais d boa
Mas esse registro é bem interessante
1 curtida
O YaST e o zypper utilizam a libzypp por debaixo dos panos, enquanto que o Discover utiliza o PackageKit, que por sua vez se comunica com a libzypp. O PackageKit funciona perfeitamente no openSUSE, com a exceção deste problema aqui:
Sim. No caso do Tumbleweed, o YaST e o Discover sempre usam o dup.
1 curtida