Seamus's questions

Estou trabalhando em um projeto que visa usar um pequeno teclado (de 6 teclas) para controlar música tocada por mpd(e mpc) em um Raspberry Pi. Obviamente, preciso "capturar" as entradas do teclado e traduzi-las em comandos para mpd. Não tenho (zero) experiência trabalhando com teclados, mas depois de alguma pesquisa e usando estas perguntas e respostas como ponto de partida , agora tenho um pequeno script funcional que evtestmonitora a saída do teclado.

Há uma declaração no site do Debian sobre o evtestpacote sobre o qual quero perguntar:

O evtest agora está em modo de manutenção e não suporta todos os recursos dos kernels mais recentes; o evemu-record do pacote evemu-tools deve ser usado em seu lugar.

Também testei o evemu-recordcomando no meu script; parece funcionar muito parecido com o evtest.

Tenho duas perguntas: a primeira é se os problemas mencionados evtestsão ou não uma preocupação real, dado o seguinte:

• o sistema alvo é um Raspberry Pi sem cabeça ('bookworm', 64 bits)
• o teclado tem apenas 6 teclas e é conectado via USB

Eu também tenho uma pergunta sobre esta afirmação em man evtest:

Se o sinalizador --grab for fornecido no modo de captura, o evtest mantém um EVIOCGRAB no dispositivo. Enquanto esse grab estiver ativo, outros processos não receberão eventos dos dispositivos do kernel.

Isso significa que, se meu script for iniciado @reboot( cron), a saída do teclado de 6 teclas nunca será direcionada a nenhum outro processo? Se for assim, isso me parece "uma coisa boa" e uma potencial vantagem sobre evemu-record.

A segunda pergunta é uma "pergunta de opinião", eu acho, mas eu gostaria de saber se há "vantagens convincentes" reais em escrever esse monitor de teclado em Cvez de em bashcomo eu fiz?

Eu administro a distribuição "bookworm stable". Recentemente, comecei a experimentar um pacote chamado mpd. Por razões que não entendo, o responsável pelo mpdrepositório do GitHub não disponibiliza documentação para versões mais antigas (por exemplo, a versão 0.23.12 incluída na "bookworm stable"). Os manuais do sistema são extremamente breves.

Tenho tido alguns problemas com o mpd, e não ter acesso à documentação detalhada não está ajudando. Decidi que, dadas as circunstâncias, devo tentar um pacote mais recente. A versão que acho que funcionará é a 0.24.2-1 - atualmente no repositório "testing" . O mpdpacote mais recente no Debian, o 0.24.3-1, agora está na pasta "unstable"... Pode ser uma escolha melhor e corresponderia totalmente à documentação disponível .

