somega's questions

Alguém me disse que o Linux pode rodar em CPUs que não suportam múltiplas tarefas.

Mas se você possui apenas um núcleo que não suporta multitarefa, como o Linux implementa multitarefa?

Digamos que eu queira executar dois programas que precisam de 1h para terminar cada um. Como o Linux pausa o primeiro programa após aproximadamente 100 ms para mudar para o segundo programa?

Aqui estão dois cenários em que posso pensar:

• Não é possível executar várias tarefas ao mesmo tempo.
• O Linux usa um temporizador de hardware para interromper processos em execução.

A Wikipedia faz a diferença entre reinicialização a frio e a quente .

Então, ao usar o rebootcomando no Linux, como escolher entre reinicialização a quente e a frio?

Editar: a Wikipedia menciona um terceiro modo de reinicialização no Linux. Então, como escolher entre esses três modos?

Clonei um pen drive de 1GB para um de 8GB usando o dd.

Mas o tamanho do GPT ainda é de 1 GB. Por exemplo, o GPT secundário (backup) ainda está localizado em 1 GB (deve ser movido para o final do disco).

Também acho que dois campos dentro do GPT principal (no deslocamento 32 e 48) precisam ser atualizados.

Eu procurei, gdiskmas não consegui encontrar nada.

Eu estava brincando /dev/meme descobri que mesmo como usuário root você não pode acessar o arquivo inteiro if CONFIG_STRICT_DEVMEM=y.

Era novidade para mim que existem mecanismos para impedir que o usuário root faça o que quiser.

Mas como root eu poderia simplesmente alterar a imagem do kernel do Linux e reinicializar (para desabilitar a restrição). Se o arquivo de imagem do kernel estiver protegido de alguma forma, eu ainda poderei gravar /dev/sdaou qualquer que seja o disco principal.

Então, minha pergunta é se as configurações CONFIG_STRICT_DEVMEM=ysão seguras ou é fácil para o usuário root ignorá-las?

No Windows, quando você visualiza as propriedades de uma pasta, o tamanho é calculado da seguinte forma (recursivamente):

• para arquivos, o comprimento do conteúdo conta
• links simbólicos contam zero
• as próprias pastas contam zero

É possível obter o mesmo resultado na linha de comando do Linux?

Aqui estão alguns comandos de vários posts do SE que eu já tentei:

du -s -B 1 folder
du -sb folder
du -sh --apparent-size folder
ncdu
tree folder -s

O problema é que todos contam 4k para pastas. Alguém tem uma ideia?

Vamos supor que eu perdi um pen drive USB criptografado com LUKS. Acho que o tipo de sistema de arquivos (ext4/fat32/...) não desempenha um papel. Um estrangeiro o encontra. Claro que ele não pode acessar meus dados porque não tem a senha. Mas ele pode alterar um único byte no meio dos dados "brutos" para que os dados sejam danificados.

Depois que o pen drive for devolvido para mim, é possível verificar se meus dados foram danificados ou não?

Achei que a leitura de todo o dispositivo mapeador causaria um erro de E/S, mas infelizmente isso não aconteceu. Eu também verifiquei dmesg.

# create an all zero 100MiB file
dd if=/dev/zero of=moh bs=100M count=1

# format it as LUKS device
/usr/sbin/cryptsetup luksFormat moh

# map it to /dev/mapper/moh
sudo cryptsetup luksOpen moh moh

# initialize mapper file to zero
sudo dd if=/dev/zero of=/dev/mapper/moh

# close LUKS device
sudo cryptsetup luksClose moh

# overwrite 1MiB with zeroes at offset 10MiB. After this the LUKS device is damaged.
sudo dd if=/dev/zero of=moh conv=notrunc bs=1M seek=10 count=1

# open LUKS device and see if it complains
sudo cryptsetup luksOpen moh moh

# read all data to see if it complains
sudo dd if=/dev/mapper/moh of=/dev/null

Os comandos acima provam que abrir e ler um dispositivo LUKS danificado não produz nenhum erro.

Observe que não desejo executar nenhuma verificação do sistema de arquivos. Em vez disso, quero verificar se o dispositivo LUKS está intacto no nível de criptografia.

Como estou procurando um único comando para verificar um dispositivo luks, espero que você entenda que esta não é uma questão de programação mais adequada para SO.

Eu tentei isso:

find /usr/lib -print0 | grep zip | xargs -0 -I{} echo "found file: {}"
find /usr/lib -print0 | grep --null zip | xargs -0 -I{} echo "found file: {}"

Mas não funciona porque grep apenas diz que há uma correspondência de arquivo binário. Eu quero que o grep produza linhas terminadas em nulo.

