Estou criando instantâneos de sistema de arquivos inteiros (com BTRFS) periodicamente. Preciso impedir que meu script tire instantâneos enquanto o sistema estiver em um estado inconsistente, como no meio de uma instalação de aplicativo ou de uma atualização completa do sistema.

1. Como posso detectar de forma confiável tais ações?

Como não podemos invocar várias aptinstâncias, também quero criar um bloqueio para apt install(ou qualquer outro software de gerenciamento de pacotes) para ter certeza de que a operação de instantâneo foi concluída (pode levar vários segundos dependendo da E/S do disco).

2. Como posso impedir temporariamente a execução de qualquer aplicativo de gerenciamento de pacotes?

Estou depurando uma situação em que o relatório de porcentagem de bateria restante não é preciso para minha bateria recém-instalada.

Em relação à resposta da minha pergunta anterior , várias ferramentas consultam as informações da bateria diretamente da própria bateria. No entanto, a saída da tensão da bateria difere entre /sys/class/power_supply/BAT1/voltage_nowe upower:

# upower
    voltage:             10.974 V

# /sys/...
10500000

Além disso, upoweratualiza suas estatísticas a cada 2 minutos, onde /sys/class/power_supply/BAT1/voltage_nowparece ser atualizado ao vivo. Isso também indica que as fontes dessas duas fontes de dados são provavelmente diferentes.

Então, quais são as fontes de dados dessas duas fontes de dados?

Aviso de correção

Lamento trazer este problema à tona com base em uma memória incorreta da contagem de células em série. Não havia 4 células em série, mas 3 células. Bobo eu. Para 3 células em série, a tensão máxima da bateria deve ser 4.2V * 3 = 12.6V, o que parece bastante consistente aqui, portanto, a "parte do cálculo da tensão" da questão é imprecisa.

Pergunta original

Estou usando o LXDE e o miniaplicativo da bateria mostra 100% como estado da bateria. Outros comandos suportam essa porcentagem:

