Cubi73's questions

Percebi que às vezes vgchange -a n [vgname]parece não fechar o grupo de volumes corretamente. Isso acontece com mais frequência, quando eu realmente preparo um novo sistema e não sei o que está causando isso. Considere a seguinte estrutura de disco (saída de lsblk -o name,fstype)

NAME                   FSTYPE
/dev/sdx
+- /dev/sdx1           crypto_LUKS
|  +- test_luks        LVM2_member
|  |  +- test_lvm-test ext4

Quando eu abro todas essas coisas da maneira normal ( cryptsetup open ..., vgchange -a y ..., etc.), faça algumas coisas test_lvm-teste feche tudo com

umount [mountpoint of test_lvm-test]
vgchange -a n test_lvm
cryptsetup close test_luks

test_lvmdesaparece da saída de vgscomo esperado. MAS, se eu acabei de criar essa estrutura (veja abaixo para reproduzir), montei pela primeira vez e depois fechei da mesma forma, test_lvmnão desaparece da saída do vgs. Em vez disso, vgsreclama que o dispositivo para o volume físico "não foi encontrado ou rejeitado por um filtro". Para remover o erro de vgsTenho que reabrir test_lukse test_lvm, desativar test_lvmnovamente e fechar test_luksnovamente.

Por que isso acontece? Por que o LVM mantém o identificador test_lvmafter vgchange -a n test_lvm; cryptsetup close test_luks, quando foi montado pela primeira vez, mas não depois?

Consegui reproduzir esse comportamento de maneira mais consistente com o Arch Linux Live CD "Arch Linux 5.2.5-arch1-1-ARCH" no VirtualBox assim

# Let /dev/sdx1 be the partition to test this on

#
# Create LVM on LUKS with one ext4 volume
#
cryptsetup luksFormat --cipher aes-xts-plain64 --hash sha256 --label "Test (Encrypted)" /dev/sdx1
cryptsetup open /dev/sdx1 test_luks
pvcreate /dev/mapper/test_luks
vgcreate test_lvm /dev/mapper/test_luks
lvcreate --extents 100%FREE test_lvm --name test
mkfs.ext4 -L Test /dev/test_lvm/test

#
# Mount volume and write to it
#
mount /dev/test_lvm/test /mnt
echo "Hello World" > /mnt/test.txt

#
# Unmount everything
#
umount /mnt
vgchange -a n test_lvm
# -> 0 logical volume(s) in volume group "test_lvm" now active
cryptsetup close test_luks

#
# Check vgs
#
vgs
# -> Warning: Device for PV [uuid] not found or rejected by a filter.
# -> Warning: Device for PV [same uuid] not found or rejected by a filter.
# -> Couldn't find device with uuid [same uuid again].
# -> VG       #PV #LV #SM Attr   VSize   VFree
# -> test_lvm   1   1   0 wz-pn- 492.00m    0

#
# Mount and unmount again
#
cryptsetup open /dev/sdx1 test_luks
vgs
# No error this time
vgchange -a n test_lvm
cryptsetup close test_luks
# test_lvm no longer listed in vgs and no errors.

Meu novo laptop tem um layout de teclado alemão um tanto incomum, onde a <tecla está localizada à direita de AltGr(veja a imagem abaixo). Isso torna a digitação \|( AltGr+ ßseguido por AltGr+ <) realmente muito difícil (e ao digitar coisas matemáticas no LaTeX, isso acontece com muita frequência). Então, descobri que todas as AltGr-combinações podem ser substituídas por Ctrl+ Alt-combinações. Na minha máquina, isso funciona para todas as combinações, AltGrEXCETO AltGr+ <.

Então minha primeira pergunta é: Por quê? Por que Ctrl+ Alt+* funcionaria para todas as chaves, exceto <? E minha segunda pergunta é se é possível (de preferência, mas não necessariamente sem software externo) mapear AltGr+ ´para AltGr+ <para facilitar a digitação \|?

Usando o comando do gdisk, iposso visualizar o "GUID exclusivo" de uma partição (identificando a partição) e o "GUID/código de tipo" (sugerindo o tipo/uso/formato da partição) e o tcomando no gdisk me permite alterar esse código de tipo, mas apenas com uma lista de códigos de tipo predefinidos. É possível alterar manualmente o tipo GUID de uma partição caso a lista de códigos de tipo pré-definidos do gdisk não inclua esse tipo? (De preferência algum método que não envolva a abertura de um editor hexadecimal.)

Por exemplo, a versão do gdisk no live CD do Elementary OS 5.0 não inclui o tipo GUID para partições LUKS CA7D7CCB-63ED-4C53-861C-1742536059CC, mas a versão do gdisk no live CD do ArchLinux inclui e está listada como type code 8309.

A seleção de um pendrive no VirtualBox torna o pendrive disponível para o sistema convidado e indisponível para o sistema host (no meu caso, o Windows), para que o sistema host não interfira no sistema convidado. Existe uma maneira de conseguir a mesma coisa com discos brutos? Posso disponibilizar discos gerados com vboxmanage internalcommands createrawvmdko sistema convidado simplesmente adicionando-os aos dispositivos de armazenamento do sistema convidado no painel de configurações, mas o sistema host ainda pode gravar neles, o que faz com que o sistema convidado trave na maioria das vezes. Existe uma maneira de tornar um disco bruto indisponível para o sistema host, como o VirtualBox faz com pendrives?

EDIT: No meu caso, quero instalar um sistema Windows em um pendrive. Mas, como o Windows rejeita pendrives USB como alvos de instalação, pensei em enganar o Windows para instalá-lo em um pendrive disfarçando-o de disco rígido, que é exatamente o que os VMDKs brutos fazem. Embora o sistema host comece a gritar comigo assim que o sistema convidado altera a tabela de partição do pendrive, o que não acontece, se eu conectar o pendrive da maneira normal. No entanto, conectar o pendrive da maneira normal faz com que o Windows rejeite o pendrive.