Guss's questions

Estou construindo um aplicativo que depende do Qt6 e, por padrão, dpkg-buildpackagegera >=dependências para dependências shlibs que não especifiquei explicitamente. Então especificando:

Depends: ${shlibs:Depends}

Causas:

$ dpkg-query --show -f '${Depends}' mypackage
... qt6-base (>= 6.7.2), ...

O problema é que o Qt requer a versão específica exata contra a qual o aplicativo foi criado para poder ser executado. Se o sistema tiver qt6-baseuma versão 6.8.0instalada, meu aplicativo será instalado, mas não será executado - como posso evitar isso?

Não quero aptatualizar meu aplicativo até ter uma versão que suporte explicitamente a versão exata do Qt disponível no sistema (e/ou impedir a atualização do Qt até que eu tenha lançado uma versão apropriada).

Eu sei que posso adicionar dependências explícitas manuais para cada pacote Qt do qual dependo - e então atualizar a versão manualmente toda vez que eu compilar com uma nova versão Qt - mas isso vai ser muito trabalhoso. Eu esperaria que houvesse uma opção de algo como "para pacotes que têm o texto 'qt' em seu nome, use uma =dependência em vez de um >=".

Depois de obter um novo sistema, movi a unidade NVME do meu sistema antigo para o novo, onde ambas as máquinas estão configuradas para inicializar usando UEFI. Como a configuração EFI é específica da máquina, eu esperava encontrar problemas e vim preparado - inicializei a partir de um USB ao vivo, fiz a montagem e o chroot e reinstalei o GRUB de acordo com as instruções (encontradas em todos os lugares na web e repetidas abaixo), depois que uma reinicialização me leva ao prompt de comando do GRUB e não consigo descobrir como consertar isso - não importa o que eu faça, se eu selecionar a entrada de inicialização UEFI do Linux (conforme mostrado abaixo), recebo um prompt do grub. Se eu selecionar a entrada de inicialização UEFI do Windows (este é um sistema de inicialização dupla), ela carrega bem.

Sempre posso inicializar a instalação do Linux a partir do prompt do GRUB digitando configfile (hd0,gpt6)/@/boot/grub/grub.cfgque inicia o menu GRUB que eu esperava e a partir disso posso inicializar qualquer entrada sem problemas (estou usando o BTRFS como a partição raiz e /está no subvolume @- isso é bastante padrão para uma instalação do Ubuntu).

Aqui está a configuração atual:

# efibootmgr --verbose
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0005,0000,0002
Boot0000* UEFI Samsung SSD 970 EVO Plus 1TB S6P7NF0T423021F 1   HD(1,GPT,37b6d616-6865-44b1-a382-9987345e2cfa,0x800,0x32000)/File(\EFI\Boot\BootX64.efi)N.....YM....R,Y.
Boot0001* Neon  HD(1,GPT,37b6d616-6865-44b1-a382-9987345e2cfa,0x800,0x32000)/File(\EFI\Neon\shimx64.efi)
Boot0002* UEFI HTTPs Boot       PciRoot(0x0)/Pci(0x1f,0x6)/MAC(000000000000,0)/IPv4(0.0.0.00.0.0.0,0,0)/Uri()N.....YM....R,Y.
Boot0005* Windows Boot Manager  HD(1,GPT,37b6d616-6865-44b1-a382-9987345e2cfa,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
# ll /boot/efi/EFI/
total 6
drwx------ 6 root root 1024 Jul 26 12:38 ./
drwx------ 4 root root 1024 Jan  1  1970 ../
drwx------ 2 root root 1024 Aug 28  2022 Boot/
drwx------ 5 root root 1024 Jul 26 12:38 Dell/
drwx------ 4 root root 1024 Aug 28  2022 Microsoft/
drwx------ 2 root root 1024 Jul 24 20:01 Neon/
# cat /boot/efi/EFI/Neon/grub.cfg 
search.fs_uuid 2886a665-f535-496e-a543-13c62983b0da root 
set prefix=($root)'/@/boot/grub'
configfile $prefix/grub.cfg

# ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 120 Jul 26 13:20 ./
drwxr-xr-x 9 root root 180 Jul 26 13:20 ../
lrwxrwxrwx 1 root root  15 Jul 26 13:20 2886a665-f535-496e-a543-13c62983b0da -> ../../nvme0n1p6
lrwxrwxrwx 1 root root  15 Jul 26 13:20 80D9-5688 -> ../../nvme0n1p1
lrwxrwxrwx 1 root root  15 Jul 26 13:20 82926928-1ed1-4a76-b0e8-d62a0171c1ee -> ../../nvme0n1p5
lrwxrwxrwx 1 root root  15 Jul 26 13:20 D8D6FA10D6F9EF1E -> ../../nvme0n1p4
# lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,uuid,partuuid
NAME        FSTYPE      SIZE FSUSED LABEL PARTLABEL                    MOUNTPOINT            UUID                                 PARTUUID
nvme0n1               931.5G                                                                                                      
├─nvme0n1p1 vfat        100M  58.8M       EFI system partition         /boot/efi             80D9-5688                            37b6d616-6865-44b1-a382-9987345e2cfa
├─nvme0n1p2              16M              Microsoft reserved partition                                                            fdc1478a-852d-4f33-8e22-24a2ea209726
├─nvme0n1p3 BitLocker  50.2G              Basic data partition                                                                    e8584ca9-db86-4bb1-abf7-424afe77bc94
├─nvme0n1p4 ntfs        517M                                                                 D8D6FA10D6F9EF1E                     5373ade9-ed41-4164-85e2-c28b7026c25f
├─nvme0n1p5 swap       30.5G                                           [SWAP]                82926928-1ed1-4a76-b0e8-d62a0171c1ee d5d866a5-97d4-49bb-a182-6eec3abcba18
└─nvme0n1p6 btrfs     850.2G 440.5G linux                              /var/lib/docker/btrfs 2886a665-f535-496e-a543-13c62983b0da cb45a183-14d3-4a95-b89f-6b5e315609cd

Posso tentar reinstalar por:

1. Remova a entrada de inicialização EFI ofensiva:efibootmgr -b 1 -B
2. Reinstale o boot carregado no disco e EFI:grub-install /dev/nvme0n1 --target x86_64-efi --efi-directory /boot/efi/ --bootloader-id Neon
3. Atualize a configuração do GRUB (não tenho certeza se é necessário, mas é o que dizem os documentos):update-grub2

Depois disso, a configuração parece que estou mostrando acima e, ao reiniciar, o GRUB não iniciará o menu automaticamente. Não tenho certeza sobre o UUID no dump EFI NVRAM, mas esse valor não está configurado em nenhum lugar que eu possa encontrar e é reproduzido se eu remover as entradas e recriá-las.

Alguma ideia do que estou perdendo?

Estou usando a tela (o gerenciador de sessão de terminal com nome problemático) em um sistema remoto acessado por SSH - para executar processos de longa duração e outros. Eventualmente, comecei a usar um comando para anexar diretamente à sessão da tela, em vez de primeiro fazer login por meio do SSH e depois iniciar a tela:

ssh -t hostname screen -xRR

O uso do -xRRé anexar à sessão de tela existente, se disponível, caso contrário, basta criar uma nova. O problema é que quando uma nova sessão é criada, ela não é criada como um shell de login:

$ shopt -q login_shell; echo $?
1

e, como resultado, a configuração da sessão de login (em execução .profilee amigos) não é concluída e, em seguida, faltam partes da configuração, em comparação com o primeiro uso do SSH para fazer o login e depois a execução screen- nesse caso, o shell que o SSH inicia é um shell de login e está configurado corretamente e acho que a tela herda o ambiente.

Tentei usar o -lsinalizador na tela, que está documentado como "modo de login", mas não ajuda - acho que apenas atualiza o "horário de login" para coisas como who.

Alguma idéia de como obter a tela para executar um shell de login?

Criei uma unidade SystemD para iniciar um serviço e esse serviço requer que outra unidade seja iniciada antecipadamente.

Eu configurei o serviço dependente com Requires=dependant.service, e dessa forma quando depending.serviceé iniciado automaticamente durante a inicialização, ele primeiro tenta iniciar dependant.service.

O problema é que, se dependant.servicecomeçar muito cedo, falha ao iniciar (não tenho certeza do que significa "muito cedo" aqui). Para resolver isso, configurei dependant.servicepara Restart=always.

E isso funciona bem - depending.serviceestá habilitado e inicia automaticamente, inicia dependant.service, que trava e depois é reiniciado e sempre consegue iniciar na 2ª tentativa.

Mas depending.servicevi dependant.servicea primeira falha do 's e suas Requires=dependant.servicecausas para falhar. O registro mostra:

systemd[1]: Dependency failed for depending.
systemd[1]: Job depending.service/start failed with result 'dependency'.

Mesmo que dependanteventualmente tenha sucesso, e ambos tenham Restart=always, dependingnunca reinicia após a falha inicial de dependant.

Eu tentei várias configurações de Requires=, e Wants=, mas não consegui encontrar uma combinação que causasse a reinicialização após a reinicialização.BindsTo=Afterdependingdependant