É possível corrigir isso sem alterar todo o comando? Eu sei que é possível usar find -name ... -exec .... Mas seria bom se meu comando existente pudesse ser corrigido.

Existe a placa-mãe Supermicro X10DAi e o manual está aqui . Na página 1-11 você pode ver que cada CPU tem sua própria RAM.

Digamos que program Aestá oferecendo uma API por meio de um soquete local /var/run/socketapi. Este programa é iniciado na CPU 1.

Em seguida, há program Bconexão com este soquete e é iniciado na CPU 2.

Quando program Bescreve um comando no soquete, o kernel normalmente copia os dados do espaço de memória de program Bpara o de program A.

Mas como os programas são executados em CPUs diferentes e a memória não é compartilhada entre as CPUs, há um problema.

Como isso é resolvido no Linux recente? Talvez toda a memória da CPU 1 esteja mapeada para a CPU 2 usando a interface QPI mostrada no manual?

Ou talvez o programa IPC não funcione e ocorra um erro?

Forneça alguma referência ao código-fonte ou à documentação do Linux.

Eu tenho um HDD externo Intenso de 1 TB 2,5" aqui. Ele está com algum defeito (desconecta aleatoriamente no Windows), então decidi executar este comando para verificar:

dd if=/dev/sdb of=/dev/null bs=4M status=progress

A saída durante a execução se parece com isto:

715099471872 Bytes (715 GB, 666 GiB) kopiert, 16115 s, 44,4 MB/s

Além disso, 44,4 MB/s é muito lento para um disco USB3, o estranho é que o relógio está marcando apenas a cada 12s. ("16115 s" é o relógio dd.) Ao executar o mesmo comando em um disco saudável, ele marca a cada segundo.

Tentei stracever por que está bloqueando por tanto tempo, mas parece ler o disco pelo mapeamento de memória, então não consigo ver nada.

Também não é possível que o disco simplesmente bloqueie 12s durante a leitura. Porque a velocidade é de 44,4 MB/s e o tamanho do bloco é de 4 MB. Portanto, dd tem 11 chances por segundo de atualizar o relógio.

Então, o que está acontecendo aqui exatamente?

(Não estou interessado no que há de errado com o disco, mas, em vez disso, quero saber por que o relógio dd está correndo tão devagar. Portanto, espero estar certo no SE Unix.)

Já existe o SSD Nimbus ExaDrive 100TB e o SSD 200TB chegará em breve . Como você pode ler aqui, o ext4 suporta até 256 TB. É apenas uma questão de tempo o hardware atingirá esse limite.

Eles atualizarão o ext4 ou haverá o ext5? O que vai acontecer?

Eu tenho esta linha em /etc/crypttab para minha partição swap:

luks-4205519b-f3fe-468f-b05e-44f25f6882a4 UUID=4205519b-f3fe-468f-b05e-44f25f6882a4     /crypto_keyfile.bin luks,keyscript=/bin/cat

Comentei e agora ficou assim:

# luks-4205519b-f3fe-468f-b05e-44f25f6882a4 UUID=4205519b-f3fe-468f-b05e-44f25f6882a4     /crypto_keyfile.bin luks,keyscript=/bin/cat

Reiniciei, mas o arquivo do mapeador /dev/mapper/luks-4205519b-f3fe-468f-b05e-44f25f6882a4ainda é criado. Por que?

No Windows, é possível usar a hibernação sem usar nenhuma troca.

Gostaria de saber se isso é possível no Linux?

Pois no meu Debian 11 encontro essa linha em /etc/default/grub

GRUB_CMDLINE_LINUX_DEFAULT="... resume=/dev/mapper/luks-4205519b-f3fe-468f-b05e-44f25f6882a4"

Como você pode ver, a opção "resume=" especifica a partição swap que é usada para hibernação.

Agora, se eu excluir esta partição de troca (para desabilitar a troca), o que vou escrever em /etc/default/grub?

É possível usar um arquivo de hibernação como no Windows?

Porque eu tenho 32 GB de RAM e se eu usar uma partição swap de 32 GB apenas para hibernação, é uma perda de espaço.

Eu coloquei um CD na minha unidade. Como posso encontrar a cor do livro do arco-íris no Linux (livro vermelho/livro amarelo/livro azul/...)?

Eu tenho um disco que talvez esteja quebrado. Desejo gravar dados aleatórios no disco e depois verificar a soma de verificação md5.

Eu escrevo no disco assim:

dd if=/dev/urandom of=/dev/sda bs=4M status=progress

Como criar a soma de verificação md5 enquanto grava no disco ao mesmo tempo? Quero ver a soma de verificação md5 dos dados aleatórios gravados quando o dd terminar. Também quero ver o progresso durante a gravação no disco.

