Seamus's questions

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?

Acabei de construir (a partir do código-fonte) uma versão atual (versão 2.1) no libgpiodmeu RPi 4B. Existem seis (6) "ferramentas de linha de comando" incluídas no tarball de origem do libgpiod. Durante o make installprocesso, essas ferramentas – e suas novas manpáginas – foram instaladas em subpastas em /usr/lib/arm-linux-gnueabihf.

• páginas de manual:./share/man/man1
• ferramentas exe binárias:./bin

Não desinstalei o libgpiodpacote existente do meu sistema. Por enquanto (até eu descobrir se devo ou não manter a versão 2.1, ou se um pacote atualizado for lançado), estou criando links simbólicos apontando /usr/binpara as novas ferramentas no /usr/lib/arm-linux-gnueabihf/bin. Mas não estou claro sobre como lidar com os manproblemas. Quero ver as novas manpáginas; por exemplo, quando eu entro man gpioset, quero ver a página de manual em /usr/lib/arm-linux-gnueabihf/share/man/man1/gpioset.1.

Como o RPi OS é um derivado do Debian, eu esperaria que os manuais fossem instalados na convenção IAW Debian (seja lá o que for). Eu executei um whereisno nome de uma das 6 ferramentas de linha de comando e obtive o seguinte:

$ whereis gpioinfo
gpioinfo: /usr/bin/gpioinfo /usr/bin/gpioinfo.old /usr/share/man/man1/gpioinfo.1.gz

E encontro todos os 6 manuais /usr/share/man/man1(como arquivos compactados "gzip" ). Suponho que uma maneira de substituir as páginas de manual "novas pelas antigas " seria mover ( mv) os manuais antigos e colocar links para os novos em seus lugares. Mas eu esperava algo mais elegante do que isso - talvez uma "linha única" em algum lugar que apontasse para a localização dos novos manuais no formato /usr/lib/arm-linux-gnueabihf/share/man/man1. Existe tal one-liner ?

Existe uma maneira de configurar isso ad hoc - até que o novo libgpiodpacote seja lançado?

Há muita configuração para esta questão:

Eu tenho um host ( rpi5.local) com 2 contas de usuário: pie cake.

Eu queria explorar gite criei a cakeconta para "possuir" os repositórios "servidor/origem". Como usuário cake, em /home/cake, criei uma pasta ( git-srv) com uma subpasta chamada projectA. Passei pelo processo de inicialização deste repositório usando git init --bare.

Inicialmente, "preenchi" o projectArepositório no servidor de outro host ( rpi4b.local). Enviei pushalguns arquivos em uma pasta chamada Aprojectno raspberrypi4b.localhost para o projectArepositório via SSH usando esta sequência:

$ hostname
rpi4b.local
$ pwd
/home/pi/Aproject
$ git push -u ssh://[email protected]/home/cake/git-srv/projectA.git

Isso funcionou bem.

Como usuário pi, clonetransferi o projectArepositório para uma pasta no arquivo /home/pi/XYZ. Fiz & commiteditei algumas alterações em um dos arquivos /home/pi/XYZe tentei fazer pushessas alterações no servidor da seguinte maneira:

$ hostname
rpi5.local
$ pwd
/home/pi/XYZ
$ git push -u /home/cake/git-srv/projectA.git

Recebi um erro com este esforço:

...
error: remote unpack failed: unable to create temporary object directory
To /home/cake/git-srv/projectA.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to '/home/cake/projectA.git'

Depois de pesquisar um pouco sobre esse erro, concluí que era um problema de permissão entre pie cake. Achei que a solução seria su cakeas user pi, então fiz isso e tentei pushnovamente. E finalmente, minha pergunta:

$ whoami
cake
$ hostname
rpi5.local
$ pwd
/home/pi/XYZ
$ git push -u /home/cake/git-srv/projectA.git
fatal: failed to stat '/home/pi/motd.git': Permission denied

O que failed to statsignifica nesta situação e existe uma solução simples ?

Recentemente me familiarizei com o poder restaurador de dpkg-reconfigureseguir uma instalação incorporada do mailutilspacote GNU. No final do processo de instalação, uma caixa de diálogo (ncurses?) aparece solicitando que o usuário faça escolhas e preencha alguns espaços em branco. Está tudo muito bem, e suponho que se você for proficiente o suficiente, você simplesmente evitará cometer erros na "caixa de diálogo de configuração pós-instalação", ou PICDcomo chamarei na sequência.

