lyndhurst's questions

Eu corri paru -Syu, então sudo pacman -Syuvárias vezes com o mesmo resultado. Recebo este erro:

Total Installed Size:  3034.55 MiB
Net Upgrade Size:        49.01 MiB

:: Proceed with installation? [Y/n] 
(222/222) checking keys in keyring           [------------------------------] 100%
(222/222) checking package integrity         [------------------------------] 100%
:: File /var/cache/pacman/pkg/plasma5-themes-sweet-full-git-r390.48a9050-1-x86_64.pkg.tar.zst is corrupted (invalid or corrupted package (checksum)).
Do you want to delete it? [Y/n] 
error: failed to commit transaction (invalid or corrupted package)
Errors occurred, no packages were upgraded.

Quando me oferecem para excluir o arquivo, respondo "Sim", e então aparece a mensagem de falha.

Corri sudo pacman-key --refresh-keyscom sucesso, então, sudo pacman -Syyumas obtive o mesmo resultado.

Ao fazer o cd-ing no /var/cache/pacman/pkg/, encontrei alguns, plasma5-themes-sweet-full-git-r3*como esperado, mas o mais recente foi o r389, nenhum vestígio de r390, nenhum download parcial, nada.

Frustrado, corri sudo rmem todos esses arquivos, eles foram deletados, mas não consertou nada. Isso foi meio idiota, mas não acho que seja prejudicial.

Não sei bem como lidar com o fato de que ele está reclamando de um arquivo que não está lá, talvez algum cache para redefinir... Qualquer ajuda seria apreciada, obrigado pelo seu tempo.

Acabei de restaurar meus dados de um repositório de backup borg após uma falha no computador.

Minha ~/.gnupgpasta parece boa, as chaves privadas estão lá e as permissões parecem corretas. Normalmente Borg faz um bom trabalho nisso. Quando eu acesso catos arquivos de chaves privadas, não há sinal de corrupção de dados.

No entanto, não posso listar ou usar as chaves privadas. Só consigo interagir com uma chave pública que foi importada pacmandurante o processo de instalação.

Me deparei com alguns posts com problemas semelhantes de chaves privadas não reconhecidas após serem copiadas de uma máquina para outra, e geralmente o problema é resolvido seguindo recomendações de repetir a transferência usando gpg —export-keye depois importá-las com o comando oposto.

Infelizmente não tenho esse luxo, pois minha máquina antiga travou e não pode ser recuperada. Eu estava ciente da importação e exportação de chaves, mas sempre presumi que era apenas um procedimento seguro mover chaves.

Então eu tenho duas perguntas:

Preciso revisar meus scripts de backup e usar o comando de exportação para minhas chaves secretas gpg?

Mesmo assim, posso recuperar minhas chaves secretas?

======= Editar ======

Encontrei uma postagem no fórum do arch com um usuário tendo exatamente o mesmo problema que eu, então consegui mais pistas para seguir.

O que eu tentei até agora:

gpg --version
> gpg (GnuPG) 2.4.5

ps aux | grep gpg-a
>  /usr/bin/gpg-agent --supervised

#About ownership: 
chown -R $USER:$USER .gnupg

# Checking UID/GID with show a result of `1000` both on filesystem # # and backup archive.
ls -vn .gnupg/private-keys-v1.d 

gpg --export-secret-keys
> gpg: WARNING: nothing exported

gpg -v --list-secret-keys
> gpg: enabled compatibility flags:
> gpg: using pgp trust model

# Most relevant results of:
strace -f -o /tmp/gpg.strace gpg --list-secret-keys
cat /tmp/gpg.strace
> 76220 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> 76220 access("/home/$USER/.gnupg/secring.gpg", F_OK) = -1 ENOENT (No such file or directory)

# Listing public keys
gpg --list-keys
> Returns one public key imported by pacman during install

gpg -K
> Returns nothing