ceremcem@cca-erik:~$ acpi
Battery 0: Full, 100%
ceremcem@cca-erik:~$ upower -i `upower -e | grep bat`
  native-path:          BAT1
  vendor:               LGC
  model:                DELL 49VTP27J
  serial:               7849
  power supply:         yes
  updated:              Fri 17 Jan 2020 11:46:50 AM +03 (105 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    warning-level:       none
    energy:              73.26 Wh
    energy-empty:        0 Wh
    energy-full:         73.26 Wh
    energy-full-design:  48.84 Wh
    energy-rate:         0.0111 W
    voltage:             12.014 V
    percentage:          100%
    capacity:            100%
    technology:          lithium-ion
    icon-name:          'battery-full-charged-symbolic'

O problema real é que a tensão nominal da bateria é de 14,4 V (3,6 V/célula, 4 séries). Isso significa que em 100% SOC (estado de carga), a bateria deve estar em 4.2 * 4 = 16.8V. Se você vir a battery -> voltageseção, ela está atualmente em 12,0 V, o que significa 3,0 V por célula, o que significa que está em 0% SOC (totalmente vazia) de acordo com Batteryuniversity.com :

Como esses comandos decidem o SOC? Eles estão perguntando diretamente para a bateria? Como podemos recalibrar essa incompatibilidade?

Como os UUIDs são atribuídos na fase de particionamento (por software), não há UUID disponível para o disco inteiro.

No entanto, /dev/disk/by-id/contém informações promissoras para o mesmo fim. Podemos obter o caminho "UUID" para - por exemplo. /dev/sdb/por:

$ disk=sdb; ls /dev/disk/by-id/ -l | grep "/$disk$" | awk '{print "/dev/disk/by-id/"$9}'
/dev/disk/by-id/ata-ST1000LM048-2E7172_WKP6XK95
/dev/disk/by-id/wwn-0x5000c500ccbb7485

No entanto, como você pode ver, há mais de uma entrada para a mesma unidade. O que termina com WKP6XK95faz mais sentido, pois está escrito fisicamente na etiqueta do produto, na seção "Número de série".

Como posso obter o único valor possivelmente gravado no disco? Em outras palavras, como o wwn-...id é gerado, então como posso ignorar com segurança essa entrada? Ignorar esta entrada ... | grep -v wwnseria seguro?

De https://manpages.debian.org/wheezy/multistrap/multistrap.1 :

--no-auth - permite o uso de repositórios não autenticados. O mesmo que noauth=true

O que eu entendo dessa definição é que multistrapnão tentará autenticar, portanto, softwares inseguros podem ser instalados.

No entanto, não parece ser o caso: A configuração noauth=true lança o seguinte erro :

Get:1 http://ftp.uk.debian.org/debian buster InRelease [122 kB]
Err:1 http://ftp.uk.debian.org/debian buster InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY DCC9EFBF77E11517
Reading package lists... Done
W: GPG error: http://ftp.uk.debian.org/debian buster InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 04EE7237B7D453EC NO_PUBKEY 648ACFD622F3D138 NO_PUBKEY DCC9EFBF77E11517
E: The repository 'http://ftp.uk.debian.org/debian buster InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
apt update failed. Exit value: 100

A parte interessante é que a configuração noauth=falsecorrige o problema.

O que noauthcausa exatamente?

Acontece que estou tentando criar uma distribuição portátil enquanto me preparo para qualquer tipo de falha de hardware.

Estou criando (ou restaurando) uma distribuição Debian por multistrap (ou de meus backups) e exigindo que o disco resultante seja inicializável em um novo hardware (principalmente compatível), incluindo uma máquina VirtualBox .

Como perguntei antes , uma das poucas coisas necessárias para uma "distro portátil" é lidar com os nomes das interfaces de rede.

Por exemplo, na máquina real, o primeiro dispositivo ethernet é nomeado como enp2s0e no VirtualBox, é nomeado como enp0s3. Como devo gerar um /etc/network/interfacesarquivo na inicialização?

Existe uma maneira mais genérica de remapear os nomes da interface de rede (por links simbólicos, talvez) e permitir que cada aplicativo use esses nomes (os nomes das funções) sem a necessidade de conhecer os nomes reais da interface de rede do hardware subjacente?

Em https://wiki.debian.org/Multistrap#Steps_for_Squeeze_and_later , é necessário executar o seguinte comando no ambiente chroot:

/var/lib/dpkg/info/dash.preinst install

Este comando é executado no Stretch, porém não há nenhum /var/lib/dpkg/info/dash.preinstarquivo encontrado no Buster.

Qual pode ser o comando equivalente para completar a instalação no Buster?

Reprodução

git clone https://github.com/ceremcem/multistrap-example
cd multistrap-example
./build.sh buster

Estou tentando fazer uma instalação do Debian manualmente do zero para um disco externo dentro de um CD do Debian ao vivo.

Eu criei um rootfs Debian Stretch via multistrap seguindo as instruções daqui ( 44fbcc) .

Dentro chrootdo ambiente, quando se trata de instalação do Grub, instalo o Grub2 no MBR:

debian:~# grub-install /dev/sdX --boot-directory=/boot

Comando é executado sem erro. Quando preciso criar o /boot/grub/grub.cfg, ele lança o seguinte erro:

debian:~# grub-mkconfig
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).

Sim, /devé montado junto com /sys, /proce /run aqui .

Como posso gerar ambiente grub.cfginterno chroot?

Eu estava sem espaço em disco, então limpei meus instantâneos antigos como costumo fazer. Desta vez, df -h /insisti em mostrar "nenhum espaço disponível" enquanto btrfs fi df /mostrava alguns GB de espaço, então decidi executar um arquivo btrfs balance.

btrfs balancefalhou devido a erros de "espaço insuficiente", pesquisei na rede e direcionei para esta postagem no blog que aconselha a solucionar esse problema adicionando temporariamente um pequeno dispositivo (mesmo um pendrive USB) para poder executar btrfs balancee removê-lo quando terminar.

Adicionei meu pendrive ao meu rootfs:

btrfs dev add /dev/sdc1 /