Quando instalei um pacote de 'backports' , segui um procedimento semelhante a este (atualizado para refletir o uso de 'testing` em vez de 'backports':

• Modifique /etc/apt/sources.listpara adicionar 'teste'
• Instalar:sudo apt install -t testing mpd mpc ...
• Remover testes de /etc/apt/sources.list(uma medida de "segurança" :)

Isso parece aproximadamente correto? Fiz algumas pesquisas, mas não consegui encontrar um exemplo específico de instalação de um único pacote de "testing" para "stable" — todos eles refletiam uma atualização geral (todos os pacotes) para "testing" — não é o que eu quero!

Se isso não funcionar, agradeceria sugestões sobre a melhor forma de proceder com a instalação de uma versão atualizada do mpd.

Eu costumo mpg123tocar uma lista de músicas enquanto trabalho. O host que realmente executa mpg123e toca a música é um sistema local, sem interface , mas posso me conectar a ele por SSH. Eu começo mpg123neste host em cron; ele toca as faixas de áudio da minha "playlist" em um loop contínuo. No entanto, há momentos em que preciso pausar a música (chamadas telefônicas recebidas, visitantes, etc.).

man mpg123diz que pressionando a stecla uma vez eu posso pausar a reprodução, e pressioná-la novamente para recomeçar. Se eu iniciar mpg123em um terminal, e deixá-lo rodando, isso funciona bem. Eu também aprendi que é possível enviar um sinal de "pausa" ( s) para mpg123quando ele estiver sendo reproduzido em uma screensessão:

$ screen -S mpg123                                   # to start the screen session 
$ /usr/bin/mpg123 --loop -1 /home/pi/rainstorm.mp3   # for example
'ctrl+a, d'                                          # quit screen 

... 

$ screen -S mpg123 -X stuff "s"   # pauses play

Encontrei uma pergunta parecida com a minha aqui no SO , mas a resposta parece não atingir o objetivo - pelo menos eu não entendi!

Não consegui encontrar um método que me permita enviar um scomando "pause" ( ) para mpg123se ele foi iniciado em cron. Eu preferiria uma rota mais diretascreen do que enviar esse comando para mpg123, além disso, não tenho certeza se isso poderia ser configurado usando cron.

Alguém pode me aconselhar sobre uma abordagem? Eu preferiria uma " bashsolução" a uma que exija (por exemplo) um programa em C - mas ficaria feliz em aceitar o que eu puder conseguir!

Meu sistema tem uma única interface: wifi via wlan0. O NetworkManager é o padrão. No entanto, o sistema tem vários "serviços de rede" habilitados. A seguir está uma lista (o padrão) dos serviços habilitados relacionados à "rede":

$ systemctl list-unit-files --state=enabled

ModemManager.service               enabled enabled
networking.service                 enabled enabled
NetworkManager-dispatcher.service  enabled enabled
NetworkManager-wait-online.service enabled enabled
NetworkManager.service             enabled enabled

wpa_supplicant.service             enabled enabled  # underlined??

Eu queria tentar networking.service, então adicionei as entradas necessárias /etc/network/interfacespara fazer funcionar e desabilitei NetworkManager.service. Após uma reinicialização, "networking" estava operacional (o que significa que eu podia fazer todas as coisas que precisava fazer: conectar-me ao host via SSH, fazer aptatualizações, etc.).

Em seguida, eu queria tentar reativar NetworkManager.servicee desativar networking.service. Comentei todas as adições que fiz em /etc/network/interfaces, então desativei networking.servicee reiniciei. Após a reinicialização, não consegui me reconectar ao host via SSH.

Então conectei o host a um console, reativei networking.servicee reiniciei. A rede foi restaurada (o que significa que eu poderia conectar ao host via SSH, do apt, etc.

Pesquisei, mas não consegui encontrar uma resposta para esta pergunta, pois ela se refere ao meu sistema Debian 'bookworm':

Se eu desabilitar networking.service, mas deixar NetworkManager.servicehabilitado, por que isso "quebra" a rede?

EDITAR...

Desculpas a todos - Eu estraguei tudo! Durante os comentários @grawityabaixo, percebi que meu problema foi causado por uma NetworkManagerconfiguração que tinha sido criada meses antes e esquecida, pois eu estava usando networking.servicedesde então.

Então, todas as respostas aqui estão corretas, deixando minha pergunta como a única postagem incorreta aqui.

Mais uma vez, desculpas a todos.

Reescrevi este parágrafo de abertura... tentando esconder meu desdém por systemd. Vou me contentar em dizer que acho systemda "lógica" de desconcertante, e deixar por isso mesmo. Para chegar à pergunta:

Tenho tentado reduzir o tempo de inicialização relatado por systemd-analyze timeem um pequeno Raspberry Pi Zero 2W . O SO é cerca de 95% Debian com um pouco de Raspberry Pi para lidar com o hardware.

Comecei listando os arquivos de unidade ativos e, a partir dessa lista, cheguei a alguns serviceque eu tinha certeza de que poderiam ser removidos sem impacto:

$ systemctl list-unit-files --state=enabled
...
rpi-display-backlight.service      enabled enabled
rpi-eeprom-update.service          enabled enabled
...
$

Eu escolhi disableambos os serviços da seguinte forma:

$ sudo systemctl disable rpi-eeprom-update.service rpi-display-backlight.service
Removed "/etc/systemd/system/halt.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/poweroff.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/reboot.target.wants/rpi-display-backlight.service".
Removed "/etc/systemd/system/multi-user.target.wants/rpi-eeprom-update.service".

Decepcionantemente, descobri que o tempo de inicialização (conforme relatado por systemd-analyze time) na verdade aumentou em cerca de 3 segundos. Reiniciei algumas vezes para obter uma "média"; o aumento de 3 segundos parecia real e persistente. Fiquei pensando se esse aumento poderia ser devido a systemd uma nova tentativa de iniciar esses serviços. E então procurei dependências com outras systemd"unidades":

$ systemctl list-dependencies rpi-eeprom-update.service
rpi-eeprom-update.service

$ systemctl list-dependencies rpi-display-backlight.service
rpi-display-backlight.service
● └─system.slice
$

Tomei o primeiro resultado (rpi-eeprom) como uma indicação de que não havia outras dependências. O segundo resultado (rpi-display) é desconcertante para mim. Fiz um pouco de pesquisa .slicedesde então, mas ainda faz pouco (na verdade, nenhum) sentido para mim. O que me leva à minha pergunta:

Alguém pode explicar como editar isso system.slicee remover o rpi-display-backlight.service?

Aparentemente, "quebrei" o acesso de rede a um dos meus sistemas 'bookworm' Debian que rodam em hardware Raspberry Pi. Isso resultou da minha aparente falta de entendimento dos detalhes sobre como as várias "ferramentas de rede" operam. O sistema quebrado é uma unidade "sem cabeça"; não consigo mais fazer uma conexão SSH com ele. Ele nem responde a um ping.

Estou levantando essa questão aqui na tênue esperança de que alguém possa explicar se há uma maneira de recuperar o acesso SSH sem fazer nenhuma alteração no sistema. Meu recurso atual é remover o SSD NVME e montá-lo em outro sistema para corrigir o erro de configuração ou conectar um monitor e teclado, mas isso é difícil devido à falta de hardware/cabos, etc.

O que eu fiz: Fiquei "farto" da nmcliinterface arcana do NM e pensei: "deve haver uma maneira melhor". Li esta página no site do Debian ; especificamente:

O NetworkManager manipulará apenas interfaces não declaradas em /etc/network/interfaces

Interpretei isso como se eu declarasse minha interface WiFi ( wlan0) em /etc/network/interfaces, então NetworkManager"se afastaria" e systemdusaria ifup, ifdown, etc para gerenciar wlan0IAW o conteúdo que adicionei a /etc/network/interfaces. Aqui está o conteúdo do interfacesarquivo que criei:

iface wlan0 inet static
    address 192.168.1.222
    netmask 255.255.255.0
    gateway 192.168.1.1
    dns-nameservers 192.168.1.1

Depois rebootdescobri que não conseguia mais acessar este sistema via SSH.

Tenho duas perguntas:

1. Existe alguma maneira de recuperar o acesso SSH sem fazer alterações no sistema?
2. Por que os dados que inseri /etc/network/interfacesnão geraram uma conexão Wi-Fi funcional?

Esta pergunta é uma continuação desta resposta . Em geral, meu objetivo é saber se meu sistema (Debian/Raspberry Pi 5 'bookworm') está atualizando meu relógio RTC/hardware a partir do horário do sistema. Observe que o RPi 5 (diferentemente de seus ancestrais Pi) tem um relógio RTC/hardware embutido .

Aqui está o que consegui determinar até agora:

1. Sinto que estabeleci que o relógio do sistema está sendo atualizado a partir do hwclock:

$ dmesg | grep "system clock" 

[    1.588793] rpi-rtc soc:rpi_rtc: setting system clock to 2025-02-18T04:59:13 UTC (1739854753)

Depois de alguma busca dmesg, no entanto, não consegui encontrar nenhuma indicação de que o hwclock esteja sendo atualizado a partir do horário do sistema. No entanto, encontrei uma referência a um fake-hardwarerelógio (o que parece estranho ). :

[    4.037230] systemd[1]: Starting fake-hwclock.service - Restore / save the current clock...

2. O kernel está aparentemente configurado para fazer atualizações de relógio em "ambas as direções":

$ cat /boot/config-$(uname -r) | grep -i HCTOSYS
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"  

$ cat /boot/config-$(uname -r) | grep -i SYSTOHC
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"

Ocorreu-me que o kernel pode estar executando a sincronização SYSTOHC somente durante o desligamento, e talvez não esteja sendo capturado por dmesg... mas isso é um WAG.

Alguém pode explicar como confirmar se o kernel está (ou não) atualizando o hwclock/RTC?

A 'here string' ( <<<) é uma construção útil e pode ser usada em vez de echoem muitas situações. No entanto, ao calcular um hash (como um exemplo), a adição de um caractere de nova linha altera o valor do hash.

Procurei um método compacto para evitar que a quebra de linha fosse adicionada pela 'here string', mas não consegui encontrar nada. Esta pergunta foi feita e respondida no SO , mas estranhamente a resposta aceita (ou qualquer uma das respostas) não responde realmente à pergunta AFAICT.

Alguns podem considerar responder a essa pergunta com uma sugestão de simplesmente usar echo -n <string> | md5sumor printf ... | md5sumem vez disso. Mas minha pergunta diz respeito especificamente à 'string here'.

Tenho um bashscript que preciso poder iniciar a partir de:

1. cron
2. um shell interativo (logon)

Este script precisa saber se foi iniciado a partir de cron, ou iniciado a partir de um shell interativo. Pensei que tinha resolvido esse problema quando declarei uma variável de ambiente em root crontab:

RUN_BY_CRON="TRUE"

No script, eu testo RUN_BY_CRONe uso o resultado para definir outra variável:

if [ "$RUN_BY_CRON" = "TRUE" ]; then            
    ((wait_time=DELAY_HALT*60))
fi

Isso funcionou até eu adicionar set -uao meu script (como uma "estratégia de programação defensiva comum" ). Desde então, quando executo o script a partir da linha de comando, set -usinaliza RUN_BY_CRONcomo um erro de "variável não vinculada":

$ sudo ./skedrtc.sh
./skedrtc.sh: line 24: RUN_BY_CRON: unbound variable

A propósito, executei shellcheckesse script e não recebi nenhum aviso ou erro.

Tentei adicionar um teste para RUN_BY_CRON, mas obtive o mesmo erro. Tentei testar para um shell interativo, mas testar de dentro do script em si não é útil:

...
if [ -z "$RUN_BY_CRON" ]; then        # test for null string
    RUN_BY_CRON="FALSE"
fi
...

if [[ $- == *i* ]]; then              # test for interactive shell
    RUN_BY_CRON="FALSE"
fi

Isso parece uma situação de "catch 22" . Procurei maneiras de criar um bloco try-catch , mas AIUI não tem nada parecido em bash.

P: Como posso evitar esse erro de "variável não vinculada" sem remover o set -u?

Aqui está o que estou tentando fazer (em um script):

#!/usr/bin/env bash

if [[ ! $("/usr/bin/scp [email protected]:/Users/seamus/Downloads/imgutils/image-utils* /home/pi/testscp") ]]; then
    printf "\nERROR & EXIT: 'scp' failed \n"
    exit 1
fi
printf "success!\n"

Eu tentei fazer isso de algumas maneiras, mas nada parece funcionar. Aqui está o que eu obtenho do acima:

./testscp.sh: line 3: /usr/bin/scp [email protected]:/Users/seamus/Downloads/imgutils/image-utils* /home/pi/testscp: No such file or directory

ERROR & EXIT: 'scp' failed

O scpcomando roda OK quando está em uma linha por si só. Se eu fizer isso, posso testar $0- o que funciona OK... mas eu preferiria fazer tudo em uma única linha. O que estou perdendo?

Estou acostumado alsaa mexer no volume de um alto-falante Bluetooth que conectei. É uma configuração de 1 alto-falante; apenas algo para fornecer algum contexto.

Posso 'obter' a configuração de volume via CLI da seguinte maneira:

$ amixer sget Master
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 22938 [35%] [on]
  Front Right: Playback 22938 [35%] [on]

Posso 'definir' o volume pela CLI da seguinte maneira:

$ amixer sset Master 50%
Simple mixer control 'Master',0
  Capabilities: pvolume pswitch pswitch-joined
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 65536
  Mono:
  Front Left: Playback 32768 [50%] [on]
  Front Right: Playback 32768 [50%] [on]

Não preciso de toda essa verbosidade , então decidi criar uma função e dois aliases no meu ~/.bashrcarquivo para reduzir isso. A função não está funcionando como eu esperava:

Da CLI, isso funciona bem:

$ amixer sget Master | awk -F"[][]" '/Right:/ { print $2 }'
35%

Mas quando coloco isso na minha declaração de função em ~/.bashrc, funciona de forma diferente :

# functions & aliases for alsa mixer/volume control
function vol-get() {
   amixer sget Master | awk -F"[][]" '/Left:/ { print $2 }'
}
export -f vol-get

alias vol-up='amixer sset Master 5%+ > /dev/null && vol-get'
alias vol-dn='amixer sset Master 5%- > /dev/null && vol-get'

Reler ~/.bashrce executar a vol-getfunção produz o seguinte:

$ . ~/.bashrc
$ vol-get
  Front Left: Playback 22938 [35%] [on]
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ?? what happened here ??
$ vol-up
  Front Left: Playback 26215 [40%] [on]
$ 

Então - estou perto , mas não entendo por que meu | awk ...se comporta de forma diferente dentro da função do que na linha de comando. Alguém pode explicar e corrigir isso?

Edições para respostas a algumas das perguntas levantadas nos comentários:

EDIÇÃO #1:

$ command -V vol-get
vol-get is a function
vol-get ()
{
    amixer sget Master | awk -F"[][]" '/Left:/ { print $2 }'
} 

$ awk --version
awk: not an option: --version
$ man awk
# reveals that I am actually calling `mawk`, Version 1.3.4

EDIÇÃO #2:

RE: caracteres não imprimíveis; observe que este é um c&p parcial da saída (ou seja, literalmente):

$ cat -vet ~/.bashrc
...
function vol-get() {$
    amixer sget Master | awk -F'[][]' '/Left:/ { print $2 }'$
}$
...

O Raspberry Pi geralmente monta duas partições no momento da inicialização; aqui está /etc/fstab:

proc            /proc           proc    defaults          0       0
PARTUUID=8a6020b5-01  /boot/firmware  vfat    defaults          0       2
PARTUUID=8a6020b5-02  /               ext4    defaults,noatime  0       1

Tenho um problema porque, em várias ocasiões, a /boot/firmwarepartição (vfat) ( aparentemente aleatoriamente ) foi "desmontada"; observei isso na saída de lsblk --fs:

# 'boot/firmware' mounted correctly: 

$ lsblk --fs
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS 
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs 146B-AD94                             444.8M    13% /boot/firmware
└─nvme0n1p2 ext4   1.0   rootfs ece25014-1cd7-4874-9bfc-f91e486bc000  364.9G     2% /

# 'boot/firmware' becomes "un-mounted": 

$ lsblk --fs 
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS 
nvme0n1
├─nvme0n1p1 vfat   FAT32 bootfs 146B-AD94                             444.8M    13% 
└─nvme0n1p2 ext4   1.0   rootfs ece25014-1cd7-4874-9bfc-f91e486bc000  364.9G     2% /  

Depois de considerar algumas opções para ajudar a "solucionar" esse problema, pensei que usar a --pollopção com findmntseria uma boa escolha; ou seja:

$ nohup /usr/bin/findmnt -n --poll=umount,mount --target /boot/firmware & 

Executei este comando e testei usando umounte mountpara acionar findmnt --poll:

$ nohup /usr/bin/findmnt --poll=umount,mount --target /boot/firmware &
[1] 10904

# wait a while, then

$ sudo umount /boot/firmware 
$ sudo mount -a

# check nohup.out: 

$ cat nohup.out
umount     /boot/firmware /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro
mount      /boot/firmware /dev/nvme0n1p1 vfat   rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 

O que preciso fazer é disparar uma rotina quando a umount ...saída for produzida. Até agora não consegui fazer isso, e é aí que preciso de ajuda. Preciso de um script que inicie o findmnt --pollcomando e então espere por uma saída começando com umount. Quando essa saída chegar, gostaria de executar dmesg(?), capturar essa saída para um arquivo de log, talvez algum outro(s) diagnóstico(s) e, finalmente, emitir um sudo mount -a.

Depois de findmnt --pollgerar outra linha com mount, acho que o script deve retornar ao estado de "espera" para capturar o próximo umountevento.

Li um pouco sobre o waitcomando , mas me pergunto se é a abordagem correta porque:

O comando wait faz com que um script de shell ou uma sessão de terminal aguarde a conclusão dos processos em segundo plano.

Neste caso, findmnt --poll não termina - continua a rodar, sondando por outra mudança de estado reportável. Alguma sugestão sobre como abordar isso?

Tenho uma situação que aconteceu ontem mesmo depois de um apt full-upgrade. Parece que os aplicativos afetados são aplicativos que eu tinha instalado anteriormente de debian-backports. Aqui está o resumo com todo o histórico que consegui reunir:

1. Modificar /etc/apt/sources.listpara adicionar bookworm-backports; o/a 15 de agosto de 2024:

Cerca de 2,5 meses atrás, concluí que precisava das backportsversões de pipewiree wireplumber. Para fazer isso acontecer, modifiquei meu /etc/apt/sources.listarquivo para adicionar backports:

$ cat /etc/apt/sources.list
deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
# Uncomment deb-src lines below then 'apt-get update' to enable 'apt-get source'
#deb-src http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
#deb-src http://deb.debian.org/debian-security/ bookworm-security main contrib non-free non-free-firmware
#deb-src http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-backports main contrib non-free

Nenhuma alteração foi feita em /etc/apt/sources.list.d/raspi.list:

$ cat /etc/apt/sources.list.d/raspi.list
deb http://archive.raspberrypi.com/debian/ bookworm main
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.com/debian/ bookworm main

2. Instalar pipewireet. al. de bookworm-backports; o/a 15 ago 2024:

$ sudo apt install -t bookworm-backports pipewire pipewire-audio-client-libraries libspa-0.2-bluetooth 
...
$ sudo reboot

Depois disso, as versões pipewire& (de ) instaladas no meu sistema foram:wireplumberbackports

$ pipewire --version
pipewire
Compiled with libpipewire 1.2.1
Linked with libpipewire 1.2.1 

$ wireplumber --version
wireplumber
Compiled with libwireplumber 0.4.17
Linked with libwireplumber 0.4.17

3. Avanço rápido para 9 de outubro de 2024 após a conclusão dos testes

Este sistema não foi atualizado em dois meses, pois eu estava executando um teste nos aplicativos com os quais estou tendo problemas agora. Aqui está o que eu vi ontem:

Observe bookworm-backportsna lista abaixo:

$ sudo apt update
Hit:1 http://deb.debian.org/debian bookworm InRelease
Get:2 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
Get:3 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
Get:4 http://deb.debian.org/debian bookworm-backports InRelease [59.0 kB]
Get:5 http://archive.raspberrypi.com/debian bookworm InRelease [39.0 kB]
Get:6 http://deb.debian.org/debian-security bookworm-security/main armhf Packages [181 kB]
Get:7 http://deb.debian.org/debian-security bookworm-security/main arm64 Packages [185 kB]
Get:8 http://deb.debian.org/debian-security bookworm-security/main Translation-en [114 kB]
Get:9 http://deb.debian.org/debian bookworm-backports/main arm64 Packages [249 kB]
Get:10 http://deb.debian.org/debian bookworm-backports/main armhf Packages [250 kB]
Get:11 http://deb.debian.org/debian bookworm-backports/main Translation-en [210 kB]
Get:12 http://deb.debian.org/debian bookworm-backports/contrib arm64 Packages [4,964 B]
Get:13 http://deb.debian.org/debian bookworm-backports/contrib armhf Packages [4,740 B]
Get:14 http://deb.debian.org/debian bookworm-backports/non-free arm64 Packages [6,864 B]
Get:15 http://deb.debian.org/debian bookworm-backports/non-free armhf Packages [1,516 B]
Get:16 http://archive.raspberrypi.com/debian bookworm/main armhf Packages [515 kB]
Get:17 http://archive.raspberrypi.com/debian bookworm/main arm64 Packages [485 kB]
Fetched 2,409 kB in 4s (614 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
59 packages can be upgraded. Run 'apt list --upgradable' to see them.

Marquei (*) as 12 entradas que vêm de backports:

apt list --upgradable
Listing... Done
base-files/stable 12.4+deb12u7 arm64 [upgradable from: 12.4+deb12u6]
curl/stable 7.88.1-10+deb12u7 arm64 [upgradable from: 7.88.1-10+deb12u6]
git-man/stable-security,stable-security 1:2.39.5-0+deb12u1 all [upgradable from: 1:2.39.2-1.1]
git/stable-security 1:2.39.5-0+deb12u1 arm64 [upgradable from: 1:2.39.2-1.1]
initramfs-tools-core/stable,stable 0.142+deb12u1 all [upgradable from: 0.142]
initramfs-tools/stable,stable 0.142+deb12u1 all [upgradable from: 0.142]
libc-bin/stable 2.36-9+rpt2+deb12u8 arm64 [upgradable from: 2.36-9+rpt2+deb12u7]
libc-dev-bin/stable 2.36-9+rpt2+deb12u8 arm64 [upgradable from: 2.36-9+rpt2+deb12u7]
libc-devtools/stable 2.36-9+rpt2+deb12u8 arm64 [upgradable from: 2.36-9+rpt2+deb12u7]
libc-l10n/stable,stable 2.36-9+rpt2+deb12u8 all [upgradable from: 2.36-9+rpt2+deb12u7]
libc6-dbg/stable 2.36-9+rpt2+deb12u8 arm64 [upgradable from: 2.36-9+rpt2+deb12u7]
libc6-dev/stable 2.36-9+rpt2+deb12u8 arm64 [upgradable from: 2.36-9+rpt2+deb12u7]
libc6/stable 2.36-9+rpt2+deb12u8 arm64 [upgradable from: 2.36-9+rpt2+deb12u7]
libcamera-ipa/stable 0.3.2+rpt20240927-1 arm64 [upgradable from: 0.3.0+rpt20240617-1]
libcamera0.3/stable 0.3.2+rpt20240927-1 arm64 [upgradable from: 0.3.0+rpt20240617-1]
libcurl3-gnutls/stable 7.88.1-10+deb12u7 arm64 [upgradable from: 7.88.1-10+deb12u6]
libcurl4/stable 7.88.1-10+deb12u7 arm64 [upgradable from: 7.88.1-10+deb12u6]
libexpat1/stable-security 2.5.0-1+deb12u1 arm64 [upgradable from: 2.5.0-1]
libpam-systemd/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
* libpipewire-0.3-0/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
* libpipewire-0.3-common/stable-backports,stable-backports 1.2.4-1~bpo12+1 all [upgradable from: 1.2.1-1~bpo12+1]
* libpipewire-0.3-modules/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
libpisp-common/stable,stable 1.0.7-1 all [upgradable from: 1.0.6-1]
libpisp1/stable 1.0.7-1 arm64 [upgradable from: 1.0.6-1]
* libspa-0.2-bluetooth/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
* libspa-0.2-modules/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
libssl3/stable 3.0.14-1~deb12u2+rpt1 arm64 [upgradable from: 3.0.13-1~deb12u1+rpt1]
libsystemd-shared/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
libsystemd0/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
libudev1/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
linux-headers-rpi-2712/stable 1:6.6.51-1+rpt3 arm64 [upgradable from: 1:6.6.31-1+rpt1]
linux-headers-rpi-v8/stable 1:6.6.51-1+rpt3 arm64 [upgradable from: 1:6.6.31-1+rpt1]
linux-image-rpi-2712/stable 1:6.6.51-1+rpt3 arm64 [upgradable from: 1:6.6.31-1+rpt1]
linux-image-rpi-v8/stable 1:6.6.51-1+rpt3 arm64 [upgradable from: 1:6.6.31-1+rpt1]
linux-libc-dev/stable,stable 1:6.6.51-1+rpt3 all [upgradable from: 1:6.6.31-1+rpt1]
locales/stable,stable 2.36-9+rpt2+deb12u8 all [upgradable from: 2.36-9+rpt2+deb12u7]
openssl/stable 3.0.14-1~deb12u2+rpt1 arm64 [upgradable from: 3.0.13-1~deb12u1+rpt1]
* pipewire-alsa/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
* pipewire-audio-client-libraries/stable-backports,stable-backports 1.2.4-1~bpo12+1 all [upgradable from: 1.2.1-1~bpo12+1]
* pipewire-bin/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
* pipewire-jack/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
* pipewire-pulse/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
* pipewire/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
python3-gpiozero/stable,stable 2.0.1-0+rpt1 all [upgradable from: 2.0-1]
raspberrypi-sys-mods/stable 20240911 arm64 [upgradable from: 20240807]
raspi-firmware/stable,stable 1:1.20240924-1 all [upgradable from: 1:1.20240529-1]
raspi-utils-core/stable 20240903-1 arm64 [upgradable from: 20240402-4]
raspi-utils-dt/stable 20240903-1 arm64 [upgradable from: 20240402-4]
raspi-utils-eeprom/stable 20240903-1 arm64 [upgradable from: 20240402-4]
raspi-utils-otp/stable,stable 20240903-1 all [upgradable from: 20240402-4]
raspi-utils/stable,stable 20240903-1 all [upgradable from: 20240402-4]
raspinfo/stable,stable 20240903-1 all [upgradable from: 20240402-4]
rpi-eeprom/stable,stable 26.0-1 all [upgradable from: 24.0-1]
rpicam-apps-lite/stable 1.5.2-2 arm64 [upgradable from: 1.5.0-2]
systemd-sysv/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
systemd-timesyncd/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
systemd/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
udev/stable 252.30-1~deb12u2 arm64 [upgradable from: 252.26-1~deb12u2]
* wireplumber/stable-backports 0.5.6-1~bpo12+1 arm64 [upgradable from: 0.4.17-1~bpo12+1]

E então eu fiz uma upgradeem toda a lista; isso pareceu completar normalmente , mas alguns itens escaparam da minha atenção (não estava olhando para a tela durante o upgrade) até que "as rodas saíram":

$ sudo apt -y full-upgrade
...

The following package was automatically installed and is no longer required:
  libwireplumber-0.4-0
Use 'sudo apt autoremove' to remove it.
The following NEW packages will be installed:
  libwireplumber-0.5-0 linux-headers-6.6.51+rpt-common-rpi linux-headers-6.6.51+rpt-rpi-2712 linux-headers-6.6.51+rpt-rpi-v8
  linux-image-6.6.51+rpt-rpi-2712 linux-image-6.6.51+rpt-rpi-v8 linux-kbuild-6.6.51+rpt
The following packages will be upgraded:
  base-files curl git git-man initramfs-tools initramfs-tools-core libc-bin libc-dev-bin libc-devtools libc-l10n libc6 libc6-dbg libc6-dev
  libcamera-ipa libcamera0.3 libcurl3-gnutls libcurl4 libexpat1 libpam-systemd libpipewire-0.3-0 libpipewire-0.3-common libpipewire-0.3-modules
  libpisp-common libpisp1 libspa-0.2-bluetooth libspa-0.2-modules libssl3 libsystemd-shared libsystemd0 libudev1 linux-headers-rpi-2712
  linux-headers-rpi-v8 linux-image-rpi-2712 linux-image-rpi-v8 linux-libc-dev locales openssl pipewire pipewire-alsa
  pipewire-audio-client-libraries pipewire-bin pipewire-jack pipewire-pulse python3-gpiozero raspberrypi-sys-mods raspi-firmware raspi-utils
  raspi-utils-core raspi-utils-dt raspi-utils-eeprom raspi-utils-otp raspinfo rpi-eeprom rpicam-apps-lite systemd systemd-sysv systemd-timesyncd
  udev wireplumber
59 upgraded, 7 newly installed, 0 to remove and 0 not upgraded.

...

apt-listchanges: Reading changelogs...
apt-listchanges: News
---------------------

wireplumber (0.5.1-1) experimental; urgency=medium

  WirePlumber 0.5 was released with a new configuration system.
  The new system is based on JSON instead of Lua which makes WirePlumber >= 0.5
  incompatible with Lua conf files written for WirePlumber 0.4.
  .
  If only the default configuration (e.g the configuration shipped with the
  Debian package) is used, then there is nothing to do.
  .
  If you use custom configuration files, you will have to manually update them
  by following the migration guide. No automatic migration of old configuration
  files is performed.
  .
  This guide is available at (after having installed "wireplumber-doc"):
    /usr/share/doc/wireplumber/html/daemon/configuration/migration.html
  or
    https://pipewire.pages.freedesktop.org/wireplumber/daemon/configuration/migration.html

 -- Dylan Aïssi <[email protected]>  Sun, 31 Mar 2024 14:44:46 +0200

...

$ sudo reboot
... 

4. Depois que upgradedescobri que "as rodas saíram"; pipewirenão funciona mais; sem som do Bluetooth!

Só para confirmar o que eu já sabia, verifiquei o status do Bluetooth comsystemctl

$ systemctl status bluetooth
● bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
     Active: active (running) since Wed 2024-10-09 22:29:30 UTC; 1h 6min ago
       Docs: man:bluetoothd(8)
   Main PID: 507 (bluetoothd)
     Status: "Running"
      Tasks: 1 (limit: 404)
        CPU: 196ms
     CGroup: /system.slice/bluetooth.service
             └─507 /usr/libexec/bluetooth/bluetoothd

Oct 09 22:29:30 rpi2w bluetoothd[507]: Starting SDP server
Oct 09 22:29:30 rpi2w bluetoothd[507]: profiles/audio/vcp.c:vcp_init() D-Bus experimental not enabled
Oct 09 22:29:30 rpi2w bluetoothd[507]: src/plugin.c:plugin_init() Failed to init vcp plugin
Oct 09 22:29:30 rpi2w bluetoothd[507]: profiles/audio/mcp.c:mcp_init() D-Bus experimental not enabled
Oct 09 22:29:30 rpi2w bluetoothd[507]: src/plugin.c:plugin_init() Failed to init mcp plugin
Oct 09 22:29:30 rpi2w bluetoothd[507]: profiles/audio/bap.c:bap_init() D-Bus experimental not enabled
Oct 09 22:29:30 rpi2w bluetoothd[507]: src/plugin.c:plugin_init() Failed to init bap plugin
Oct 09 22:29:30 rpi2w bluetoothd[507]: Bluetooth management interface 1.22 initialized
Oct 09 22:29:31 rpi2w bluetoothd[507]: profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Oct 09 22:29:31 rpi2w bluetoothd[507]: sap-server: Operation not permitted (1)

$

bluetoothctlconsegui conectar com meu alto-falante, mas nada - nenhum som.

5. Restaurar o sistema a partir do arquivo de imagem raw criado em 16 de agosto de 2024

Isso "trouxe meu sistema de volta" ao mesmo estado em que estava imediatamente após a instalação pipewireet. al. (quando funcionava bem!). Então - tenho um sistema totalmente funcional novamente neste ponto; 9 de outubro de 2024.

6. Iniciar atualizações incrementais; 9 de outubro de 2024

Por meio de um processo de tentativa e erro, comecei uma atualização "incremental", usando sudo apt-get install --only-upgrade X Y Z etc. Após cada atualização, verifiquei se o Bluetooth ainda estava funcionando. Depois que reduzi a lista de pacotes desinstalados para o seguinte, o Bluetooth ainda estava funcionando:

$ apt list --upgradable
Listing... Done

libpipewire-0.3-common/stable-backports,stable-backports 1.2.4-1~bpo12+1 all [upgradable from: 1.2.1-1~bpo12+1]
libpipewire-0.3-modules/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
libspa-0.2-bluetooth/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
libspa-0.2-modules/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
pipewire-alsa/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
pipewire-audio-client-libraries/stable-backports,stable-backports 1.2.4-1~bpo12+1 all [upgradable from: 1.2.1-1~bpo12+1]
pipewire-bin/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
pipewire-jack/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
pipewire-pulse/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
pipewire/stable-backports 1.2.4-1~bpo12+1 arm64 [upgradable from: 1.2.1-1~bpo12+1]
wireplumber/stable-backports 0.5.6-1~bpo12+1 arm64 [upgradable from: 0.4.17-1~bpo12+1]

7. pipewireet. al. são aparentemente os únicos responsáveis ​​pelo mau funcionamento do Bluetooth. Acho que isso pode ser "nenhuma surpresa" para muitos, mas senti que precisava estabelecer o mais especificamente possível a origem do problema.

Aqui está minha pergunta: Como eu estraguei tudo ? Nunca usei backportsantes, e presumi que quando o canal regular "alcançasse" backportsisso apt, tudo seria mesclado/instalado sem incidentes. Obviamente, não foi isso que aconteceu aqui. O que preciso fazer para consertar isso?

Eu tenho um Raspberry Pi que está executando a versão ‘bookworm’ do sistema operacional; a versão de 64 bits do sistema operacional, se isso fizer alguma diferença. Instalei um dos sensores de temperatura e umidade SHT3X e aparentemente está funcionando bem. Está conectado via interface I2C (canal 0, /dev/i2c-0acredito). Posso ler temperatura e umidade nos arquivos sysfs; Acredito que o sensor esteja funcionando corretamente.

Descobri que existem duas pastas idênticas que sysfscontêm os mesmos arquivos de saída e controle para o dispositivo SHT3X:

pasta 1:/sys/devices/platform/soc/3f205000.i2c/i2c-0/0-0044/hwmon/hwmon2

$ ls -l
total 0
lrwxrwxrwx 1 root root    0 Jun  2 21:55 device -> ../../../0-0044
-rw-r--r-- 1 root root 4096 Jun  2 21:55 heater_enable
-r--r--r-- 1 root root 4096 Jun  2 21:55 humidity1_alarm
-r--r--r-- 1 root root 4096 Jun  2 21:55 humidity1_input
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_max
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_max_hyst
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_min
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_min_hyst
-r--r--r-- 1 root root 4096 Jun  2 21:55 name
lrwxrwxrwx 1 root root    0 Jun  2 21:55 of_node -> ../../../../../../../../firmware/devicetree/base/soc/i2c@7e205000/sht3x@44
drwxr-xr-x 2 root root    0 Jun  2 21:55 power
-rw-r--r-- 1 root root 4096 Jun  2 21:55 repeatability
lrwxrwxrwx 1 root root    0 Jun  2 21:55 subsystem -> ../../../../../../../../class/hwmon
-r--r--r-- 1 root root 4096 Jun  2 21:55 temp1_alarm
-r--r--r-- 1 root root 4096 Jun  2 21:55 temp1_input
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_max
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_max_hyst
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_min
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_min_hyst
-rw-r--r-- 1 root root 4096 Jun  2 21:52 uevent
-rw-r--r-- 1 root root 4096 Jun  2 21:55 update_interval

pasta 2:/sys/class/hwmon/hwmon2

$ ls -l
total 0
lrwxrwxrwx 1 root root    0 Jun  2 21:55 device -> ../../../0-0044
-rw-r--r-- 1 root root 4096 Jun  2 21:55 heater_enable
-r--r--r-- 1 root root 4096 Jun  2 21:55 humidity1_alarm
-r--r--r-- 1 root root 4096 Jun  2 21:55 humidity1_input
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_max
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_max_hyst
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_min
-rw-r--r-- 1 root root 4096 Jun  2 21:55 humidity1_min_hyst
-r--r--r-- 1 root root 4096 Jun  2 21:55 name
lrwxrwxrwx 1 root root    0 Jun  2 21:55 of_node -> ../../../../../../../../firmware/devicetree/base/soc/i2c@7e205000/sht3x@44
drwxr-xr-x 2 root root    0 Jun  2 21:55 power
-rw-r--r-- 1 root root 4096 Jun  2 21:55 repeatability
lrwxrwxrwx 1 root root    0 Jun  2 21:55 subsystem -> ../../../../../../../../class/hwmon
-r--r--r-- 1 root root 4096 Jun  2 21:55 temp1_alarm
-r--r--r-- 1 root root 4096 Jun  2 21:55 temp1_input
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_max
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_max_hyst
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_min
-rw-r--r-- 1 root root 4096 Jun  2 21:55 temp1_min_hyst
-rw-r--r-- 1 root root 4096 Jun  2 21:52 uevent
-rw-r--r-- 1 root root 4096 Jun  2 21:55 update_interval

E tem mais; por exemplo:

pasta 3:/sys/devices/platform/soc/3f205000.i2c/i2c-0/0-0044/hwmon/hwmon2/subsystem/hwmon2

Sei que há links simbólicos envolvidos, mas existe um local verdadeiro/imutável para esses arquivos sysfs? Li algumas referências em sysfs 1 , 2 , mas não encontrei explicação para essa aparente duplicação. Alguém pode explicar a aparente redundância e se existe um local imutável para os arquivos?

Eu sei que há algumas perguntas aqui que fazem a mesma pergunta que pareço estar fazendo. Eu tentei essas sugestões 1 e 2 , mas elas não funcionam neste caso. Aqui está o que aconteceu:

pi@raspberrypi0w:~ $ sudo apt -t bullseye-backports install udev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  libudev1
The following packages will be upgraded:
  libudev1 udev
2 upgraded, 0 newly installed, 0 to remove and 35 not upgraded.
Need to get 1,654 kB of archives.
After this operation, 511 kB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://deb.debian.org/debian bullseye-backports/main armhf udev armhf 252.5-2~bpo11+1 [1,554 kB]
Get:2 http://deb.debian.org/debian bullseye-backports/main armhf libudev1 armhf 252.5-2~bpo11+1 [100 kB]
Fetched 1,654 kB in 1s (1,267 kB/s)
Reading changelogs... Done
(Reading database ... 43648 files and directories currently installed.)
Preparing to unpack .../udev_252.5-2~bpo11+1_armhf.deb ...
Unpacking udev (252.5-2~bpo11+1) over (247.3-7+rpi1+deb11u2) ...
Preparing to unpack .../libudev1_252.5-2~bpo11+1_armhf.deb ...
Unpacking libudev1:armhf (252.5-2~bpo11+1) over (247.3-7+rpi1+deb11u2) ...
Setting up libudev1:armhf (252.5-2~bpo11+1) ...
Setting up udev (252.5-2~bpo11+1) ...
Segmentation fault
Job for systemd-udevd.service failed because a fatal signal was delivered to the control process.
See "systemctl status systemd-udevd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript udev, action "restart" failed.
● systemd-udevd.service - Rule-based Manager for Device Events and Files
     Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static)
     Active: activating (start) since Tue 2024-04-09 07:36:27 UTC; 130ms ago
TriggeredBy: ● systemd-udevd-control.socket
             ● systemd-udevd-kernel.socket
       Docs: man:systemd-udevd.service(8)
             man:udev(7)
   Main PID: 8773 ((md-udevd))
      Tasks: 1
        CPU: 45ms
     CGroup: /system.slice/systemd-udevd.service
             └─8773 (md-udevd)

Apr 09 07:36:28 raspberrypi0w systemd[1]: Stopped Rule-based Manager for Device Events and Files.
Apr 09 07:36:28 raspberrypi0w systemd[1]: Starting Rule-based Manager for Device Events and Files...
Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Main process exited, code=killed, status=11/SEGV
Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Failed with result 'signal'.
Apr 09 07:36:28 raspberrypi0w systemd[1]: Failed to start Rule-based Manager for Device Events and Files.
Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Scheduled restart job, restart counter is at 5.
Apr 09 07:36:28 raspberrypi0w systemd[1]: Stopped Rule-based Manager for Device Events and Files.
Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Start request repeated too quickly.
Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Failed with result 'signal'.
Apr 09 07:36:28 raspberrypi0w systemd[1]: Failed to start Rule-based Manager for Device Events and Files.
dpkg: error processing package udev (--configure):
 installed udev package post-installation script subprocess returned error exit status 1
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u8) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for initramfs-tools (0.140) ...
Errors were encountered while processing:
 udev
E: Sub-process /usr/bin/dpkg returned an error code (1)

A tentativa de “reversão” não foi muito interessante:

pi@raspberrypi0w:~ $ apt install ${udev}/bullseye
Illegal instruction

Tentei algumas outras "reversões":

pi@raspberrypi0w:~ $ sudo apt install udev
Illegal instruction
pi@raspberrypi0w:~ $ sudo apt-get install udev/stable
Illegal instruction
pi@raspberrypi0w:~ $ sudo apt-get install udev/old-stable
Illegal instruction

Uma 'falha de segmentação' - parece grave :). Eu não tinha certeza do que isso significava; ou seja, o sistema rejeitou automaticamente a udevatualização e reverteu automaticamente? - ou eu pisei nisso? Esperei alguns minutos e tentei isto:

$ systemctl status systemd-udevd.service
● systemd-udevd.service - Rule-based Manager for Device Events and Files
     Loaded: loaded (/lib/systemd/system/systemd-udevd.service; static)
     Active: failed (Result: signal) since Tue 2024-04-09 07:36:28 UTC; 28min ago
TriggeredBy: ● systemd-udevd-control.socket
             ● systemd-udevd-kernel.socket
       Docs: man:systemd-udevd.service(8)
             man:udev(7)
    Process: 8776 ExecStart=/lib/systemd/systemd-udevd (code=killed, signal=SEGV)
   Main PID: 8776 (code=killed, signal=SEGV)
        CPU: 199ms

Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Scheduled restart job, restart counter is at 5.
Apr 09 07:36:28 raspberrypi0w systemd[1]: Stopped Rule-based Manager for Device Events and Files.
Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Start request repeated too quickly.
Apr 09 07:36:28 raspberrypi0w systemd[1]: systemd-udevd.service: Failed with result 'signal'.
Apr 09 07:36:28 raspberrypi0w systemd[1]: Failed to start Rule-based Manager for Device Events and Files.

Eu tenho um bom backup (de imagem) da noite passada, então, se eu matar meu sistema operacional, posso me recuperar. No entanto, prefiro corrigir isso sem recorrer ao backup - se for possível.