Não sou proficiente e precisei executar novamente o 'PICD'. Ainda não conhecendo o dpkg-reconfigure, presumi que seria necessário desinstalar e reinstalar. Mas quando fiz isso, a instalação foi concluída - mas o 'PICD' não reapareceu. Eu tentei um reboot, mas ainda não há 'PICD'!?!

Eventualmente, alguém me deu uma dica dpkg-reconfigure, mas dpkg-reconfigure mailutilstambém não conseguiu restaurar o 'PICD'. Acontece que não mailutils era isso que precisava ser reconfigurado - era postfix- o MTA. Isso demorou um pouco para ser resolvido porque o empacotador Debian se mailutilsescondeu habilmente sob um "pacote virtual"postfix inócuo chamado . E assim a magia necessária para obter uma segunda chance de reconfiguração foi: . Essa descoberta permitiu minha abordagem de configuração por tentativa e erro e finalmente a concluí.default-mtadpkg-reconfigure postfix

Mas isso levantou uma ou duas questões para mim:

1. O que desabilita a apresentação do 'PICD' nas instalações subsequentes? Quero dizer, como o script de instalação sabe que o usuário já viu o ‘PICD’? Existe algum valor gravado e salvo pelo instalador para evitar a reprodução do 'PICD' ?

2. Por que o instalador desativa as apresentações subsequentes do 'PICD' (sem o dpkg-reconfigureencantamento)? Qual é o sentido disso, na verdade?

Eu li que o suporte para o exfatsistema de arquivos foi incorporado ao kernel Linux desde que o kernel versão 5.4 foi lançado no final de 2019 - início de 2020. Estou confuso sobre o que isso significa no exfat-fusepacote. AFAIK, o exfat-fusepacote existia antes do kernel versão 5.4 e era o método ad-hoc para montar exfatpartições.

A incorporação de suporte para exfatsistemas de arquivos significa que o exfat-fusepacote não é mais necessário? Por outro lado, se exfat-fuseainda for necessário, o que foi significado/conseguido com a incorporação de exfatsuporte no kernel?

Uma questão relacionada está na documentação para isso - especificamente man mounte em sua FILESYSTEM-SPECIFIC MOUNT OPTIONSseção. Não há menção a um manual específico do sistema de arquivos exfat, nem há uma subseção "Opções de montagem para exfat". O que me leva a perguntar: "Onde são cobertas essas opções de montagem para exfat?" Os usuários deveriam confiar na subseção "Opções de montagem para gordura" em man mount, ou deveriam confiar em man mount.exfat-fuse, ou em alguma outra coisa?

Eu uso systemd-timesyncdcomo cronometrista do sistema há vários anos. Eu executo um derivado do Debian chamado raspbian para meu Raspberry Pis. Estou muito satisfeito com o cliente SNTP systemd-timesyncd, mas gostaria de experimentá-lo chronydpara uso em aplicativos fora da rede.

O seguinte comando pode ser usado para listar a configuração de systemd-timesyncd:

$ systemctl cat systemd-timesyncd

Em buster, havia uma seção de código nesta listagem que fornecia systemd-timesyncda capacidade de "desculpar-se" se encontrasse outro serviço de cronometragem (daemon NTP) instalado:

# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

Em algum momento após o lançamento de buster(simultâneo com o lançamento de bullseye??), o esquema acima foi alterado; o comando systemctl cat systemd-timesyncdnão contém mais referências para restringir ou inibir a inicialização systemd-timesyncdse outros cronometristas forem encontrados.

Alguém se lembra da história dessa mudança? Mais importante ainda, systemd-timesyncdainda inibe sua inicialização se encontrar outro daemon de cronometragem instalado? Onde/como isso é feito?

No meu novo sistema mac os/Darwin, minha findferramenta é uma versão BSD de 11 anos. Eu usei MacPorts para instalar uma versão mais atual: GNU's find, que MacPorts nomeou gfinde colocou em /opt/local/bin/. O antigo fornecido pela Apple findpermanece no formato /usr/bin/find.

Eu preciso manter a versão antiga findno caso de ela ainda ser usada pelo sistema, mas prefiro digitar findna linha de comando em vez de gfind. Velhos hábitos e tudo mais...

Eu sei que posso executar gfindao entrar findcriando um linkin /opt/local/bin/(é antes /usr/binno meu PATH) ou criando um aliasin .zshrc. Ambos funcionam bem. Meu problema é como chegar man gfindquando entro man find- já tentei várias versões do aliasin .zshrc, mas nenhuma funcionou.

Como faço para que isso funcione? Como faço para aparecer man gfindna tela do meu pager quando digito man findna linha de comando?