Nenhum erro mostrado e agora eu tinha algum espaço livre. Eu corro btrfs balancee quando terminar, tentei remover o pendrive:

sudo btrfs dev del /dev/sdc1 /
ERROR: error removing device '/dev/sdc1': unable to go below two devices on raid1

O BTRFS de alguma forma decidiu usar a unidade no perfil RAID1 para metadados e dados do sistema:

$ sudo btrfs fi usage / 
Overall:
    Device size:         864.53GiB
    Device allocated:        857.05GiB
    Device unallocated:        7.48GiB
    Device missing:          0.00B
    Used:            830.28GiB
    Free (estimated):         24.93GiB  (min: 21.23GiB)
    Data ratio:               1.00
    Metadata ratio:           2.00
    Global reserve:      512.00MiB  (used: 0.00B)

Data,single: Size:828.01GiB, Used:810.56GiB
   /dev/mapper/masa-root     828.01GiB

Data,RAID1: Size:2.02GiB, Used:2.01GiB
   /dev/mapper/masa-root       2.02GiB
   /dev/sdc1       2.02GiB

Data,DUP: Size:2.00GiB, Used:1.94GiB
   /dev/sdc1       4.00GiB

Metadata,RAID1: Size:2.97GiB, Used:131.61MiB
   /dev/mapper/masa-root       2.97GiB
   /dev/sdc1       2.97GiB

Metadata,DUP: Size:7.50GiB, Used:5.78GiB
   /dev/mapper/masa-root      15.01GiB

System,RAID1: Size:32.00MiB, Used:128.00KiB
   /dev/mapper/masa-root      32.00MiB
   /dev/sdc1      32.00MiB

Unallocated:
   /dev/mapper/masa-root       1.97GiB
   /dev/sdc1       5.51GiB

Como posso remover corretamente este dispositivo temporário?

Após a execução btrfs scrub, os arquivos corrompidos podem ser detectados. Para determinar os arquivos incorrigíveis, podemos tentar ler todos os arquivos no disco:

sudo find / -type f -exec cp -v {} /dev/null \; 2> corrupted-files.txt

A saída deste comando satisfaz a necessidade. No entanto, leva horas para ser concluído.

O wiki do Arch Linux sugere o seguinte comando para determinar os arquivos corrompidos:

sudo journalctl --output cat | grep 'BTRFS .* i/o error' | sort | uniq 

Ele busca resultados rapidamente. No entanto, os caminhos dos arquivos são relativos aos seus caminhos de subvolume, portanto, inestimáveis ​​para corrigir os arquivos dos backups:

BTRFS warning (device dm-2): i/o error at logical 69945753600 on dev /dev/mapper/zeytin-root, sector 142920640, root 636, inode 172280, offset 238682112, length 4096, links 1 (path: home/aea/couchdb/couchdb/data/shards/60000000-7fffffff/client2.1533443496.couch)
BTRFS warning (device dm-2): i/o error at logical 70045958144 on dev /dev/mapper/zeytin-root, sector 143116352, root 422, inode 172296, offset 307662848, length 4096, links 1 (path: home/aea/couchdb/couchdb/data/shards/e0000000-ffffffff/client2.1533443496.couch)
BTRFS warning (device dm-2): i/o error at logical 70045958144 on dev /dev/mapper/zeytin-root, sector 143116352, root 636, inode 172296, offset 307662848, length 4096, links 1 (path: home/aea/couchdb/couchdb/data/shards/e0000000-ffffffff/client2.1533443496.couch)
BTRFS warning (device dm-2): i/o error at logical 70138376192 on dev /dev/mapper/zeytin-root, sector 143296856, root 423, inode 100548, offset 688631808, length 4096, links 1 (path: var/log/auth.log)
BTRFS warning (device dm-2): i/o error at logical 70138425344 on dev /dev/mapper/zeytin-root, sector 143296952, root 423, inode 100548, offset 688644096, length 4096, links 1 (path: var/log/auth.log)
BTRFS warning (device dm-2): i/o error at logical 70138441728 on dev /dev/mapper/zeytin-root, sector 143296984, root 423, inode 100548, offset 688648192, length 4096, links 1 (path: var/log/auth.log)
BTRFS warning (device dm-2): i/o error at logical 70138449920 on dev /dev/mapper/zeytin-root, sector 143297000, root 419, inode 818783, offset 95145984, length 4096, links 1 (path: var/log/daemon.log)
BTRFS warning (device dm-2): i/o error at logical 70138564608 on dev /dev/mapper/zeytin-root, sector 143297224, root 419, inode 818783, offset 95154176, length 4096, links 1 (path: var/log/daemon.log)
BTRFS warning (device dm-2): i/o error at logical 70138884096 on dev /dev/mapper/zeytin-root, sector 143297848, root 419, inode 818783, offset 95174656, length 4096, links 1 (path: var/log/daemon.log)