O que devo fazer?

Procurei sem sucesso um método para listar todas as atualizações disponíveis nos backports do Debian (especificamente bullseye-backports):

• Eu adicionei deb http://deb.debian.org/debian bullseye-backports main contrib non-freeao /etc/apt/sources.list.

• Eu corri sudo apt updatecom sucesso

• Corri sudo apt list --upgradeable bullseye-backportscom um resultado "vazio"

• Eu corri sudo apt list --upgradeable -t bullseye-backports; ocorreu um erro

• Eu corri sudo apt -t bullseye-backports upgrade; Recebo uma lista de NOVOS pacotes a serem instalados e uma lista de pacotes EXISTENTES a serem atualizados e uma [Y/n]opção para prosseguir com o lote inteiro.

Não há como simplesmente listar os pacotes que podem ser atualizados bullseye-backports?

Já uso rsynchá algum tempo e sempre funcionou muito bem. No entanto, tentar rsyncmeu macOS (fonte, sistema de arquivos APFS) com meu Synology NAS (dest, sistema de arquivos btrfs) parece sempre apresentar "desafios" que não encontro em outros usos do rsync.

Alguns dos meus “desafios” são com a nomenclatura usada (particularmente) na rsyncdocumentação; ou seja man rsync. Espero encontrar algum esclarecimento sobre esta questão; a seguir estão os detalhes:

rsyncé a sincronização "unidirecional"; man rsyncdescreve o -i( --itemize-changes) da seguinte forma:

[output is cryptic string] that is 11 letters long. The general format is    
YXcstpoguax, where Y is replaced by the type of update being done ... 

A < means that a file is being transferred to the remote host (sent)  

A > means that a file is being transferred to the local host (received)

Ao usar o seguinte rsynccomando:

# Version:
rsync --version
rsync  version 3.2.7  protocol version 31   

# The command (simplified)
rsync -rlAtgoDiv /Users/seamus/Desktop/ /Volumes/backups/Desktop

Eu recebo a seguinte saída:

>f..t....... BooksBlogsEtc/pix/Capucine02.jpg

É aqui que perco o enredo. O >diz "file being transferred to local host (received)", mas tomando esta afirmação pelo valor nominal , diz que o arquivo está sendo transferido para o meu Mac e do NAS – ele está sendo recebido . IOW, confundi o termo sourcecom sente (em menor grau) local host. Mas não é isso que parece estar acontecendo - o arquivo no exemplo acima está sendo enviado da origem/Mac para o destino/NAS.

Alguém pode me explicar essas aparentes discrepâncias?

Estou tentando encontrar uma string em uma página da web baixada com curl. Estou usando greppara encontrar a string que corresponde a um padrão de expressão regular .