Eu li este post e criei este comando:

pv /dev/urandom >(md5sum) > /dev/sdXXX

O problema é que ele ocupa toda a minha memória RAM. Eu tenho 32 GB de RAM.

Meu disco é sda e tenho esses arquivos de tamanho:

/sys/dev/block/8:0/size
/sys/class/block/sda/size
/sys/block/sda/size

Qual devo usar? O primeiro é usado por lsblk. Existem diferenças?

Meu disco é sda. Existe o tamanho do arquivo /sys/dev/block/8:0/size. Sua unidade são os setores. Quando corro, strace lsblkposso vê-lo lendo este arquivo.

Mas como o lsblk obtém o tamanho do setor para depois mostrar o tamanho total do disco em bytes? Porque não consigo ver lsblk lendo o arquivo hw_sector_sizenem physical_block_size.

Eu tenho um dispositivo luks e ele é aberto na inicialização por /etc/crypttab. lsblk se parece com isso:

sdc                                             8:32   1 114,6G  0 disk  
└─luks-672dcc74-d002-47dc-b61b-525baf91dc7c   253:2    0 114,6G  0 crypt 

Eu monto o dispositivo assim:

pmount /dev/mapper/luks-672dcc74-d002-47dc-b61b-525baf91dc7c

Eu desmonto assim (ambos funcionam):

pumount /dev/mapper/luks-672dcc74-d002-47dc-b61b-525baf91dc7c
pumount /media/mapper_luks-672dcc74-d002-47dc-b61b-525baf91dc7c

Mas depois de pumount lsblk fica assim:

sdc                                             8:32   1 114,6G  0 disk

Por que pumount fechou o dispositivo luks? Na página de manual do pumount, diz:

Normally, pumount will not luksClose (see cryptsetup(1)) a device pmount did not open.

O dispositivo luks foi aberto por /etc/crypttab na inicialização e não por pmount! Por que pumount fecha o dispositivo luks? Isso é um inseto?

Estou no debian bullseye.

Eu tentei o seguinte:

user1@debian-desktop:/home/user1$ sudo add-apt-repository ppa:cdemu/ppa
Unofficial CDEmu packages
More info: https://launchpad.net/~cdemu/+archive/ubuntu/ppa
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: Die "Keybox" `/tmp/tmpknhcngga/pubring.gpg' wurde erstellt
gpg: /tmp/tmpknhcngga/trustdb.gpg: trust-db erzeugt
gpg: Schlüssel 423A2125D782A00F: Öffentlicher Schlüssel "Launchpad PPA for CDEmu" importiert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                              importiert: 1
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
gpg: Keine gültigen OpenPGP-Daten gefunden.
user1@debian-desktop:/home/user1$ sudo apt-get update
....         
Ign:5 http://ppa.launchpad.net/cdemu/ppa/ubuntu lunar InRelease
Fehl:6 http://ppa.launchpad.net/cdemu/ppa/ubuntu lunar Release
404  Not Found [IP: 2620:2d:4000:1::3e 80]
Paketlisten werden gelesen… Fertig                        
E: Das Depot »http://ppa.launchpad.net/cdemu/ppa/ubuntu lunar Release« enthält keine Release-Datei.
N: Eine Aktualisierung von solch einem Depot kann nicht auf eine sichere Art durchgeführt werden, daher ist es standardmäßig deaktiviert.
N: Weitere Details zur Erzeugung von Paketdepots sowie zu deren Benutzerkonfiguration finden Sie in der Handbuchseite apt-secure(8).

Acho que a linha importante é:

404  Not Found [IP: 2620:2d:4000:1::3e 80]

Por que recebo esse erro?

Quando executo o cd-info, a lista de faixas fica assim:

CD-ROM Track List (1 - 1)
  #: MSF       LSN    Type   Green? Copy?
  1: 00:02:00  000000 data   false  no   
170: 68:17:27  307152 leadout (688 MB raw, 599 MB formatted)

O que significa LSN e o que significa? Eu verifiquei a página de manual e o Google e não encontrei nada!

Quero detectar erros na lógica de execução do aplicativo. Por exemplo:

• esqueci de ligar free()no endereço retornado pormalloc()
• não fechou o identificador de arquivo retornado poropen()
• sinalizadores inválidos passados ​​paraopen()
• identificador de arquivo inválido passado parapoll()
• write()chamado em fd que não foi aberto para escrita
• passar sinalizadores inválidos para, open()por exemplo, open("/etc/fstab", 4)
• chamando close()um fd inválido
• ...

Acho que tem centenas mais.

Talvez a ferramenta possa ser executada de forma semelhante a ftraceou strace, mas um log do kernel contendo as chamadas defeituosas também seria suficiente.