ls -ln .gnupg/
.rw-r-----   12 1000 13 Mar 10:45 common.conf
drwx------    - 1000  6 Sep  2023 crls.d
.rw------- 2.0k 1000 13 Sep  2023 gpg-agent.conf
.rw-------  703 1000  5 Mar 18:48 gpg.conf
drwx------    - 1000 30 Aug  2023 private-keys-v1.d
drwxr-x---    - 1000 14 Mar 19:27 public-keys.d
.rw-r--r--    0 1000 24 Aug  2023 pubring.gpg
.rw-r--r-- 7.7k 1000  5 Mar 12:13 pubring.kbx
.rw-r--r-- 7.0k 1000  7 Sep  2023 pubring.kbx~
.rw-------  600 1000  8 Mar 07:20 random_seed
.rw-r-----  676 1000 30 Aug  2023 sshcontrol
.rw------- 1.6k 1000  2 Sep  2023 trustdb.gpg

Eu tenho uma unidade externa com uma partição ext4 /dev/sda1que uso para meus backups locais do borg.

Ele é simplesmente conectado via porta USB e montado com uma fstabentrada de montagem automática do systemd gerada. Fiz um backup ontem à noite sem erros, e esta manhã liguei e não foi mais reconhecido. A unidade apareceria com lsblk, mas nenhuma partição abaixo dela.

Corri sudo fsck -R -C -V -t ext4 /dev/sda1e obtive a seguinte saída:

fsck from util-linux 2.39.2
[/usr/bin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -C0 /dev/sda1 
e2fsck 1.47.0 (5-Feb-2023)
fsck.ext4: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda1
Could this be a zero-length partition?
/dev/sda1: status 8, rss 3232, real 0.002321, user 0.001784, sys 0.000000

Não tenho ideia de como interpretar isso. Só consigo ver o status do código de saída 8 que a página de manual descreve como um 'erro operacional'.

COMEÇAR A EDITAR

Saída parasudo parted /dev/sda print

Error: Invalid partition table on /dev/sda -- wrong signature 0.
Ignore/Cancel? I                                                          
Model: SABRENT  (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      8225kB  1000GB  1000GB  extended               lba

Saída sudo dmesglogo após conectar a unidade

[16265.871467] usb 2-6.4: new SuperSpeed USB device number 15 using xhci_hcd
[16265.889474] usb 2-6.4: New USB device found, idVendor=152d, idProduct=1561, bcdDevice= 2.04
[16265.889486] usb 2-6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[16265.889491] usb 2-6.4: Product: SABRENT
[16265.889495] usb 2-6.4: Manufacturer: SABRENT
[16265.889499] usb 2-6.4: SerialNumber: DB9876543214E
[16265.899660] scsi host4: uas
[16265.900160] scsi 4:0:0:0: Direct-Access     SABRENT                   0204 PQ: 0 ANSI: 6
[16268.706521] sd 4:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[16268.706530] sd 4:0:0:0: [sda] 4096-byte physical blocks
[16268.706759] sd 4:0:0:0: [sda] Write Protect is off
[16268.706768] sd 4:0:0:0: [sda] Mode Sense: 53 00 00 08
[16268.707113] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[16268.707265] sd 4:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
[16268.707270] sd 4:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of preferred minimum block size (4096 bytes)
[16268.724287]  sda: sda1 < >
[16268.724396] sd 4:0:0:0: [sda] Attached SCSI disk
[16296.811964] usb 2-6.3: reset SuperSpeed USB device number 14 using xhci_hcd
[16340.865861]  sda: sda1 < >

Seguindo o conselho da Telecom, corri sudo losetup --sector-size 4096 -P -f /dev/sdx. Eu tenho um dispositivo/partição loop1p1 agora.

❯ sudo parted /dev/loop1p1 print
Error: /dev/loop1p1: unrecognised disk label
Model: Unknown (unknown)                                                  
Disk /dev/loop1p1: 4096B
Sector size (logical/physical): 4096B/4096B
Partition Table: unknown
Disk Flags: 

❯ sudo fsck.ext4 -f /dev/loop1p1
e2fsck 1.47.0 (5-Feb-2023)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
fsck.ext4: Bad magic number in super-block while trying to open /dev/loop1p1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

FIM DA EDIÇÃO

Devo desistir de tentar recuperar esta partição? (Tenho backups redundantes, não é uma catástrofe para mim, só quero aprender antecipando o dia em que poderá ser uma).

Agradeço antecipadamente por sua ajuda.