A seguir está a string que estou tentando encontrar:

./download/file.php?id=86753

Esta string faz parte desta string maior na página da web:

href="./download/file.php?id=86753"

O grepencantamento com o qual estou trabalhando é o seguinte:

grep -Eo '\.\/download\/file\.php\?id=[0-9]+' dlfile.html

Mas isso não encontra nada no arquivo html. No entanto, se eu modificar grepda seguinte forma, recebo duas (2) correspondências. A primeira partida é a que preciso; a segunda é uma distração inútil e não deve ser incluída:

grep -Eo '\/download\/file\.php\?id=[0-9]+' dlfile.html
/download/file.php?id=86753
/download/file.php?id=62517

A string que contém a segunda correspondência (indesejada) é a seguinte:

href="https://web.archive.org/web/20190824162104/https://www.somewhere.com/forums/download/file.php?id=62517&sid=907ab04af81e19ad758c5bcf8ebdca32"

Parece que o problema é a falha em reconhecer o início .(ponto) na string. Observe que esta é a principal diferença entre a string desejada e a string indesejada.

P: Por que isso não funciona e o que eu preciso?

Meu ambiente: derivado do Debian (Raspberry Pi), versão 'bullseye'

Qual grepe bashestou usando?

$ grep --version
grep (GNU grep) 3.6
...
$ bash --version
GNU bash, version 5.1.4(1)-release (arm-unknown-linux-gnueabihf)