Eu aprendi recentemente que journalctlestá ocupando uma grande parte do meu cartão SD de 16 GB (Raspberry Pi):

$ journalctl --disk-usage
Archived and active journals take up 312.1M in the file system.  

Eu não sinto isso journalctle estou puxando seu pesojournald no meu caso de uso para esta máquina. É um RPi antigo e também está em execução. Eu estimo que minha necessidade e uso de talvez seja "uma vez na lua azul" . Consequentemente, decidi que iria desabilitar - o que "alimenta" . Eu assumi que isso seria direto, usando to , ou talvez apenas ing the para que ele não iniciasse na próxima inicialização.rsyslogjournalctljournaldjournalctlsystemctlstopdisablesystemd-journald.service

Antes de puxar o plugue, decidi fazer algumas pesquisas. Em vez de encontrar milhares de referências que ofereciam conselhos de "como fazer", havia notavelmente poucos resultados abordando meu termo de pesquisa específico: "como desativar o journald" . Em vez disso, os resultados ofereceram principalmente conselhos sobre a redução journalddo consumo de recursos . Encontrei algumas referências que me deram uma pausa:

Um tópico antigo no fórum do ArchLinux sugeriu que não era possível desabilitar journaldsem repercussões ; ou seja, "Masking systemd-journald causes all kinds of dependency failures and drops you at an emergency prompt."mas este post já tem 10 anos...

O manual do systemd-journald.service diz, "stopping it [systemd-journald.service] is not recommended.". A documentação prossegue a partir daí para discutir namespaces ?

Aprendi que o comando usual para impedir que as systemdunidades iniciem não tem efeito; ou seja, ele inicia normalmente:

$ sudo systemctl disable systemd-journald.service
$ sudo reboot 

# ... and after boot & login:

$ systemctl status systemd-journald.service
● systemd-journald.service - Journal Service
     Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Fri 2022-06-03 07:30:29 UTC; 1min 59s ago
TriggeredBy: ● systemd-journald-audit.socket
             ● systemd-journald.socket
             ● systemd-journald-dev-log.socket
       Docs: man:systemd-journald.service(8)
             man:journald.conf(5)
   Main PID: 134 (systemd-journal)
     Status: "Processing requests..."
      Tasks: 1 (limit: 1598)
        CPU: 820ms
     CGroup: /system.slice/systemd-journald.service
             └─134 /lib/systemd/systemd-journald

...
$ 

Como pode journaldser desativado? ... ou pode ser desativado?

Se não, por que os systemddesenvolvedores forçariam isso aos usuários? (OK, sim - pedindo uma opinião, então esqueça essa parte da pergunta.)

Talvez uma pergunta idiota, mas eu sou novo nisso - então, por favor, tenha paciência comigo.

Segue uma breve descrição da situação :

1. Recentemente, soube de um bug significativo e de longa data dhcpcd- o gerenciador de rede padrão para o RPi OS. Coincidentemente, alguém enviou uma solicitação de pull ao dhcpcdsite do GitHub que foi confirmada recentemente.

2. A organização RPi não publica suas dhcpcdfontes no GitHub, mas elas estão disponíveis via apt-get source dhcpcd5. Isso gerou uma nova pasta ( ~/dhcpcd5-8.1.2), um .dscarquivo (com várias imprecisões) e um tararquivo compactado ( dhcpcd5_8.1.2.orig.tar.xz) - não havia diff.gzarquivo/pasta. Eu incorporei a correção de código-fonte simples (uma única linha de código) e aprendi o suficiente para construir um novo .debarquivo com sucesso. Instalei e testei o .debarquivo em 3 dos meus sistemas; ele resolve o problema e não encontrei efeitos colaterais

3. Aconselhei um indivíduo da organização RPi sobre minhas descobertas há algum tempo, mas não obtive nenhum feedback. Aparentemente, não há local para enviar alterações propostas pelo usuário para os arquivos de origem do pacote Debian - nenhum mecanismo de solicitação de pull iow.

Eu gostaria de compartilhar meu esforço. Ocorreu-me que pode (deveria?) haver um método pelo qual eu possa efetivamente criar um repositório git a partir do conteúdo dos dhcpcdarquivos de origem do pacote Debian. Eu sei o suficiente gitpara fazer upload do conteúdo ~/dhcpcd5-8.1.2em um repositório do GitHub; mas minhas dúvidas são essas :

