Pacman demorando para resolver dependências

Problema:

  • Problema que venho enfrentando é que o pacman demora de 1 - 2 minutos ou mais para resolver as dependências, 2 a 3 meses atrás eu demorava nem 40 segundos, cada vez que eu instalo um programa(pacote) novo, ele tende a demorar mais ainda para achar as dependências, já atualizei meus mirrors para os do Brasil, única coisa que mudou foi a velocidade de Download.

Screenshot:

image

  • Demorou 3 minutos para resolver as dependências.

Info do sistema:

System:
  Kernel: 6.5.3-arch1-1 arch: x86_64 bits: 64 Desktop: bspwm
    v: 0.9.10 Distro: Arch Linux
Machine:
  Type: Desktop Mobo: ASUSTeK model: PRIME A320M-K/BR
    v: Rev X.0x serial: <superuser required>
    UEFI: American Megatrends v: 5007 date: 06/18/2019
CPU:
  Info: quad core model: AMD Ryzen 3 2200G with Radeon Vega
    Graphics bits: 64 type: MCP cache: L2: 2 MiB
  Speed (MHz): avg: 1721 min/max: 1600/3500 cores: 1: 1425
    2: 1594 3: 2353 4: 1512
Graphics:
  Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon
    Mobile Series] driver: amdgpu v: kernel
  Display: server: X.Org v: 21.1.8 with: Xwayland v: 23.2.0
    driver: X: loaded: amdgpu unloaded: modesetting,vesa
    dri: radeonsi gpu: amdgpu resolution: 1: 1366x768~60Hz
    2: 1024x768~60Hz
  API: OpenGL v: 4.6 Mesa 23.1.7-arch1.1 renderer: AMD
    Radeon Vega 8 Graphics (raven LLVM 16.0.6 DRM 3.54
    6.5.3-arch1-1)
Audio:
  Device-1: AMD Raven/Raven2/Fenghuang HDMI/DP Audio
    driver: snd_hda_intel
  Device-2: AMD Family 17h/19h HD Audio
    driver: snd_hda_intel
  API: ALSA v: k6.5.3-arch1-1 status: kernel-api
  Server-1: PulseAudio v: 16.1 status: active
Network:
  Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit
    Ethernet driver: r8169
  IF: enp5s0 state: up speed: 1000 Mbps duplex: full
    mac: <filter>
Drives:
  Local Storage: total: 577.56 GiB used: 83.61 GiB (14.5%)
  ID-1: /dev/sda vendor: SanDisk model: SSD PLUS 120GB
    size: 111.8 GiB
  ID-2: /dev/sdb vendor: Western Digital
    model: WD5000AAKX-001CA0 size: 465.76 GiB
Partition:
  ID-1: / size: 146.59 GiB used: 25.23 GiB (17.2%) fs: ext4
    dev: /dev/sdb2
  ID-2: /home size: 299.89 GiB used: 58.38 GiB (19.5%)
    fs: ext4 dev: /dev/sdb3
Swap:
  ID-1: swap-1 type: partition size: 8 GiB used: 0 KiB (0.0%)
    dev: /dev/sdb4
Sensors:
  System Temperatures: cpu: 35.5 C mobo: N/A gpu: amdgpu
    temp: 35.0 C
  Fan Speeds (rpm): N/A
Info:
  Processes: 231 Uptime: 11h 34m Memory: total: 8 GiB
  note: est. available: 6.7 GiB used: 4.62 GiB (69.0%)
  Shell: Zsh inxi: 3.3.29

Bom dia!

Tenta limpar o cache do pacman com o comando abaixo

sudo pacman -Scc

Depois, rode um update completo do sistema

sudo pacman -Syyu

E verifique se há redução no tempo pra resolver as dependências.

2 curtidas

So uma ideia, se for HD pode ser que o disco rígido esteja com os dados fragmentadaço, mas esse problema também aconteceria para todas as atividades do HD.
Existe ferramenta de analise de fragmentação.

Memórias flash não sofre com esse problema.

1 curtida

É bom garantir que você está usando os espelhos de repositório mais rápidos e atualizados. Você pode usar uma ferramenta como reflector para classificar os espelhos por velocidade e atualizá-los automaticamente:

sudo reflector --country ‘Brazil’ --age 12 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

impe o cache:

sudo pacman -Scc

Tente também habilitar o download paralelo:

No arquivo /etc/pacman.conf

ParallelDownloads = 5

3 curtidas

Bom dia Pessoal. Já Atualizei os mirrors e também limpei o cache, porém ainda continua a mesma coisa. Eu tenho HD e acho que pode ser oque o @aguamole disse, sobre fragmentação, mas não tenho nenhum conhecimento sobre fragmentação / desfragmentação. Se alguém der um help sobre isso eu agradeceria.

Dei uma pesquisada e descobri que tem uma ferramenta de análise para isso.

/dev/sdb2 - Meu /

Saída do e2fsck -fn

Aviso!  /dev/sdb2 está montado.
Aviso: a saltar recuperação do diário por estar em curso uma verificação só-de-leitura do sistema de ficheiros.
Passo 1: a verificar inodes, blocos e tamanhos
Passo 2: verificar estrutura de pastas
Passo 3: verificar conectividade da pasta
Passo 4: verificar totais de referência
Passo 5: verificar informação de resumo do grupo
Total de blocos livres errado (33363735, contados=33363661).
Reparar? não

Total de inodes livres errado (9365413, contados=9365407).
Reparar? não

/dev/sdb3: 464987/9830400 ficheiros (0.1% não-contíguos), 5957865/39321600 blocos

/dev/sdb2 - Minha Home

Aviso!  /dev/sdb3 está montado.
Aviso: a saltar recuperação do diário por estar em curso uma verificação só-de-leitura do sistema de ficheiros.
Passo 1: a verificar inodes, blocos e tamanhos
árvore de extensão de inode 19404253 (no nível 1) podia ser mais curta. Optimizar? não

Passo 2: verificar estrutura de pastas
Passo 3: verificar conectividade da pasta
Passo 4: verificar totais de referência
Passo 5: verificar informação de resumo do grupo
Total de blocos livres errado (63109600, contados=63108264).
Reparar? não

Total de inodes livres errado (19721371, contados=19721476).
Reparar? não

/dev/sdb3: 324453/20045824 ficheiros (1.1% não-contíguos), 17043744/80153344 blocos

Ambos /dev/sdb2 e /dev/sdb3 estão formatados como ext4.

Por algum motivo o fdisk -l não mostra o tipo de partição :confused:

image

A ferramenta de operação de desfragmentação do ext4 é o “e4defrag”
Leia o manual.

1 curtida

Acredito eu que nem precisava desfragmentar :confused:


Parabéns não faço a menor ideia.

3 curtidas

O ext4 é um sistema de arquivos super resistente a fragmentação.

Não manjo de Arch Linux, mas penso que seu arquivo de configuração do pacman possa ser antigo. Dê uma lida aqui: Pacman (Português)/Pacnew and Pacsave (Português) - ArchWiki

1 curtida