Existe uma maneira de determinar o caminho do subvolume usando o sector XXXXXXX, root XXX, inode XXXXXXX, offset XXXXXXXXvalor?

O que poderia me impedir de desconectar meu disco rígido atual do laptop e comprar um novo laptop, instalar o disco e retomar de onde parei? Em outras palavras, o que impede que minha instalação atual do Debian 9 seja contada como portátil?

• Se as entradas do Grub estiverem usando referências sólidas (UUID é a solução correta em vez de /dev/sdaXou (hd0,1))
• Se a arquitetura de CPU do novo laptop suportar minha instalação (x64 neste caso)

O novo laptop deve inicializar (e está inicializando no meu caso).

Drivers podem estar faltando na pior das hipóteses, mas minha intenção é criar um script chamado switch-to-new-hardware.shque irá instalar:

• Driver da placa gráfica (se puder, se necessário)
• Driver(s) de placa NIC (eth, wifi) (se necessário)
• Driver da placa de som
• ...

O que deve ser levado em consideração ao mudar para um novo hardware?

btrfs sub snap foo barcria exatamente o mesmo conteúdo de subvolume fooque subvolume bar, exceto os subvolumes em foo.

O que eu quero é excluir algumas pastas regulares também da saída ( bar), como node_modulese tmp; assim como rsync --exclude ...faz.

Existem várias maneiras de fazer isso acontecer, por exemplo:

• Crie um subvolume para cada pasta a ser excluída. (Con: as pastas geradas automaticamente não podem ser excluídas, pois são criadas como pastas normais, como node_modulesneste cenário)
• Crie um subvolume temporário, exclua os arquivos/pastas indesejados (abordagem mais promissora) e crie o subvolume final a partir dele.

Além do acima, podemos aplicar um filtro programático ao criar instantâneos?

Estou iniciando o servidor ssh dropbear no initramfs para poder desbloquear uma partição criptografada por SSH * .

No Debian Jessie, estava tudo bem, mas no Buster, o dropbear parece não parar depois switch_rootde , o que impede que o servidor ssh do OpenBSD seja iniciado.

apt-get purge dropbearnão ajuda e which dropbearimprime /usr/bin/dropbeare ps -ef | grep dropbearimprime /sbin/dropbear; que diz que este processo é aquele que começou no estágio initramfs e não parou.

Como solução alternativa, estou fazendo killall dropbearno script de serviço SSH, mas seria mais apropriado matá-lo antes de alternar a partição raiz.

Como posso executar o script nesse ponto?

Ao tentar compilar um software, apt-getapresentou um erro dizendo que não foi possível localizar o pacote libpyside-dev. Pesquisei esse pacote na rede e encontrei em https://packages.debian.org/sid/libpyside-dev . Não sei em qual repositório devo adicionar para /etc/apt/sources.listpoder instalar este pacote via apt-get.

Onde está a entrada sources.list escrita nessa página?

Editar

1. Minha apt-cache policysaída está aqui .

2. Minha versão Debian ( cat /etc/debian_version) é:buster/sid

3. Adicionar deb https://deb.debian.org/debian/ sid main contrib non-freeparece resolver o problema (junto com outros pacotes problemáticos), mas não tenho certeza se essa é a maneira correta ou não.