1. A pasta ~/dhcpcd5-8.1.2contém alguns arquivos binários. Acho que esses arquivos foram criados durante o debuildprocesso. Como faço para limpar binários das fontes em ~/dhcpcd5-8.1.2?

2. Existem vários patches em dhcpcd5-8.1.2/debian/patches; posso confiar com segurança nessas respostas de 2016 para garantir que todos os patches sejam aplicados ao código-fonte?

3. Como não sei o suficiente para fazer mais perguntas, vou perguntar: "Isso funcionará?" O que significa que, se todos os binários forem removidos e a alteração atual e todos os patches anteriores forem aplicados - alguém sem experiência específica poderá clonar o repositório do GitHub que desejo criar e construí-lo usando debuild -b -uc -us?

Acabei de concluir uma modificação e reconstrução simples do código-fonte em uma máquina Raspberry Pi OS - bullseye. Como isso é novo para mim, vou listar as etapas que segui em um esforço para evitar ambiguidade:

$ dhcpcd --version
dhcpcd 8.1.2                            # "before" version
$ sudo apt install devscripts           # build tools for using `debuild`
$ apt-get source dhcpcd5                # creates source tree ~/dhcpcd5-8.1.2; Debian git repo is far off!
$ cd dhcpcd5-8.1.2                      # cd to source dir
$ nano src/dhcp.c                       # make required changes to the source (one line)
~/dhcpcd5-8.1.2 $ debuild -b -uc -us    # successful build
$ cd ..
$ sudo dpkg -i dhcpcd5_8.1.2-1+rpt5_armhf.deb # install .deb file created by debuild
$ dhcpcd --version
dhcpcd 8.1.2                            # "after" version
$ 

Tudo bem, mas os números de versão "antes" e "depois" são exatamente os mesmos, o que me deixa sem uma maneira simples de saber se tenho meu código corrigido em execução ou o código não corrigido . Vou instalar o arquivo .deb corrigido em vários hosts, posso receber solicitações de outros, etc, então gostaria de alguma maneira de distinguir facilmente o código corrigido do não corrigido .

Usando dhcpcd --versionparece uma maneira fácil de fazer isso. Eu li que o Debian tem regras sobre números de versão, mas como não estou liberando isso para "o mundo", não vejo necessidade de formalidade. Além disso - enviei uma solicitação de pull/merge para o repositório Debian e avisei a organização RPi sobre o problema. Não recebi nenhum feedback de nenhuma das partes, mas esse bug é um grande aborrecimento para mim. Não desejo esperar por um novo lançamento dhcpcdcom um número de versão "adequado".

O que devo fazer para que a versão corrigidadhcpcd de reporte dhcpcd 8.1.2.1- ou algo semelhante?

EDIT para esclarecimento:

Com base nessa resposta , editei dhcpcd5-8.1.2/debian/changelog. Após essa alteração, os aptutilitários relatam consistentemente a versão de dhcpcdcomo 8.1.3:

$ apt-cache policy dhcpcd5
dhcpcd5:
  Installed: 1:8.1.3-1+rpt1
  Candidate: 1:8.1.3-1+rpt1
  Version table:
 *** 1:8.1.3-1+rpt1 100
        100 /var/lib/dpkg/status
     1:8.1.2-1+rpt1 500
        500 http://archive.raspberrypi.org/debian buster/main armhf Packages
     7.1.0-2 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
$ #
$ dpkg -s dhcpcd5 | grep Version
Version: 1:8.1.3-1+rpt1 
$

No entanto: dhcpcd --versionainda relata 8.1.2. dhcpcdé alias dhcpcd5em /etc/alternatives. Consequentemente, dhcpcd --versioné na verdade dhcpcd5 --version. Parece que o executável estádhcpcd5 recebendo --versionde uma fonte diferente dos aptutilitários.?

EDIÇÃO 2:

Acontece que a versão # que é relatada por dhcpcd --versioné definida da defs.hseguinte forma:

#define PACKAGE                 "dhcpcd"
#define VERSION                 "8.1.2"

Eu acho que dhcpcd é um pouco outlier . A equipe do RPi aparentemente decidiu renunciar à versão upstream 9 quando lançada (anos atrás), e manteve a versão 8.1.2, embora houvesse vários lançamentos upstream após a versão 8.1.2. Ainda mais confuso é o fato de que o .dscarquivo lista Vcs-Browser: https://salsa.debian.org/smlx-guest/dhcpcd5como o repositório Git - mas na verdade está preso na versão 7. Isso não faz muito sentido para mim - acho que é uma das razões pelas quais não sou um mantenedor de pacotes. :)