Tenho um arquivo aberto vime terminei minhas edições. Existe uma maneira de eu fechar o arquivo (ou buffer ) para que a vimtela fique em branco?

Estou tentando modificar um script que usa o seguinte:

# first portion of script
# ...
exec > >(tee -ia $OUT)
# ...
# second portion of script 

O problema que tenho com este script é que ele produz uma saída volumosa para stdout(meu terminal). O autor do script não incluiu opções para eliminar a saída do terminal. Gostaria de adicionar uma opção que remova o stdoute obtenha a saída somente no arquivo $OUT.

Aqui está o que eu tentei:

TERM_OPT="OFF"

# first portion of script
# ...

if [ $TERM_OPT != "OFF" ]; then
     exec > >(tee -ia $OUT)
else {

# ...
# second portion of script 

} > $OUT
fi

Isso parece funcionar, mas não tenho certeza sobre o uso de chaves {} neste contexto, pois a seção GNU de Comandos de agrupamento ( parece ) afirma que ;é necessário um ponto-e-vírgula após a lista. Mas adicionar ;ou deixar de lado parece não fazer diferença. Eu me perguntei se deveria usar parênteses ()em vez de chaves, mas isso faz com que tudo dentro do ()seja executado em um subshell. Não estou particularmente interessado nisso, pois é o script de outra pessoa e as implicações do subshell não são claras para mim (não tentei isso).

A outra coisa que tentei parecia um hack, mas li sobre outras pessoas que o usaram e parece funcionar bem também:

TERM_OPT="OFF"

# first portion of script
# ...

if [ $TERM_OPT != "OFF" ]; then
     exec > >(tee -ia $OUT)
else
     exec > >(tee -ia $OUT 1> /dev/null)
fi

# ...
# second portion of script 

Eu gosto disso porque parece mais independente , mas isso não é uma consideração importante AFAICT.

Portanto, a questão é: Qual é a maneira correta de fazer isso? Com isso, quero dizer qual é a maneira correta de cancelar a saída do terminal após um exec > >(tee -ia $OUT)? Uma dessas soluções é preferível à outra - ou preciso fazer algo completamente diferente?