Início / user-286615

Seamus's questions

Martin Hope
Seamus
Asked: 2025-02-18 13:53:11 +0800 CST
  • 5

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?

linux-kernel
Martin Hope
Seamus
Asked: 2025-02-07 13:02:03 +0800 CST
  • 7

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'.

bash
Martin Hope
Seamus
Asked: 2025-01-20 07:29:06 +0800 CST
  • 5

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?

bash
Martin Hope
Seamus
Asked: 2024-11-26 17:20:56 +0800 CST
  • 7

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?

bash
Martin Hope
Seamus
Asked: 2024-10-19 15:21:22 +0800 CST
  • 7

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 }'$
}$
...
bash
Martin Hope
Seamus
Asked: 2024-10-16 14:09:38 +0800 CST
  • 5

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?

bash
Martin Hope
Seamus
Asked: 2024-10-11 14:05:55 +0800 CST
  • 7

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?

debian
Martin Hope
Seamus
Asked: 2024-06-03 12:56:30 +0800 CST
  • 6

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?

sysfs
Martin Hope
Seamus
Asked: 2024-04-09 16:14:02 +0800 CST
  • 1

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?

debian
Martin Hope
Seamus
Asked: 2024-04-09 15:14:39 +0800 CST
  • 7

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?

debian
Martin Hope
Seamus
Asked: 2024-03-19 08:17:16 +0800 CST
  • 5

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?

rsync
Martin Hope
Seamus
Asked: 2024-02-17 09:44:37 +0800 CST
  • 1

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&amp;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)
grep
Martin Hope
Seamus
Asked: 2024-01-08 15:26:39 +0800 CST
  • 5

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?

bash
Martin Hope
Seamus
Asked: 2023-12-17 16:06:43 +0800 CST
  • 5

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?

symlink
Martin Hope
Seamus
Asked: 2023-12-15 18:22:26 +0800 CST
  • 5

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 ?

git
Martin Hope
Seamus
Asked: 2023-12-04 02:51:50 +0800 CST
  • 7

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?

debian
Martin Hope
Seamus
Asked: 2023-11-13 11:19:12 +0800 CST
  • 5

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?

linux-kernel
Martin Hope
Seamus
Asked: 2023-10-04 12:01:42 +0800 CST
  • 8

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?

raspbian
Martin Hope
Seamus
Asked: 2022-06-11 16:36:22 +0800 CST
  • 0

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?

zsh symlink