Passar um dispositivo de bloco para o Qemu 3.0.1 assim funciona, mas gera um aviso de depreciação:
-blockdev file,node-name=f1,filename=/dev/loop0 \
-blockdev raw,node-name=q1,file=f1 \
-device virtio-blk,drive=q1
O aviso:
qemu-system-x86_64: -blockdev file,node-name=f1,filename=/dev/loop0:
warning: Opening a block device as a file using the 'file' driver
is deprecated
É justo, mas como passo um dispositivo de bloco para o qemu sem usar o driver 'arquivo'?
Se a linha de comando do kernel contém várias configurações para o mesmo parâmetro, como elas são avaliadas?
Exemplo:
nohz=off ... nohz=on
Qual configuração 'ganha'? O último?
E a lógica de avaliação é a mesma para cada parâmetro?
Em uma apresentação, vi uma ferramenta de linha de comando mencionada que é capaz de registrar os serviços em execução (e as portas de escuta abertas por eles) como uma linha de base e depois verificar essa linha de base e relatar desvios.
Infelizmente, não lembro o nome da ferramenta, apenas que foi escrita em Go (IIRC). De alguma forma, pareço usar os termos de pesquisa errados e, portanto, não consigo encontrá-lo por meio de uma pesquisa no Google.
Qual é o nome dessa ferramenta?
O assistente de configuração de primeira execução do Zsh geralmente adiciona
zstyle :compinstall filename '$HOME/.zshrc'
para o recém-gerado ~/.zshrc.
Qual é o objetivo desta diretiva? Eu poderia encontrar alguma documentação sobre zstyle em geral, mas não sobre a chave de configuração específica.
Especificar systemd.debug-shell=1como um parâmetro do kernel funciona: posso alternar via Alt + F9 para um shell quando a inicialização do systemd trava.
Mas esta concha é completamente impossível porque uma animação
[ *** ] A start job is running for Create Volatile Files and
Directories (4min 23s / no limit)
banner está destruindo meu prompt e saída de linha de comando.
Assim, minha pergunta: como desabilito essa saída obstrutiva do systemd no meu shell tty9?
Estou bem com isso sendo exibido no tty1, ou seja, no console principal - mas, como está, torna o shell de depuração do systemd inutilizável.
Este é o systemd no Fedora 29.
Com o Fedora 27, ao desconectar uma unidade de disco USB externa, o diário registra linhas como estas:
May 07 22:29:11 usb 2-3.1: USB disconnect, device number 23
May 07 22:29:11 sd 3:0:0:0: [sdb] Synchronizing SCSI cache
May 07 22:29:11 sd 3:0:0:0: [sdb] Synchronize Cache(10) failed:
Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
O que se deve fazer sobre isso?
por que o sistema/kernel tenta sincronizar o cache depois que a unidade já está desconectada?
É possível desligar normalmente o disco USB antes da desconexão? Por exemplo, com um comando que emite o comando Synchronize-Cache e, em seguida, desacelera a unidade.
Isso talvez também reduza o estresse mecânico na unidade, pois a perda repentina de energia com o disco giratório não é necessariamente ideal.
Editar: An eject /dev/sdbé ineficaz, ou seja, as mensagens do kernel acima ainda aparecem no dispositivo desconectado e o disco continua girando. Em vez disso, o comando eject produz estas mensagens de log do kernel:
May 18 17:26:06 ldm_validate_partition_table(): Disk read failed.
May 18 17:26:06 Dev sdb: unable to read RDB block 0
May 18 17:26:06 sdb: unable to read partition table
May 18 17:26:06 ldm_validate_partition_table(): Disk read failed.
May 18 17:26:06 Dev sdb: unable to read RDB block 0
May 18 17:26:06 sdb: unable to read partition table
Edit: Desligar o disco com udisksctl power-off --block-device /dev/sdbfunciona:
May 19 08:08:21 udisksd[9447]: Successfully sent SCSI command SYNCHRONIZE CACHE
to /dev/sdb
May 19 08:08:21 udisksd[9447]: Successfully sent SCSI command START STOP UNIT
to /dev/sdb
May 19 08:08:21 kernel: sd 3:0:0:0: [sdb] Synchronizing SCSI cache
May 19 08:08:21 udisksd[9447]: Powered off /dev/sdb - successfully wrote
to sysfs path /sys/devices/pci0000:00/0000:00:14.0/usb2/2-3/2-3.1/remove
May 19 08:08:21 kernel: usb 2-3.1: USB disconnect, device number 60
E, de fato, o disco é desligado.
Toda vez que inicializo um sistema instalado Fedora 27 UEFI, ele mexe com as entradas do gerenciador de inicialização EFI. Por exemplo:
efibootmgrvejo que o Fedora de alguma forma conseguiu adicionar uma entrada para si mesmo (se foi excluído antes) e colocar essa entrada na frente da ordem de inicialização.Esse comportamento faz sentido para instalações padrão, mas não tanto se o Fedora estiver instalado em um pendrive que você deseja inicializar para o trabalho de resgate, sem alterar implicitamente as entradas do gerenciador de inicialização EFI.
Assim, qual peça do Fedora é responsável por essas mudanças no tempo de inicialização? E como isso pode ser desabilitado?
editar: Outra experiência:
Como root, exclua todas as entradas de inicialização do Fedora com efibootmgr e altere a ordem de inicialização para incluir apenas uma entrada genérica (000C).
Inclua efibootmgr no initramfs (usando dracut).
Reinicie e solte no shell dracut.
efibootmgr agora imprime:
BootCurrent: 000C
BootOrder: 000A,0000,...
...
Boot000A* Fedora HD(2,GPT,...)/File(\EFI\fedora\shimx64.efi)
Boot000C* UEFI Misc Device 2 PciRoot(0x0)/Pci(0x5,0x0)...
...
O BootCurrent é o esperado, a mudança no BootOrder (contém tudo agora) e a nova entrada do Fedora são inesperadas.
Portanto, algo em execução entre o shutdown -r nowe o shell de emergência initramfs alterou a configuração do gerenciador de inicialização EFI.
É possível que o firmware UEFI tenha feito essa alteração, mas não vejo como derivaria o nome 'Fedora' e o /EFI/fedora/shimx64.eficaminho.